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>

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. (0) _: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*? Cheers, Michael -- 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ßnerkrausReceived 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
*