W3C home > Mailing lists > Public > public-owl-wg@w3.org > March 2008

RE: Proposal to close ISSUE-12

From: Michael Schneider <schneid@fzi.de>
Date: Tue, 25 Mar 2008 23:35:12 +0100
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A080368C@judith.fzi.de>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: <public-owl-wg@w3.org>
Hi Peter!

>> > >1/ Annotations on axioms that generate single triples are 
>as before 
>> > >   e.g., ObjectPropertyDomain(Annotation(a "bar") r d) 
>could become
>> > >   	 _:x rdf:type owl11:Axiom
>> > >	 _:x rdf:subject r
>> > >	 _:x rdf:predicate rdfs:domain
>> > >	 _:x rdf:object d
>> > >	 _:x a "bar"
>> > >2/ Annotations on axioms that generate a fresh blank node put the
>> > >   annotation on that blank node, as is done already for negative
>> > >   property assersions
>> > >   e.g.,  DisjointClasses(Annotation(a "bar") c1 c2 c3) becomes
>> > >   	  _:x rdf:type owl11:AllDisjointClasses
>> > >	  _:x owl11:members SEQ(c1 c2 c3)
>> > >	  _:x a "bar"
>> > >3/ Other annotations on axioms that generate multiple 
>triples (e.g.,
>> > >   EquivalentObjectProperties) result in the triples 
>being reified and
>> > >   each annotation attached to each of the reified triples.
>> > >
>> > >peter
>> > Point 3/ may produce a lot of duplication of information, 
>in particular when
>> > owl:RestrictionS are involved.
>> Agreed, but I view this as the "least-bad" approach.
>Further, restrictions fall under the second point, so they will not
>generate duplicate annotations.

I now see that my statement about restrictions was not adequate. A restriction alone is not an axiom, but is a class description. So, formally, /none/ of the above annotation approaches, which are for /axiom/ annotation only, will apply to it. A construct like e.g.

     _:x rdf:type owl11:ObjectRestriction
     _:x owl:onProperty p
     _:x owl:allValuesFrom C

will need to part of a real axiom such as

  (1) w rdf:type _:x 			// a class assertion

  (2) D rdfs:subClassOf _:x		// a subsumption axiom

  (3) _:x rdfs:subClassOf D		// another subsumption axiom

AFAICS, the first two of these examples can be regarded as single-triple axioms, so approach 1/ would apply to them.

But I am not certain about the third example. Is this a single-triple axiom ((3) alone) or a multi-triple axiom ((3)+(0))? I don't know whether point 1/ or point 2/ applies here.

I first thought that it must be a multi-triple axiom, in which case approach 2/ would apply. But when I add an additional subsumption axiom for the restriction (0):

  (4) _:x rdfs:subClassOf E

which of the two axioms is then annotated? And in the case that both axioms are annotated in this way, how can I then annotate axiom (3) alone?

So it rather looks to me that it must be a single-triple axiom, for which point 1/ applies. 

But in this case I do not see a situation in which I *must* apply point 2/. In the example you give for point 2/

  (5a) _:x rdf:type owl11:AllDisjointClasses
  (5b) _:x owl11:members SEQ(c1 c2 c3)

I can alternatively annotate (5b) alone as a single-triple axiom, by applying approach 1/. By doing so, it will be perfectly clear that the whole multi-triple axiom consisting of (5a) and (5b) is annotated, because the bNode "_:x" connects these triples, and therefore identifies this axiom.

So my question is: Is there a situation where approach 2/ is a *must*?


Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

Received on Tuesday, 25 March 2008 22:35:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:03 UTC