Re: ISSUE-24, ISSUE-21: Versioning language

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Subject: Re: ISSUE-24, ISSUE-21: Versioning language
Date: Wed, 18 Jun 2008 09:48:38 -0400

> On Jun 18, 2008, at 8:50 AM, Peter F. Patel-Schneider wrote:
> 
> > From: Alan Ruttenberg <alanruttenberg@gmail.com>
> >> I'm not thrilled about owl:incompatible with only being able to have the
> >> subject the ontology in the header. This would not have been a
> >> restriction in OWL 1.
> > Yes, but in OWL 1 there were problems with determining which ontology
> > node was the ontology node for the current ontology.  Arbitrary
> > owl:incompatibleWith would bring this back.
> 
> There would still only be one ontologyURI rdf:type owl:Ontology. I'm
> not suggesting that each subject and object of an incompatibleWith has
> an associated type triple. Same situation as with versionURI not
> having one in the current mapping. 

But then what syntactic category are the subject and object of triples
with property owl:incompatibleWith?

> >> I'd rather one be able to specify anywhere that
> >> one ontology version is incompatible with another. I'd suggest
> >> decoupling the incompatibleWith statements from the header by having a
> >> form: IncompatibleOntologies(vu-or-ou1 vu-or-ou2) serialized, in RDF, as
> >> "vu-or-ou1 owl:incompatibleWith vu-or-ou2.", with no logical semantics.
> >> This means that the wording "Furthermore, if the import closure of O
> >> contains ontologies O1 and O2 such that O1 contains an ontology
> >> annotation owl:incompatibleWith with the value equal to either the
> >> ontology or the version URI of O2, then O should be considered
> >> syntactically invalid." needs to be changed.
> >>
> >> I consider to be a separate issue the question of whether all OWL
> >> documents must have an ontology header, and don't consider that issue
> >> resolved yet. However I don't think that issue impacts the wording here.
> >>
> >> These are the substantive issues that I would like to agree to in
> >> principle -
> > Umm which are the substantive issues?  It's not clear to me.
> Changes in the rewritten text other than the wording "typically" or "access".
> 
> >> though not necessary do all the edits - before resolving. I
> >> don't think that they differ from the spirit of what is being proposed,
> >> though better to make sure. In addition there is wordsmithing for
> >> clarity that is a normal part of editing that I will suggest when I
> >> review the documents. I'm not listing details here, just noting that
> >> there is some work to do.
> >>
> >> -Alan
> >>
> >
> > [...]
> >
> >
> >> 3.2
> >>
> >> The ontology and the version URI, if present, determine the physical
> >> location of an ontology O according to the following rules:
> >>
> >> If O contains a version URI then O must contain an Ontology URI.
> >>
> >> If O does not contain an ontology URI
> >> (and, consequently, no version URI),
> >> then O may be physically located anywhere.
> >
> >> If O contains an ontology URI ou but no version URI or contains a
> >> version URI vu that is the same as ou, then O should be physically
> >> located at the location ou.
> >
> > This seems to be covered by the next case perfectly well.  Why bother to
> > duplicate the rules?
> In one case the O *should* be located at ou, and in the other it *may* be located at ou.
> If you say Import(u) then the ontology *should* be located at u, and *may* be located elsewhere but *must not* be accessed from other than u, (modulo the location redirection mechanism)
> 
> To be honest, I'm not sure why the rules are phrased the way they are. It would seem to be much simpler to say say
> 1) Import(u) means access the ontology at u.
> 2) If the accessed ontology has an ou, optional vu that one of them should be u.
> 
> >> If O contains an ontology URI ou and a version URI vu
> >> that are not the same,
> > Remove this qualification to cover the previous case as well.
> >> then O should be physically located at the location vu and may [also] be
> >> physically located at the location ou.
> >
> >> The [current/most recent] version of an ontology series with some URI ou may be
> > It may be that there will be some reason to have a more-recent version
> > of an ontology not be at the main location (perhaps for testing?).
> >> accessed from ou using a suitable Internet protocol. To access a
> >> particular version of ou, one needs to know that version's version URI
> >> vu; then, the ontology should be accessed from vu using a suitable
> >> Internet protocol,
> >> and must not be accessed from ou if ou differs from vu.
> > This last prohibition doesn't make sense.  Either the ontology is also
> > accessible at ou, in which case it may be a bad idea to access it from ou,
> > or the ontology is not accessible at ou, in which case it can't be
> > accessed from ou.  Where then does the "must" come from?
> I'm worried about the case where you have an import that names vu, a
> >> specific version. As I read it, ou, which might be a different
> >> version of the same ontology, might be allowed to be loaded, which
> >> would be incorrect. 

But the document is specifying how importing works, isn't it?  Importing
works by accessing the ontology document at a URI, nothing about
versions, etc.  Why then this must stuff related to versions?

> >> If the document accessed from u contains an ontology URI and
> >> optionally, if it contains a version URI, and neither is u, then the
> >> importing Ontology should be considered syntactically invalid.
> > I disagree with this wording.  The original wording was much better - it
> > left the behaviour of the tool completely open but still noted that
> > there was some weirdness going on.

> The wording was inconsistent with the other wierd cases. For example
> the case where two different ontologies were loaded, or where
> incompatible ontologies were detected, it was considered syntactically
> invalid. Why should this wierdness be handled differently? 

Because it is a different kind of wierdness.  The use of "syntactically
invalid" was previously related to ... syntactic validity.  Importing
incompatible ontologies is, in my view, something different.

[...]

peter

Received on Wednesday, 18 June 2008 16:40:55 UTC