RE: OWL, XML-RDF and Imports

(Also respecting Peter's proposal to reopen the imports issue
I am not sure if this msg supports or opposes that).

> Roughly put, an OWL-Full document an OWL-Lite/DL document if [1]:
>
> o the collections of URI references of classes, object properties,
>   datatype properties and individuals are all disjoint.
> o all individuals are typed.
> o all properties must be explicitly typed as object or data properties.
> o everything's well-formed, e.g. restrictions must have a single
>   owl:onProperty and one of (someValuesFrom|allValuesFrom|cardinality).
> o none of the OWL, RDF or RDFS vocabulary has been abused.


(Aside: IMO we do need to make this *roughly* much closer to the reality).

> Ex 1)
> -----
>
> Ontology A contains the triples:
> -------------------------------
> A owl:imports B
> x rdf:type owl:Thing
> p rdf:type owl:ObjectProperty
> x p y
> -------------------------------
>
> Ontology B
> -------------------------------
> B owl:imports A
> y rdf:type owl:Thing
> p rdf:type owl:ObjectProperty
> x p y
> -------------------------------

I do not really see a problem here.
You do the imports and then you work out which species you are.

> Ex 2)
> -----
>
> Similar to 1), but with the added complication that new we're spreading
> the well-formedness of a single expression through two ontologies
>
> Ontology A
> -------------------------------
> A owl:imports B
> p rdf:type owl:ObjectProperty
> C rdf:type owl:Class
> D rdf:type owl:Class
> C rdfs:subClassOf R
> R rdf:type owl:Restriction
> R owl:onProperty p
> -------------------------------
>
> Ontology B
> -------------------------------
> R owl:allValuesFrom D
> -------------------------------

This can only work if R is a URIref (bNodes cannot be shared between
graphs).
Hence both are in Full.


> For example, if I'm building an editor that wants to be able to support
> modularisation and maintain information in a sensible fashion, situations
> like 2) above are really going to confuse it. Somewhere I want to be able
> to record the fact that C is a subclass of (some p D), but where is this
> information actually held? In A? In B? If I'm ever going to have any
> chance of round tripping this stuff I'm going to have to keep a whole load
> of information hanging around. The split across the two ontologies is too
> fine-grained -- at the level of triples rather than actual conceptual
> "chunks" of the ontology.

What is a conceptual chunk - the design as stand, with a small amount of
cleaning up, has chunks consisting of:

(A) type triples with uriref subjects
(B) blank nodes representing individuals (distinguished by their type
triples)
(C) blank nodes representing complex constructs, which must be well-formed
within a single RDF/XML document, also distinguihed by their type triples
(D) triples representing a single conceptual chunk concerning one, two or
three of the nodes identified in (A) (B) and (C).

This is significantly clearer in my account of OWL Syntax as triples than in
the published specs.

The fact that C in one RDF/XML document is a subclass of D in some other
RDF/XML document where both lie in the imports closure seems to be related
to any document which imports both of them. When there are circles like your
first example, this is difficult. Often we will find that the document
defining C imports the document defining D, and then this fact seems most
naturally related with the document defining C.
>
> A Proposal
> ==========
>
> A possible solution would be to place further restrictions on the allowed
> triples in an RDF-XML representation of an OWL ontology. For example, we
> could require that all the conditions regarding the typing of URI refs and
> well-formedness are "locally enforced", i.e. all the necessary bits are
> present even when disregarding the imports statements.
>
> This seems to be a sensible thing to do --

It makes OWL Lite and OWL DL really quite unnatural to use e.g.

FileA:
<p> rdf:type owl:ObjectProperty .
... definition of <p> in more detail

FileB:
<FileB> owl:imports <FileA> .
_:a rdf:type owl:Thing .
<x> rdf:type owl:Thing .
_:a <p> <x> .


Sean's proposal is that we additionally need to repeat
<p> rdf:type owl:ObejctProperty .
in FileB.

This suffers from the following defects:
- does not fit the C #include or Java imports paradigm, where the type
information is imported; hence presenting greater difficulty to communicate
and learn
- not robust. The current design will flag as an undeclared property error
the case where the user forgot the imports statement, or misubderstood the
nested imports. Under seans proposal the definition of <p> gets lost
silently (since <p> has to be declared locally).


>
> My guess is that even if something along these lines is not present, tools
> will by default enforce some kind of similar conditions. Without it, it's
> near impossible to guarantee that you can work with the modules
> independently (which will be, in my opinion, a requirement of tools).
>

Modules need to know something about the modules they import - that is
natural.
import cycles clearly make that harder.

===

I think there is something a little broken which is having imports and
imports closure defined as an operation in the abstract syntax. The examples
of importing declarations do have RDF/XML documents that do not naturally
correspond to the obvious abstract syntax document. I prefer a framework in
which an abstract document *is* already the imports closure. But this is
really not important enough to merit a reopening of the issue.

Jeremy

Received on Monday, 17 February 2003 03:59:05 UTC