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: Tue, 10 Sep 2002 16:48:56 -0400
Message-ID: <3D7E5AB8.689D1749@cse.lehigh.edu>
To: Mike Dean <mdean@bbn.com>
CC: WebOnt <www-webont-wg@w3.org>

Mike Dean wrote:
> > <url> priorVersion <url>.
> > <url> backCompatWith <url>.
> I assume
>   owl:priorVersion rdfs:domain owl:Ontology
>   owl:priorVersion rdfs:range owl:Ontology
>   owl:backCompatWith rdfs:domain owl:Ontology
>   owl:backCompatWith rdfs:range owl:Ontology


> > Assuming A backCompatWith B, then:
> > * A priorVersion B.
> I assume
>   owl:backCompatWith rdfs:subPropertyOf owl:priorVersion


> > <url> deprecates <classId>
> > <url> deprecates <propertyId>
> I'd prefer to view deprecation as a unary predicate on a
> class or property.  Unary predicates are implemented as
> Classes in RDF/OWL, so I'd introduce a class owl:Deprecated,
> used as
>   myont:myClass rdf:type owl:Class
>   myont:myClass rdf:type owl:Deprecated
> owl:Deprecated might also be applied to owl:Ontology
> instances.

That could work as well, but I think it makes it a little more difficult
to figure out which ontology deprecated a class or property. For
example, someone may be perfectly happy using version 1.0 of an ontology
even though version 2.0 deprecates many of its IDs. In order to suppress
warning (or error) messages when the user marks documents up using
version 1.0, the tools must be able to determine that the deprecation
happened in a later and not a prior version. In order to do this in your
approach, applications would be required to maintain the source ontology
for every RDF statement, while in mine the statement itself contains the
necessary information.

>         Mike
Received on Tuesday, 10 September 2002 16:49:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:47 UTC