W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2009

RE: OWL 2 LC Comments

From: Michael Schneider <schneid@fzi.de>
Date: Thu, 22 Jan 2009 21:08:14 +0100
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A0F98979@judith.fzi.de>
To: "Zhe Wu" <alan.wu@oracle.com>
Cc: "OWL Working Group WG" <public-owl-wg@w3.org>
To start a strictly WG-internal discussion... :)

>-----Original Message-----
>From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org]
>On Behalf Of Zhe Wu
>Sent: Thursday, January 22, 2009 5:56 PM
>To: Z Wu; OWL Working Group WG
>Subject: OWL 2 LC Comments
>
>
>Hi,
>
>I have collected the following comments from my colleagues in Oracle.

[snip]

>5. In the RDF mapping document, is it possible to keep OWL 2 vocabulary
>a bit smaller by replacing
>    owl:minQualifiedCardinality with the existing owl:minCardinality?
>    Same idea applies to owl:qualifiedCardinality,
>owl:maxQualifiedCardinality.
>    After all, owl:onClass is there to differentiate the qualified vs.
>non-qualified case.

No, this would actually lead to inconsistency of OWL 2 Full. This was ISSUE-122, and the "qualified" names were the resolution of this issue.

This would also hit OWL RL/RDF hard. Consider the following RDF graph, applying the RDF encoding of QCRs in the way you suggest:

    :snaily rdf:type [ rdf:type owl:Restriction ;
        owl:maxCardinality "0"^^xsd:nonNegativeInteger 
        owl:onProperty :hasBodyPart ;
        owl:onClass :Legs ;
    ] .

    :snaily :hasBodyPart :aHead .

One might expect that this ontology doesn't lead to any trouble, since the individual :aHead cannot be inferred to be a member of the class :Legs. However, the RDF rules will actually provide the result *false*, since the triples in the QCR *ADDITIONALLY* encode an unrestricted 0-cardinality restriction, disallowing poor little :snaily to have any body part at all.

>6. In Section 2.2 of RDF mapping document, are we missing a translation?
>    It is unclear how the second example in 2.2 is translated into
>triples.
>    The AnnotationAssertion in Table 1 has three parameters and that
>example has only two parameters
>    for AnnotationAssertion.

Yes, looks like a typo to me. From the RDF encoding, the Functional Syntax assertion should probably rather have the form

    AnnotationAssertion( a:Peter
        Annotation( a:author a:Seth_MacFarlane )
        rdfs:label "Peter Griffin"
    )

>7. For the RL/RDF rule set, it is useful to mention that it is not a
>minimal set. Some rules are redundant.
>    Also, it will be useful to add rules like
>    ?p1  subPropertyOf  ?p2  and     ?p2  subPropertyOf  ?p1  ==> ?p1
>equivalentProperty  ?p2
>     (same thing applies to subClassOf)

Yes, I also believe that these rules are missing. The only rule that refers to "owl:equivalentClass" in its consequent is "scm-cls", which represents the reflexivity of class equivalence. This alone won't allow to do the requested conclusion. Analog for "owl:equivalentProperty".

I would consider adding the additional rules a bug fix rather than a change of design, since they are rules that one obviously wants to have. Also, pD*, which is cited in the Profiles document, has these rules (see Table 7 in Section 5.3 of the pD* paper).

Cheers,
Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Dept. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: schneid@fzi.de
WWW  : 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
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. rer. nat. Dr. h.c. Wolffried Stucky, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

==============================================================================



Received on Thursday, 22 January 2009 20:08:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 January 2009 20:08:56 GMT