On 19/03/13 15:09, Ed Swing wrote:
What would be the proper construct then for "A killing is a subclass of event that
cannot have a NewsOrganization as the actor"?
The simplest change from what you have might be:
<owl:Class rdf:ID="Killing">
<rdfs:subClassOf rdf:resource="#Event" />
<rdfs:subClassOf>
<owl:Class>
<owl:complementOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#actor" />
<owl:hasValue rdf:resource="#NewsOrganization" />
</owl:Restriction>
</owl:complementOf>
</owl:Class>
</rdfs:subClassOf>
</owl:Class>
Dave
-----Original Message-----
From: Dave Reynolds [mailto:[email protected]]
Sent: Tuesday, March 19, 2013 11:01 AM
To: [email protected]
Subject: Re: Super/Subclass relationships in OntModel?
On 19/03/13 14:07, Ed Swing wrote:
Unfortunately, it looks like there's still a problem with the super/subclass
relationship even after I fixed the inconsistent property.
This is not a completely fixed ontology.
It still has the illegal section:
<owl:Class rdf:ID="Killing">
<rdfs:subClassOf rdf:resource="#Event" />
<rdfs:subClassOf>
<owl:equivalentClass>
<owl:complementOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#actor" />
<owl:hasValue rdf:resource="#NewsOrganization" />
</owl:Restriction>
</owl:complementOf>
</owl:equivalentClass>
</rdfs:subClassOf>
</owl:Class>
Less significantly it still has the two occurrences of rdf:range instead of
rdfs:range.
Specifically, here's the test code:
OntModel model =
ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM_RULE_INF);
FileInputStream inStream =
new FileInputStream("ontology/terrorism.xml");
model.read(inStream, null);
inStream.close();
String uriBase = model.getNsPrefixURI("");
OntClass cls = model.getOntClass(uriBase + "TerrorAttack");
System.out
.println("TerAtt: " + cls + " Super=" + cls.getSuperClass());
for (Iterator<OntClass> iter = cls.listSuperClasses(false); iter
.hasNext();) {
System.out.println("Super: " + iter.next());
}
OntClass newsEvt = model.getOntClass("NewsArticle");
That should be:
OntClass newsEvt = model.getOntClass(uriBase + "NewsArticle");
System.out.println("NewsEvt is a superclass of TerrorAttack: "
+ cls.hasSuperClass(newsEvt));
Newest version of the ontology is attached. What is printed:
TerAtt: http://blsdev1.vsticorp.com/terrorism#TerrorAttack
Super=http://www.w3.org/2002/07/owl#Thing
Super: http://www.w3.org/2002/07/owl#Thing
Super: http://www.w3.org/2000/01/rdf-schema#Resource
Super: 1d20fb81:13d82ecf576:-7fec
Super: http://blsdev1.vsticorp.com/terrorism#Killing
Super: http://blsdev1.vsticorp.com/terrorism#Event
Super: 1d20fb81:13d82ecf576:-7fef
Super: 1d20fb81:13d82ecf576:-7ff8
Super: 1d20fb81:13d82ecf576:-7ff7
That looks reasonable to me.
NewsEvt is a superclass of TerrorAttack: true
The superclass test is obviously incorrect. Not only are the NewsArticle and
TerrorAttack classes disjoint, the NewsArticle class doesn't even appear when
all the superclasses are listed. Why is the hasSuperClass() method returning
true?
Because:
model.getOntClass("NewsArticle")
returns null since there is no such class, and hasSuperClass looks to be treating null as
a wildcard (as does much of the Jena API). So you are actually asking "does
TerrorAttack have any super clases".
Fixing the missing uriBase on that getOntClass call and commenting out the
illegal owl:equivalentClass restriction then I get:
[[[
TerAtt: http://blsdev1.vsticorp.com/terrorism#TerrorAttack
Super=http://www.w3.org/2002/07/owl#Thing
Super: http://www.w3.org/2002/07/owl#Thing
Super: http://www.w3.org/2000/01/rdf-schema#Resource
Super: -1765f448:13d8321ac37:-7fee
Super: http://blsdev1.vsticorp.com/terrorism#Killing
Super: http://blsdev1.vsticorp.com/terrorism#Event
Super: -1765f448:13d8321ac37:-7ff8
Super: -1765f448:13d8321ac37:-7ff7
NewsEvt is a superclass of TerrorAttack: false ]]]
That is with jena 2.10.0 as released, i.e. without the fix to JENA-416.
Dave
-----Original Message-----
From: Dave Reynolds [mailto:[email protected]]
Sent: Tuesday, March 19, 2013 7:32 AM
To: [email protected]
Subject: Re: Super/Subclass relationships in OntModel?
On 19/03/13 00:35, Brian McBride wrote:
On 18/03/2013 21:36, Dave Reynolds wrote:
On 18/03/13 21:16, Joshua TAYLOR wrote:
On Mon, Mar 18, 2013 at 4:55 PM, Brian McBride
<[email protected]> wrote:
On 18/03/2013 20:18, Joshua TAYLOR wrote:
This spurred me to look at some of the relevant rules, and I'm kind
of puzzled by them. E.g., (from owl-fb.rules, line 277):
[maxRec2: (?C owl:equivalentClass max(?P, 0)), (?P rdfs:domain ?D),
(?E owl:disjointWith ?D)
-> (?E owl:equivalentClass ?C)]
That's not quite the situation here however ...
Having been wrong twice already, I'm a bit hesitant here, but I think
this rule does explain what is going on.
As I've said, the presenting problem is at least partly caused by the
illegal use of owl:equivalentClass in the source ontology and if I
remove that then the test case (listing super classes of
#AircraftHijacking) works.
However, as I've also said, I do agree that those two rules are incorrect.
Thanks for the test case. I've recorded it as JENA-416 and applied a fix.
Dave
