[Pellet-Users] Feature: pinpoint problematic statements in ValidityReport

[Ignazio Palmisano]

Evren Sirin wrote:
> Hi Ignazio,
> Axiom pinpointing capabilities of Pellet is not currently in the 
> standard release. They are available in a branch of Pellet which we are 
> currently integrating to the main branch. For this reason, we are not 
> using Report.getExtension() at all. When we finish the integration, what 
> we will have in the report is some information about the clash (not just 
> the individual but also the type of clash, e.g. cardinality or datatype) 
> plus the set of statements causing the inconsistency. Initially these 
> set of statements will be in some internal Pellet format (i.e. 
> represented as ATerm's) but we might add functionality to turn that into 
> a set of Jena triples.
> 
> Right now, if you set PelletOptions.USE_TRACING to true and then call 
> kb.getExplanationSet() you will get a subset of the problematic 
> statements. For the example you provide, the (incomplete) explanation 
> set looks like:
> [prop(urn:italypremier,urn:prodi,urn:italy), 
> prop(urn:italypremier,urn:berlusconi,urn:italy)]
> 
> When we finish the integration of explanation code this set will contain 
> all the statements (actually there can be multiple different sets 
> causing the inconsistency). We do not have an exact date of when this 
> version will be available but hopefully it will be ready in a month or so.
> 
> Evren

Thank you very much,
Ignazio

> 
> On 7/19/2006 4:58 AM, Ignazio Palmisano wrote:
>> Hi all,
>> I'm trying to use Pellet with Jena in order to spot inconsistencies in a
>> OWL model and reporting the (set of) statement related to the
>> inconsistency to the calling application. To do that, I'm doing:
>>
>> public class TestInconsistencyDetecting {
>>     public static void main(String[] args) {
>>         OntModel
>> o1=ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC, 
>> null);
>>         OntModel
>> o2=ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC, 
>> null);
>>         OntClass human=o1.createClass("urn:Human");
>>         OntClass country=o1.createClass("urn:Country");
>>         Individual italy=o1.createIndividual( country);
>>         OntProperty
>> premier=o1.createInverseFunctionalProperty("urn:italypremier");
>>         Individual prodi=o1.createIndividual("urn:prodi", human);
>>         Individual berlusconi=o1.createIndividual("urn:berlusconi",  
>> human);
>>         o1.add(berlusconi, premier, italy);
>>         o1.add(berlusconi, OWL.differentFrom, prodi);
>>         o1.add(prodi, premier, italy);
>>         ValidityReport r=o1.validate();
>>         Iterator it=r.getReports();
>>         while(it.hasNext()) {
>>             ValidityReport.Report rep=(Report) it.next();
>>             // this returns null
>>             rep.getExtension();
>>         }
>>        
>>     }
>> }
>>
>> The problem here is, the rep.getExtension() method returns null, and it
>> seems there is no method in Pellet to access information about the
>> inconsistency but to parse the string that describes the problem, which
>> is a really fragile way to do that.
>>
>> Drilling down in the Pellet source code, I found at line 1299 of
>> PelletInfGraph, method validate() (wrt the pellet-nightly.zip downloaded
>> this morning):
>>
>> report.add( true, "KB is inconsistent!", kb.getExplanation());
>>
>> kb.getExplanation() ends calling Clash.detailedString(); exploring the
>> Clash class, I found the internal Node which holds information about the
>> node that is involved in the clash, but the Clash class does not offer
>> any method to access this value.
>> I did the following modifications:
>>
>> added the method:
>>
>> /**returns the current node object*/
>> public Node getNode() {
>>     return this.node;
>> }
>>
>> to the Clash class, so that I can modify line 1299 of PelletInfGraph to:
>> report.add( true, "KB is inconsistent!", kb.getExplanation() ,
>> kb.getABox().getLastClash().getNode());
>>
>> and then I can obtain the Node as result of
>>
>> rep.getExtension();
>>
>> in my code, and from that information I obtain the Jena object
>> representing the node in the original model.
>>
>> Does this modification seem useful to others, or is there a better way
>> to do it without changing the code?
>>
>> Ignazio
>>   
> 
> 


-- 
Ignazio Palmisano
Ph.D. Student - palmisano at di.uniba.it, ignazio_io at yahoo.it