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


Just now getting 'round to catching up on WebOnt e-mail. My responses
are below:

Massimo Marchiori wrote:
> 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.

These are good questions that I think apply to any RDF(S) properties.
For example, can someone state a rdfs:domain or rdfs:range of
rdfs:subClassOf, thereby restricting the set of classes that could be
used with it (or perhaps even making the set empty)? Can someone say
rdfs:Class is a rdfs:subClassOf rdf:Property? My guess is that the model
theorists would tell us of course you can do these things, but you
really shouldn't (Pat or Peter, care to comment?) I believe that
whatever we decide for other language-defined properties and classes
will work equally well for the versioning properties and classes.

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

Backward-compatibility is only a relation that can hold between two
versions of the same ontology. I should have been clearer and said that
if one ontology is a priorVersion of another and backward-compatibility
is not declared, then incompatibility should be assumed. The ontology
author is the one who knows best whether the two versions are
incompatible, so I don't see how merging has anything to do with it.

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

If you create a new version of an ontology, then that alone is a signal
that you believe people should be using that version. What benefit does
deprecating the previous version add?

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

Massimo, this is a really good point that I hadn't considered. If
Automobile is the sameClassAs Car, and Car is a subClassOf
DeprecatedClass does that make Automobile a DeprecatedClass? If so, then
my example is broken. However, I don't think the semantics work that
way. I've looked at our semantic documents and it seems that
owl:sameClassAs only means that two classes have the same extension
(i.e., they have the same members). As far as I can tell, it says
nothing about whether properties of the classes are the same. Pat or
Peter, can you correct me if I'm wrong on this?


Received on Tuesday, 3 December 2002 10:06:53 UTC