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

Re: Review of RDF Mapping

From: Evren Sirin <evren@clarkparsia.com>
Date: Wed, 8 Apr 2009 08:41:25 -0400
Message-ID: <cbf390380904080541o2eae1239uae327be713b9499f@mail.gmail.com>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: public-owl-wg@w3.org
On Tue, Apr 7, 2009 at 6:57 AM, Peter F. Patel-Schneider
<pfps@research.bell-labs.com> wrote:
>> 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.

Sure, I understand this. I have some comments below that would be
relevant for future discussions.

>> 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).

Sure, that makes sense.

>> 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.

I agree this is true for unionOf and intersectionOf but I don't think
it is good style in any means to reuse equivalentClass for datatypes.
It might have been available for datatypes in OWL 1 Full but clearly
it wasn't commonly used in that way (actually I don't know if it was
used for that purpose in practice at all). If this was a type neutral
term like equivalentTo I wouldn't object to its reuse. I understand
the time constraints for not making any changes right now but I the
reuse of equivalentClass should be reconsidered after LC. Considering
a lot of people coming from RDF world sees only the RDF view of OWL I
think it is important to provide clear, consistent RDF mapping that
does not lead to confusion.

> 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].

Yes, sure. But if the problem is only number of new keywords added to
the vocabulary I'm sure there are places in the current mapping where
some of the terms can be eliminated. For example, I don't think there
is a need for separate terms onClass and onDataRange for qualified
cardinality restrictions. Only one term can be used for both object
and data restrictions.

> 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
> datatypes.
>> 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.

I didn't think that the order dependency necessitated a change in the
vocabulary. I just pointed out this issue because I wasn't sure if
there were other (more serious) issues similar to this one.


>> 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
> peter
Received on Wednesday, 8 April 2009 12:42:14 UTC

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