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

Dan, thanks for the feedback. I have some responses below...

Dan Connolly wrote:
> 

<snip>

> >
> > 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...
> 

That sounds like a good change.

> > This has no meaning in the semantics,
> 
> quibble: no *extra* meaning; i.e. it's just like rdfs:label
> or rdfs:seeAlso.

I can do that, too.

> > 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.

I don't like obsoletes, because it may be the case that some people may
never want to upgrade to the new version. To me, obsoletes has the
connotation that you must stop using the old version.

> 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.

While I think that something like this is an excellent idea for tech
reports, I think it could be dangerous for ontologies. First, of all
what is the generic ontology? Is it just the most recent version, as is
done with tech reports? If so, then if people start using this namespace
and importing this ontology, what happens when a modification is made
that isn't backward compatible? Essentially, it would "break" existing
documents. I'd much rather document authors to be explicit about what
version of an ontology they commit to, and put the burden on them to
upgrade at whatever pace they feel comfortable with.

> 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.

I have a slight preference for the shorter name, but could go the other
way if more of the group preferred it.

> > 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.

I'd like to have a "semantic-free" version in the current draft of OWL.
This will provide people a feature with which they conduct experiments
(like the one you mention above) on real data. I for one, intend to do a
number of semantic-based experiments with it, too. It also allows us to
determine how likely the world is to use such a feature.

> > 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.

Does this mean that you changed your mind as to whether or not this
feature should be included in this version of the language?

> > 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 Thursday, 21 November 2002 10:11:27 UTC