LANG: Defn of DL in Mappings

As we have been discussing:

The RDF Graph version of OWL DL is defined in

OWL Semantics
section 4.1
 Definition of OWL/DL Ontologies in RDF Graph Form

(suggested title!)

http://www.w3.org/TR/owl-semantics/mapping.html#4.1

[[
A collection of n-triples is an OWL/DL ontology in n-triple form if it is
the result of the above transformation of an OWL ontology in abstract syntax
form
]]

This suffers from three problems (the first two I have raised already on the
list).
1: That the mappings necesarily result in typing triples that do not conform
well with the DAML+OIL usage of RDF/XML for instance data. The ones that
Peter is having most difficulty getting rid of are:

xxx rdf:type owl:Thing .
(for instances)
and
ppp rdf:type owl:ObjectProperty .
or
ppp rdf:type owl:DatatypeProperty .
for properties.

2: That the use of blank nodes in RDF graphs within OWL DL is heavily
restricted.
Such restrictions have proved an error for RDF.

3: That it does not work well with imports.
(In fact I do not see how OWL DL in abstract syntax form works well with
imports).

As I see it:

doc1:
EquivalentClasses(Class(A),Class(B))

doc2:
SameIndividual(Individual(A),Individual(B))

doc3:
Imports(doc1)
Imports(doc2)


are all legal OWL DL documents but the resulting knowledge base is badly
typed.

====

These problems can be addressed in the following way.

1) Define:
Strict OWL DL RDF Graph as being one that corresponds to an Abstract OWL DL
document without imports.

2) An RDF Graph can be transformed by:
  a) for each non-Literal node XXX in the graph add one "DL typing triple"
    XXX rdf:type owl:Thing .
    XXX rdf:type owl:Class .
    XXX rdf:type owl:Datatype .
    XXX rdf:type owl:DatatypeProperty .
OR
    XXX rdf:type owl:ObjectProperty .
(NOTE: this may duplicate, or not, a DL typing triple in the original graph)
  b) For any node YYY appearing in more than one triple other than a DL
typing triple the following transformation may be applied.

Already:
YYY rdf:type owl:Thing .
Add:
ZZZ rdf:type owl:Thing .
YYY owl:sameIndividualAs ZZZ .

Already:
YYY rdf:type owl:Class .
Add:
ZZZ rdf:type owl:Class .
YYY owl:sameClassAs ZZZ .

Where ZZZ is a new blank node (note YYY *may* be blank), and one or more
(but not all) of the triples containing YYY are replaced by equivalent
triples containing ZZZ.


3: Given an RDF Graph it is in OWL DL iff its import closure can be
transformed into a strict OWL DL Graph by a transformation as defined in
(2), and moreover the DL typing triple in (2a) are uniquely determined by
this requirement.

====

Commentary:

The "uniquely" determined bit means that if the original RDF graph contains
enough information, in some way or other, to completely specific the DL
typing of its nodes, then that DL typing is understood as being present.
This *is* monotonic with respect to the OWL DL/OWL Full layering because in
OWL Full, such triples are all semantic consequences of the usages that
could possibly result in them being uniquely determined by the OWL DL rules
(and many of these triples are somewhat meaningless in OWL Full anyway, e.g.
all properties are owl:ObjectProperty, since owl:Thing = rdfs:Resource which
is a superclass of rdfs:Literal. (Some care may be needed with the
definition of owl:DatatypeProperty in OWL Full).

Part 2(b) is explicitly non-deterministic and is addressing the blank node
problem, and also making it easier to conform with the abstract syntax e.g.


<owl:Restriction rdf:ID="foo">
  <owl:onProperty rdf:ID="p"/>
  <owl:hasValue rdf:ID="v"/>
</owl:Restriction>

Is now part of OWL Lite:
foo must be a class
v must be a Thing (since hasValue in the abstract syntax takes URIs/bnodes
for Things and typed literals for themselves).
p must be an ObjectProperty

using the 2(b) rules we can transform this to

<owl:Class  rdf:ID="foo">
   <owl:sameClassAs>
     <owl:Class>
       <owl:Restriction>
         <owl:onProperty rdf:ID="p"/>
         <owl:hasValue rdf:ID="v"/>
       </owl:Restriction>
      </owl:Class>
   </owl:sameClassAs>
</owl:Class>

which is in strict OWL DL (with minor mods to the mapping rules).


====

Bother, 2(b) doesn't do as much as I wanted for solving the inability to use
a bnode in two places problem, ... I think the abstarct syntax could benefit
from the following change:

In many places (to be defined precisely which)
replace
  <URI reference>
with
  <OWL Name>

and add a rule

<OWL Name> ::= <URI Reference>
<OWL Name> ::= <local identifier>

The latter play the same role in the abstract syntax as Blank node
identifiers play in N-triples and RDF/XML. (Note there are no blank node
identifiers in the RDF graph).

This when combined with 2(b) allows near-arbitrary use of blank nodes while
clearly remaining within the constraints of the abstract syntax.

Jeremy

Received on Friday, 20 December 2002 03:56:21 UTC