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

Jeff, catching up after the AC meeting, sorry for the delay.

> > 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.
Yes, that was my intent. We could also use "could" (sorry for the pun :), provided we make unambiguously clear what it means
(somebody fussy like me could ask us what we mean by could). Or maybe I'm really too fussy here... anyway, good that we all agree
the intent should be a MAY. The way we better write this is editorial :)

> > 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.
Document = very fine.

> > 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.
What I meant is (sorry I'm being also fussy here) precise interaction with the rest of OWL semantics: we could just say things like
transparent things are just transparent, i.e. they are equivalent (semantically equivalent) to a graph where they are removed. But
on the other hand, a thing I liked about your current deprecation proposal is that you use rdf:type, so you could actually query for
things that are deprecated, using OWL's machinery. So, they could just be treated as normal properties. But then, we should state
what their meaning is in combination with other OWL constructs. For example, can you put more constraint on priorVersion (say), even
if it's sort of "built-in", declare restricted range etc (in other words, changing its possible use)? Can you do things like
<owl:DeprecatedClass> rdf:type <owl:DeprecatedClass> ?
We'd clarify these points.

> > 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.
Errr... why? Ontologies should be allowed to merge, so forcing incompatibility by default doesn't seem like a very good idea (what's
why I had raised the option to signal incompatibility).

> > 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.
You issue ontology v1. After a while, you need to pass to ontology v2, which, alas, is an incompatible version. You therefore might
want to signal that people shouldn't be using v1, but using your v2. The way you'd do it now is by deprecating every single item in
the ontology, which seems heavy. That's where the possibility of deprecating ontologies as a whole would come handy.

> > 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.
Yes, precisely the point.

> 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>

Mmm, this raises an interesting point: how do we propagate deprecation info? From the above, I'd assume that if Car is deprecated,
then the deprecation also propagates to Automobile, as it is declared as equivalent (in other words, deprecation should respect
OWL's equality). The second example is less clear, so we'd be careful on how we define the rules here....
Having an explicit "replacedBy", on the other hand, allows to unambiguously signal to the user agent/ontology tool what is the good
alternative that should be used.
Anyway, I agree this replacedBy could be of marginal use, just trying to get a grasp of the relative importance of the primitives
here. Having a "local deprecation scope", with no propagation, might in fact, even if clashing with OWL logic, be a fine choice (as
we're extra-logical after all). I'll think more about this.

> 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

Received on Tuesday, 26 November 2002 13:59:07 UTC