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

On Tue, 2002-11-19 at 10:23, Jeff Heflin wrote:
[...]
> I propose to add the following identifiers to the OWL namespace:
> 
> priorVersion
> backCompatWith
> deprecatedClass
> deprecatedProperty
> 
> In short, none of these identifier will have any impact on the
> semantics, they are all "extra-logical."

Any proposal of this extra-logical form is acceptable to me.

I'm not prepared to 2nd Jeff's propsal as is; I prefer
something a little different.
I won't be at the telcon tomorrow, but I trust
Jeff et. al. will consider this in the decision...
(I have some quibbles with the way jeff
worded his proposal too; more on that below)

We have some implementation experience relevant to
this issue... here's an excerpt of our ontology...

[[[
excerpted from
http://www.w3.org/2000/10/swap/pim/doc
http://www.w3.org/2000/10/swap/pim/doc.n3
http://www.w3.org/2000/10/swap/pim/doc.rdf

# Version management stuff
#
# With these you can build a CVS tree:

doc:versionOf a r:Property;
    s:comment   """This work is a a specific version of the follwing
generic document""";
    s:domain    doc:Work;
    s:range     doc:Work .
    
doc:obsoletes a r:Property;
    s:comment   """This work is more upto date than that and makes it
obsolete.""";
    s:domain    doc:Work;
    s:range     doc:Work .

doc:dependsOn a r:Property;
    s:comment   """The meaning or value of this work depends on that of
that work.""";
    s:domain    doc:Work;
    s:range     doc:Work .

]]]

We use these in our own work to manage evolution of schemas.
Our experience isn't trivial, but it isn't compellingly large
either... i.e. I'm pretty happy with them; they have proved
useful... but I don't have so much experience with them
that I'd say they are The Right Thing.


> I will now describe each of
> these in turn.
> 
> priorVersion
> -------------
> Triple usage: <url> priorVersion <url>

quibble: talking about <url> is sort of a use/mention bug.
It could be a blank node, for one; but I think it's
more useful to talk about the objects in the domain
than about the syntax for referring to them. i.e.

	newDoc priorVersion oldDoc

> The second URL identifies an ontology that is an earlier version of the
> first.

rather:
	oldDoc is an ontology that is an earlier version of newDoc...

> This has no meaning in the semantics,

quibble: no *extra* meaning; i.e. it's just like rdfs:label
or rdfs:seeAlso.

> but could be used by
> software to organize ontologies by versions.

Hmm... your priorVersion is analagous to our obsoletes...
I don't think "obsoletes" is compellingly better
than "priorVersion", but please consider it.

Please consider the versionOf term, i.e. the relationship
between a particular version and the generic versionable
object. ala between the dated version of one of
our tech reports and the "latest version" of it.

For some more background, see some design notes
on Generic Resources
  http://www.w3.org/DesignIssues/Generic


> backCompatWith
> ---------------

I prefer to spell out "Compatible"; i.e. to use
words from the dictionary. That's a rule of thumb;
there's a competing principle that says: if you
make people type more, they're less likely to
use it. <a> isn't called <anchor> for that reason.

> Triple usage: <url> backCompatWith <url>
> 
> The first URL is a later version of the second, and is backward
> compatible with it. In particular, it indicates that all identifiers
> from the previous version have the same intended interpretations in the
> new version.

We did some experimentation in this area
(http://www.w3.org/2001/05ve/), but with terms
that had real semantic meaning; i.e we played with
rules to translate between vocabularies. So my preference is
to postpone backCompatWith until next time, when
we can really attack logic-connected-to-protocols-and-documents.


> Thus it is a hint to document authors that they can safely
> change their documents to commit to the new version (by simply updating
> namespace declarations and imports statements to refer to the URL of the
> new version). Note that this feature has no impact on the semantics.
> 
> This approach does not address the problem described in
> Section 3.2 of the Requirements Document (under RDF(S) Support). There,
> we gave an example where we wanted to "fix" an incorrect definition of
> Dolphin. Solving this problem would require versioning capabilities that
> woiuld affect the semantics, but at this time it is not clear what the
> correct approach would be. A later version of OWL may address this
> issue.

Yes, let's please point out the limitations of this approach
(a) to set expectations correctly and (b) to draw out
feedback on the priority of this possible future version.

> deprecation:
> ---------------
> Triple Usage: 	<classId> rdf:type <owl:DeprecatedClass> or 
> 		<propertyId> rdf:type <owl:DeprecatedProperty>

good stuff.

> Example:
> --------
[...]

good stuff; please included something like it in the guide.

> Additions to http://www.w3.org/2002/07/owl
> --------------------------------------------
[...]

more good stuff.

> [1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0090.html
> [2] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0272.html
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Wednesday, 20 November 2002 11:43:13 UTC