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

From: Alan Ruttenberg <>
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 <>
> >> 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.



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