Review of RDF Mapping

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.

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.

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.

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.

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 Monday, 6 April 2009 15:04:03 UTC