Re: LANG: Proposal to close ontology versioning (ISSUE 5.14)

Massimo Marchiori wrote:
> 
> Here, extra-logical = good, so thumbs up.
> As far as the specific wording is concerned, it's ok with me if we go with an rfc2119-MAY. If rfc2119-SHOULD is asked instead, then
> I would be concerned.
> (The alternative, is to just be fuzzy on the conformance issues lurking here).

I'm not sure what the "MAY" or "SHOULD" apply to in this case. Are you
talking about things such as "how software could use a particular
feature." If so, would you prefer me to say things like: "The
priorVersion property has no meaning in the semantics, but software MAY
use this feature to organize ontologies by versions?" (Note, MAY instead
of "could" to go with the rfc2119 terminology). If so, I agree that this
would be a good wording change.

> 
> Other editorial points to be clarified in the proposal are:
> 1) the meaning of <url> in priorVersion and backCompatWith (we started discussing
>   this time ago....;), i.e. whether they refer to a file-based def or to a (onto-)logical-based def.

I think they refer to a document. Dan has suggested some wording changes
that I think improve it.

> 2) the general behavour of such extra-logical predicates (eg what happen when they are involved with other properties/subclassed
> etc.

Since they don't have any additional semantics, I think you can subclass
and subproperty them as with any other RDF.

> 
> Finally, there could be some thought on the core set of primitives we need for this.
> For example, do we need primitives to
> a) signal INcompatibility?

My opinion is that if backward-compatibility is not declared, then
incompatibility should be assumed.

> b) deprecate ontologies as a whole (now this is quite heavy to do....)?

Deprecation is generally something that is done to maintain backward
compatibility. I'm not sure what the point of deprecating an entire
ontology is. I suppose if the ontology was going to be deleted at a
later date, then you might want to warn users. However, my opinion on
ontology versioning is that publicly shared ontologies should never be
deleted.

> c) signal, in case of deprecation, what class/property/ontology should be used instead?

That's an interesting idea. If we had a property such as "replacedBy" or
"supercededBy" that can be used with deprecated properties in classes,
it would be possible to have software that could perform automatic
upgrades to OWL documents that use the old version of the ontology.
However, not all changes would be simple name changes. For example, the
new property might reverse the arguments, or what was represented with a
class might now be represented as a property value, etc. It seems that
what we are really talking about is ontology translation here. We
already have a number of primitives that can perform partial ontology
translation, e.g., subClassOf, subPropertyOf, sameClassAs,
samePropertyAs, inverseOf, etc. I think using these features would be
better. For example, I had said:

<!-- assume Automobile is now the preferred term for Car -->
<owl:DeprecatedClass rdf:ID="Car" />

<owl:Class rdf:ID="Automobile">
   <owl:sameClassAs resource="#Car" />
</owl:Class>

Note, the use of sameClassAs to related Automobile to the old term Car.
We could also do something like:

<owl:DeprecatedProperty rdf:ID="hasDriver" />

<owl:Property rdf:ID="drives" >
   <owl:inverseOf resource="#hasDriver" />
</owl:Property>

Even more complex expressions could be allowed as well. This seems much
more powerful than simply signaling the replacement, although it may be
less obvious to the casual reader. What do you think?

> All these can be sustained by use cases, as it is easy to see.
> What core primitives do we need among these + the other 4 proposed (now, in v1)?
> 
> -M

Jeff

Received on Thursday, 21 November 2002 11:13:35 UTC