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

Re: Review of RDF Mapping

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Tue, 07 Apr 2009 06:57:58 -0400 (EDT)
Message-Id: <20090407.065758.238656991.pfps@research.bell-labs.com>
To: evren@clarkparsia.com
Cc: public-owl-wg@w3.org
> Below is couple of comments I have about RDF mapping. Overall, I think
> this document is in very good shape and my comments are mostly related
> to some details in the mapping.

Thanks Evren.  In general you point out issues with the mapping that,
under ideal conditions, could result in changes.  However, due to time
pressure, desire to not bloat the OWL RDF vocabulary, and desire to
retain the maximum degree of compatibility with existing OWL ontologies
encoded in RDF graphs, we are loath to make any changes right now as a
result of your comments.

> Section 1:
> The RDF graph created from ontology O is called T(O) whereas the
> ontology created from RDF graph G is called O_G (subscript). It would
> be better to have a consistent notation, e.g. call reverse mapping R
> and write R(G) instead of O_G.

Yes, probably, but not worth fixing right now, I think, as it would
require a careful pass through the document, unless some editor ends up
with extra time on their hands.  Fixing this after last call should be
possible as it is simply a matter of presentation (i.e., not even really
a significant editorial change).

> Section 2.1:
> Intersection and union data ranges reuse class constructs
> owl:intersectionOf and owl:unionOf keywords respectively whereas
> datatype complement is expressed with owl:datatypeComplementOf.
> Initially owl:complementOf was used for datatype complements but this
> was changed as a result of discussions on how it affects RDF-based
> semantics [1]. AFAICT, the semantic problems related to complement do
> not occur for intersection and union. So from the point of semantics
> everything is OK. However, from the style point of view, the resulting
> vocabulary is inconsistent and possibly confusing. I think the
> "datatype" prefix should be either used for all keywords or none.
> Personally I'd be happy with none having the prefix but given the
> semantics issue it might be to coin new terms for these datatypes.
> Also in the past people expressed their discomfort about reusing
> class vocabulary for datatypes due to forward compatibility reasons
> [2] and similar reasons resulted in coining propertyDisjointWith
> instead of using disjointWith for properties.
> The same arguments apply to DatatypeDefinition mapping which uses
> owl:equivalentClass keyword. I think this is more confusing than the
> previous case since the name makes it clear that the keyword was
> intended to be used for classes. Considering there is a considerable
> of amount of OWL users that use only RDF/XML, it would be better use a
> less confusing name such as equivalentDatatype.

In RDF, datatypes are classes, so in OWL 1 Full owl:unionOf,
owl:intersectionOf, and owl:equivalentClass were already available for
use for datatypes, and appear to fit better into the RDF style.  Having
the OWL 2 mapping as it is takes some of these potentially extant
constructs into OWL 2 DL, which would not be the case if the mapping
used new vocabulary.  As well, adding a datatype version would add to
vocabulary bloat, which has been a concern in the working group [sic].

As you say, the situation is different for owl:datatypeComplementOf,
as that is complement relative to the datatype domain (LV in RDF), and
is different from owl:complementOf, which can also be used for

> Section 3.2.4
> Following the inverse property expression mapping rule in Table 11 for
> the input triples
>   _:x owl:inverseOf p
>   _:x owl:inverseOf q
> would produce either the axiom
>   InverseObjectProperties( ObjectInverseOf( p ) q )
> or
>   InverseObjectProperties( ObjectInverseOf( q ) p )
> depending on the order triples are processed. The semantics of both
> axioms are same so the meaning of the document does not change.
> However, it is not ideal to have structurally different axioms based
> on the ordering of input triples. Considering this is a very contrived
> example (normally you would just write EquivalentObjectProperties(p q)
> instead) this is probably not an issue unless the issue comes up in
> other cases. AFAICT, the ordering does not have effect on parsing for
> any other kind of expression or axiom.

owl:inverseOf was available for use in OWL 1 Full, and carried both the
axiom and the object property expression meaning.  Adding a new
vocabulary name, could result in some useful ontologies not being in OWL
2 DL.   

> Cheers,
> Evren
> [1] http://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/0024.html
> [2] http://lists.w3.org/Archives/Public/public-owl-dev/2007JanMar/0078.html

Received on Tuesday, 7 April 2009 10:55:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:58 UTC