Re: LANG: owl:import - Two Proposals

<quote>
Look, I'm really not trying to be difficult here. I'm not on some
anti-RDF crusade, although I'll admit I'm not a big fan of the language.
In [1], I listed what I consider to be a number of problems with
proposal #2. I haven't heard anyone address any of these concerns. If
these were addressed satisfactorily (perhaps by an alternate proposal)
then I would be happy to endorse that approach.
</quote>
That's because we don't always have the time to write a reply in a reasonable time... (sorry ;)

Let me do a summary: what I said in the last teleconf was essentially an expanded version of the
concise proposal that is in
http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0430.html :

<quote>
Now, to be more constructive (and, all based on the intuitive defs we have for import and versioning), some quick solutions to put
everything "in RDF":
<snip/>
b) import: we can just use a triple
(bnode) -- rdfs:seeAlso --> (URI)
Depending on a precise def of import, we might want to strengthen this using a new rdf:import or the like, that gives the import an
rfc2119-SHOULD state (processors should fetch the RDF content at the URI and incorporate it (merge the graph)).
To be picky, note that because of a), we might be more formal and, in our particular OWL case, use things like
(ontologyURIspace) -- rdfs:seeAlso --> (URI)
gaining in declarativity (and possibly in OWL performance).
</quote>

Jonathan, like he said, missed the last part of the teleconf, but trying to guess
(http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0519.html )
he got again precisely the operational semantics of the proposal (which I think is a good indication that it's not so weird... ;)
The current Proposal #2 is an instantiation of the general solution mentioned above
(the "rfc2119-way"....), plus some added things we'll see below.

Now, to the criticisms of proposal #2:
> Cons:
> - Having valid syntax that has undefined semantics may lead to reduced
> interoperability. In particular, some users may build ontologies that
> rely on the arbitrary decisions made by their favorite tool vendors.
Please note, *Jim* was advocating undefined semantics, I was never saying that, as I'm clearly stated the operational semantics (the
same as Jonathan later guessed :)

> - It is unclear what it should mean if a document C contains the
> statement A owl:imports B. Should this be another undefined construct?
> If so, how can you determine from a graph if the subject of an imports
> statement is the URI of the document from which the imports statement
> comes?
That's because your proposal #2 is too specific (see the more general one above): there are various ways to handle this, to the
simple "import all" or to the complex "base on ontology URIspaces", which is related to the versioning issue (which we haven't
solved/tackled yet).
I'd be very fine with a simple "import all" (i.e., import anytime).

> - The fact that an ontology's classes and properties do not occur
> between the <Ontology> tags is unintuitive
Well, such a "operational import" is more powerful, like an #include in C, therefore it differs from a strict "ontological/logical
definition". Since it's not in the OWL model theory anyway (same as the concept of ontology, yet....), I think this boils just down
to terminologics.

> - The use of about="" to make statements about the enclosing document
> seems like a hack. In particular is seems like we could be confusing the
> notion of a document that describes an ontology and the concept of an
> ontology itself.
Like said above, this is peculiar to the instantiation given in proposal #2.
"Import all" doesn't have this problems.

> - The approach only partially succeeds in its goals, because although it
> represents ontologies and their properties, it loses the ability to
> recognize the boundaries of an ontology (i.e., what it contains) as soon
> as two or more graphs are merged together. In particular, if this
> approach is extended for use with versioning, then we lose the ability
> to know which statements come from which version of an ontology.
Yes, but that's a general problem we have: there's still no way to capture an ontology in RDF so far. I said this is related to the
versioning (even: it's *critical* there), and one reasonable way to do it would be to try give a definition of ontology that is not
"file-based" but "graph-based" (using a combination of URIspaces and graph topology, essentially with a topological neighborhood
using URIspaces...). But anyway, while critical for versioning, it's no critical at all for import, where the simple "import all"
suffices.


On the other hand, a final word on proposal #1: like I said, the biggest con argument I can see there it's the fact it's... not RDF
any more (!), hence any transport and/or manipulation of RDF will lose the import information, which I don't find easily digestible.
The MIME issue is just a side-effect of this bigger pitfall, and Jim is right saying you'd have some troubles with it (more details
at request), but that's one side of the much bigger problem.

So, well, my preference would be for the "operational import", as formulated in
http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0430.html
and there we have two options: either the rfc2119 way, or just reuse rdfs:seeAlso (which would partly take away this potato from us,
at the possible expense of some lack of performance, depending on the import semantics we choose for that (rfc2119 "should" or
weaker).
The current proposal #2 is an instantiation of that, but it has the extra constraint on the subject, which gives the problems we
have seen above, and mixes inbetween JimH's consideration about the "undefined semantics", which I don't agree with too (at least,
the way it's been formulated so far).

-M

Received on Thursday, 3 October 2002 11:34:04 UTC