W3C home > Mailing lists > Public > www-webont-wg@w3.org > September 2002

Re: ISSUE 5.14 - Ontology versioning

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Wed, 11 Sep 2002 16:19:53 -0400
Message-ID: <3D7FA569.F954A229@cse.lehigh.edu>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
CC: WebOnt <www-webont-wg@w3.org>

"Peter F. Patel-Schneider" wrote:
> 
> From: Jeff Heflin <heflin@cse.lehigh.edu>
> Subject: Re: ISSUE 5.14 - Ontology versioning
> Date: Tue, 10 Sep 2002 16:33:55 -0400
> 
> > "Peter F. Patel-Schneider" wrote:
> > >
> > > From: Jeff Heflin <heflin@cse.lehigh.edu>
> 
> [...]
> 
> > > > Assuming A backCompatWith B, then:
> > > > * A priorVersion B.
> > > > * all classes in B are the sameClassAs a class in A with the same ID.
> > > > * all properties in B are the samePropertyAs a  property in A with the
> > > > same ID.
> > > > Note this depends on the resolution of the synonym issue (I prefer
> > > > sameAs for both classes and properties).
> > >
> > > It also needs a treatment of KBs as resources to work in a semantic
> > > fashion.  Otherwise it is more ``magic'' syntax.  (I think that it *should*
> > > be magic syntax.)
> >
> > I agree that these properties should all be "dark" in some sense (if
> > that's what you mean by "magic syntax"). The semantics of backCompatWith
> > are those of the sameXXXAs properties that it is syntactic sugar for.
> 
> But you need a semantic account of the relationship between backCompatWith
> and this collection of sameXXXAs properties.  Where is this going to come
> from?
> 
> > > [...]
> > >
> > > > Deprecation:
> > > > -------------
> > > > <url> deprecates <classId>
> > > > <url> deprecates <propertyId>
> > > >
> > > > This allows an ontology to deprecate a class or property. By deprecating
> > > > the term, it means it still is sameAs a term with the same ID in the new
> > > > ontology, but that the term should not be used in new ontologies. This
> > > > allows an ontology to maintain backward-compatibility while phasing out
> > > > old vocabulary. Deprecation should only be used in ontologies that are
> > > > backward-compatible.
> > >
> > > This is now in the area of pragmatics.
> >
> > Maybe so, but then I say below that it should have no effect on
> > semantics. Are you suggesting that we should not have a deprecation
> > feature because it is a pragmatic issue? If so, I would argue that is
> > useful in versioning distributed software, and if we want the Semantic
> > Web to work in practice as well as theory, we would be wise to include
> > something like it.
> >
> > >
> > > > This has no effect on the semantics, but authoring tools should use it
> > > > in error checking OWL markup.
> 
> As long as there is no semantic impact, then nothing needs to be done in
> the semantics.  However, if you want to use deprecates to do things like
> break the effects of imports, then it has semantic impact and has to be
> dealt with.

I don't think deprecates should break the effect of imports. If an old
document commits to an old ontology and uses a deprecated concept, then
that should be the document owner's perogative. Keep in mind that often
the document owner and the ontology owner are distinct individuals and
it is the ontology owner who decides on deprecation. Document owners
should be free to use old ontologies if they wish and can upgrade at
their own pace or even not at all.

> [...]
> 
> peter
Received on Wednesday, 11 September 2002 16:19:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:52 GMT