Schema Versioning

In the RDF Schema specification, section 1.2.1 (Versioning and URI
references) identifies problems of change management for schema docs.
However, it skirts the issue by suggesting that the problem is not in the
scope of the spec.

I envisage that if RDF becomes widely accepted, the versioning problem will
rear its ugly head sooner rather than later.  I would like to see the
problem addressed so that there is a comprehensive, standard way of the RDF
community dealing with such issues.  

It will seriously detract from the use of RDF if a plethora of versioning
schemes find their way into RDF schemas making consistent, predictable
schema processing nearly imposible.  Standard RDF schema versioning
facilities would set out exactly how to treat versioning, and would allow
RDF processors to behave more intelligently towards these issues, even if
this is as simple as issuing an intelligible warning.

IMHO putting changes into totally new schemas gets around problems with
versioning, but implies that once a schema is published it must be available
(and hence supported) forever more.

I suggest the introduction of a 'deprecated' property that allows schema
publishers to indicate that RDF classes or indeed whole schemas will be
deleted at some point in the future.  This would provide a procedure for
them to withdraw elements / schemas after a sufficient time lag:

<rdf:Property ID="deprecated"
        rdfs:label="deprecated"
        rdfs:comment="A date indicating when a resource was deprecated"
        rdfs:range="#Literal"/>

<rdf:Property ID="terminates"
        rdfs:label="terminates"
        rdfs:comment="A date indicating when a resource will be terminated"
        rdfs:range="#Literal"/>

Also, it might be a good idea to incorporate other change management
properties, such as 'obsoletedBy', 'supercedes', etc.  (These examples
inspired by the RFC change management conventions).


regards

Lee Jonas

Received on Tuesday, 1 August 2000 06:18:40 UTC