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

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.

>> 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.
>
>> 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?
>
>
>> 3.4
>>
>> Figure 1 presents the logical view of the import relation, which  
>> holds
>> between two ontologies. In concrete syntaxes, however, the importing
>> ontology only contains a URI identifying the location of the imported
>> ontology. This location should be interpreted as specified in Section
>> 3.2 in order to access the imported ontology.
>>

Received on Wednesday, 18 June 2008 13:49:17 UTC