Re: LANG: Defn of DL in Mappings

From: "Jeremy Carroll" <jjc@hpl.hp.com>
Subject: LANG: Defn of DL in Mappings
Date: Fri, 20 Dec 2002 09:57:57 +0100

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

Done.

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

Now all that is required is that each individual is given an OWL class as a type.

> (for instances)
> and
> ppp rdf:type owl:ObjectProperty .

Needed.

> or
> ppp rdf:type owl:DatatypeProperty .

Needed.

> for properties.
> 
> 2: That the use of blank nodes in RDF graphs within OWL DL is heavily
> restricted.

If we allow OWL classes and properties to not have identifiers then there
are some unusual cases that might be problematic.  For example, we would be
very close to being able to define the class of of all individuals that
have at least two values for some (undetermined) property.  

> Such restrictions have proved an error for RDF.

This is a matter of opinion.  They certainly did mean that RDF/XML could
not encode all RDF graphs.  I would argue, however, that the real problem
is the sparcity of RDF syntax.

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

The problem is getting the requirements correct.  

I may have a problem here, namely that the test for DL-ness is made too
early, i.e., before the imports closure is determined.

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

This would be problematic in that an RDF graph could be transformed into
two different RDF graphs that have different consequences.

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

I don't see the need for this.  The first transformation does not increase
the set of RDF graphs covered.  The second set only increases then by
allowing in certain kinds of blank classes.

> 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 would require semantic analysis, which is not appropriate here.

> 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

I view this example as a non-problem.  Top-level restrictions are a bad idea.

> 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 will not be done.

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

peter

Received on Tuesday, 31 December 2002 08:38:39 UTC