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

> > 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.
It's not difficult to clarify this, anyway the problem I was hinting at is slightly different from normal RDFS properties, as here
the proposed semantics is extra-logical. If you want, it's a problem common to all the so-called "extra-logical" (aka "transparent")
properties like this. So we can state that simply, general OWL semantics rules apply for the owl:deprecatedClass property (but they
don't affect at all the "versioning" meaning of DeprecatedClass, which is just extracted locally). Or we could state these are just
totally transparent as far as OWL semantics rules (entailment) is concerned. Plus looping samples like the above (which again, could
be declared void as far as versioning information is concerned), which could give trouble even at the extra-logical level only. In
any case we have to be clear about their behaviour in the specs.

> > > > 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.
Because even if we decide the above implication is true, the reverse doesn't apply: so, in order to properly define incompatibility,
we need a separate predicate. In other words, it might just be that you need to declare that some ontology is incompatible with
another one, even if they are not priorVersion's one another.
Note I'm not advocating we need this in v1, just putting this into the set of candidates for v1, for us to pick up the ones we think
ought to be in v1.

> > 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?
Because deprecation is an orthogonal axis wrt priorversion and backward compatibility. In other words, you can't logically define
deprecation from the other two properties. So, for example, you could have  a deprecated version that is in priorversion with a
backward-compatible version. Again, disclaimer as above: just putting this feature in the set of candidates.

<snip/>
> > 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?
Let me rephrase, because DanC also replied like this, but the question was not this one:
mathematically speaking, the two things are orthogonal, as one is OWL entailment semantics, and the other one is extra-logical. So
as said, we could well decide to have a "local deprecation scope", hence not interacting with the OWL entailment semantics. The
question is what we decide to do, based on what looks more elegant/productive. Either way we go, we should warn the users in the
Guide and/or in the main spec.
Now, back from the "digression" :) : the main point from which this stemmed is the "replacedBy". One advantage of having it
explicitly is that, even going with a local deprecation scoping, one would have in absentia to plug in all the related definitions,
which might in fact be catched automatically/seamlessly if an explicit replacedBy were used.
Again, disclaimer: just putting this into the pool of candidates for v1: it might be the use cases for this are not worth the effort
(after all we can't stuff everything in v1, and there's always v2 ;).

-M

Received on Tuesday, 3 December 2002 12:36:52 UTC