[PORT] SKOS maintenance policy - 2/2 (substantive comments)

The following comments are about three sections of the SKOS
Core Vocabulary Specification, W3C Editor's Working Draft
of 2005-03-24 [1]: Status of this Document, Introduction,
and Policy Statements.

Tom

[1] http://www.w3.org/2004/02/skos/core/spec/2005-03-24

----

General comments:

1) There is a subtle but important confusion in the text when
   reference is made to "this document".  "This document"
   is sometimes intended to refer to the "latest version"
   (http://www.w3.org/2004/02/skos/core/spec/), and sometimes
   the version of 2005-03-24 (called "this version"; as in:
   "This document is an Editor's Working Draft").  It looks
   to me like the ambiguity could be removed simply by citing
   the precise URI at such points.

2) This policy refers to two ways in which the SKOS
   vocabulary is described:

   -- "human-readably", as a historic series of W3C draft or
      recommended specifications (each one identified with a
      "This version" URI).  The latest version at any given
      moment in time is identified with a "Latest version" URI.

   -- "formally", as a resource in RDF/OWL which is subject
      to continual change and for which no versioning policy
      is mentioned.

   The text very clearly states the intent to maintain the
   ("latest version") RDF/OWL expression and the "latest
   version" human-readable expression in sync at all times
   -- except maybe for an hour or two now and then while a
   Website is being rebuilt.

   However, it is not clear from the text whether either
   expression -- the RDF/OWL or the human-readable -- is
   "authoritative" or "definitive" with respect to the other.
   It is therefore not entirely clear which representation
   should be the object of maintenance, and of recommendation,
   by the BPD WG.  I comment on this in more detail below.

   In a nutshell: It would appear that, in practice, changes
   are made to the RDF/OWL representation, which is used to
   generate an update of the human-readable documentation.
   However, it is on a specific version of the human-readable
   representation ("This version") that the BPD WG is being
   asked to confer some sort of status or recommendation.

   One possible position, I suggest, would be the following:

   -- The "latest version" of the human-readable document
      is the "authoritative" expression of the SKOS Core
      vocabulary at any given point in time.

   -- The "latest version" of the RDF/OWL representation is the
      "definitive RDF/OWL representation" of that authoritative
      human-readable expression at a given point in time.
      In this sense, the fact that the human-readable document
      is generated from the RDF/OWL could be seen merely as
      a practical convenience, for an efficient work flow,
      and not as something which implies that the RDF/OWL is
      definitive and the human-readable is derived.

   -- Status is assigned to historical versions of the
      vocabulary in accordance with W3C process.  This is
      currently done in the context of the BPD WG, but when
      the WG's charter expires, control will revert to W3C
      as an organization.

   I think this is already the intended meaning of the policy,
   but as written, it is not yet expressed quite precisely
   enough.

3) If the summary above is accurate, and the text were
   tweaked a bit, citing explicit URIs here and there, this
   this would satisfy the requirement that a maintenance
   policy "tell it as it is" -- i.e., that it describe the
   institutional circumstances under which the vocabulary
   is maintained.  Therefore, the SKOS spec could AFAIC move
   forward in the context of SW BPD process.  However, I
   think this exercise reveals some weaknesses in the policy
   framework -- areas in which W3C would ideally want to
   clarify how the longer-term maintenance of a vocabulary
   would occur in practice after the SW BPD charter runs out
   (starting with http://www.w3.org/Consortium/Persistence).

4) Some readers will consume this document as a printout (as I
   did).  In the sections on policy, it is particularly
   important to know the URI (URL) of a document or RDF
   schema that is being referred to.  Currently, these
   URLs are hidden from view in a normal printout, though
   they appear in angle brackets in the clear text below.
   I would suggest either adding the URLs for display in-line,
   or providing numbered footnotes for the URLs.

5) The term "namespace" is used twice -- once in the first
   paragraph of Policy Statements and once in the first
   paragraph of Maintenance.  All other references are
   to the SKOS Core Vocabulary (and its URI).  This extra
   term seems needlessly confusing -- one wonders whether
   "control of the SKOS Core namespace" is meant to refer to
   ownership of the domain for the URI of the Vocabulary,
   or to the Vocabulary itself, or both.  My suggestion is
   to drop "namespace" and refer specifically either to the
   Vocabulary or to the URIs associated with the vocabulary.

Specific comments:

| Status of this Document
| 
| This section describes the status of this document at the
| time of its publication. Other documents may supersede
| this document. A list of current W3C publications and the
| latest revision of this technical report can be found in
| the W3C technical reports index <http://www.w3.org/TR/>
| at http://www.w3.org/TR/.

As worded above, the text seems to say (exaggerating a bit):
"This document shows its status as of 2005-03-24.  After that
date, the document could very well be superseded, and the
only way you could find out would be to look in the list of
current W3C publications."

Rather, the section could perhaps explicitly promise to provide
a forward pointer to the document by which it is superseded.

Ideally, at this point, one would point to a policy for
versioning W3C documents generally, but I am not aware that
such a document exists.

|                                .... The group has discussed
| the potential for SKOS to evolve into possible future
| recommendation track work items, and would value feedback on
| the level of formal standardization that is appropriate for
| SKOS-like technology. 

Hmm, "SKOS-like technology"...  Do you mean "appropriate for
RDF vocabularies such as SKOS"?

|                 ..... While the Working Group expectation is
| that SKOS will become a W3C Working Group Note, previous W3C
| Groups have reorganised their deliverables based on deployment
| experience and feedback from the W3C Membership.

This sentence seems to be missing something...  I think the
intent is to say:

    As of the publication of this draft, the Working Group
    expects that SKOS will become a W3C Working Group Note.
    However, other outcomes are possible within the framework
    of W3C process in response to deployment experience and
    feedback from W3C members.

| Introduction
..
| The SKOS Core Vocabulary is itself formally
| defined using RDF and OWL [OWL]. The resource
| http://www.w3.org/2004/02/skos/core.rdf contains the definitive
| SKOS Core Vocabulary RDF/OWL description.
| 
| This specification is intended to provide the authoritative
| human-readable account of the SKOS Core Vocabulary, and
| to reflect the state of the of SKOS Core Vocabulary at the
| time of publication. The content of the term summary tables
| in this specification is generated [SRC] from the SKOS Core
| Vocabulary RDF/OWL description on the date of publication of
| this document.

On a careful re-reading of the text above, it is not quite
clear to me which representation of the SKOS Core Vocabulary
is definitive and authoritative:

-- The vocabulary is "formally defined" in RDF/OWL, and the
   definitive version of that formal definition is in the
   resource http://www.w3.org/2004/02/skos/core.rdf.  It is
   not clear whether this is the "definitive" version of the
   SKOS vocabulary itself or just the definitive version of
   the RDF/OWL description thereof.  At any rate, the resource
   defined by http://www.w3.org/2004/02/skos/core.rdf would
   appear to be a "latest version" -- i.e., subject to
   editorial change.

-- The vocabulary is expressed human-readably in the "latest
   version" of the specification document,
   http://www.w3.org/2004/02/skos/core/spec/ (however, as
   pointed out above, "this specification" is an ambiguous
   way to put this).  It is not clear whether this "latest
   version" is the "authoritative" version of the SKOS
   vocabulary itself or just the authoritative version of
   the human-readable description thereof (e.g., because
   the human-readable description "reflects" the definitive
   RDF/OWL description from which it is "generated").

| Because the SKOS Core Vocabulary may change (see Change
| Policy Statement below), there may be inconsistencies
| between this document and the SKOS Core Vocabulary RDF/OWL
| description. 

See General Point 3 above: In this case, the intention is
to cite the "latest version", because as soon as any change
is made to the RDF/OWL description, this particular version
("this version") of the editor's draft will henceforth forever
be out of sync.

|         .... The latest version of the SKOS Core Vocabulary
| Specification <http://www.w3.org/2004/02/skos/core/spec/>
| should accurately reflect the current state of the SKOS Core
| Vocabulary RDF/OWL description, although there still may on
| occasion be short periods (eg. during Web site publication)
| during which there are minor inconsistencies.

This is fine, though it could be just a bit clearer by
saying that the latest version of the vocabulary spec should
accurately reflect the "latest version" of the SKOS Core
Vocabulary RDF/OWL description.

| Although the SKOS Core Vocabulary RDF/OWL description is not
| itself a W3C Technical Report, it is (at least for the lifetime
| of the Semantic Web Best Practices WG) being managed with the
| intent of being consistent with this document, as well as with
| other supporting materials published as W3C Technical Reports.

Okay, this is a crucial point, and it is fine, except it does
not answer the question of which version -- the RDF/OWL or
the human-readable -- is authoritative (General Point 2 above).

| The local name of a class always starts with an uppercase
| character.  Where the local name is comprised of multiple
| concatenated words, the leading character of each word will
| be an uppercase character. E.g.
| 
|     Concept
|     ConceptScheme

It is worth noting that "local name" is not actually one of
the properties of a SKOS vocabulary term -- at any rate,
it is not listed as such in the Term Summary Table -- a
potential though perhaps minor source of confusion.

| Persistence
| 
| This document, the SKOS Core Guide, the RDF description of
| the SKOS Core Vocabulary, and the classes and properties of
| the SKOS Core Vocabulary are all declared to be persistent
| resources, as defined by the persistence policy at
| http://www.w3.org/Consortium/Persistence.

Suggestion: to cite the URI -- either in-line or in a
Bibliography -- for each resource referred to.  In this case,
"this document" is presumably "this version".

| Change
| 
| Changes to SKOS Core classes and properties may
| occur. All changes are reported on the SKOS Change Log
| <http://esw.w3.org/mt/esw/archives/cat_skos_changelog.html>.

As with other URIs, should be cited visibly, in-line, or 
with a footnote.

| Each class or property is assigned a term status value,
| which indicates the stability of the resource, and the types
| of modification that are allowed [DCMI Namespace]. A class
| or property may take one of three term status values:
| 
| unstable
| 
|     The term is unstable, and feedback is welcomed on it's
|     current form and utility (analogous to 'alpha' release
|     in software development).  It may currently be poorly
|     defined. its meaning and/or form may be expected to change
|     at any time. Do not implement mission critical systems
|     that depend on this term persisting in its current form.
|     (Changes corresponding to DCMI class A, B or C may occur).

"DCMI class" is not explained here.  Suggestion: just add
half a sentence to the effect that the policy outlined here
follows the example of the DCMI Namespace Policy, which is
already cited.

|                 ... It should be noted that claims made
| by the Working Group using the (experimental) persistence
| and change terminology employed here have as their scope
| the currently chartered Working Group. They have only draft
| status within the wider W3C Process. W3C has not delegated
| to the WG any authority to make binding commitments on behalf
| of W3C beyond those implicit in the formal W3C Process.
| 
| The Working Group is committed to a public, consensus-driven
| design environment for SKOS Core, and to this end conducts
| SKOS-related discussion in public, in particular drawing on
| feedback from the Semantic Web Interest Group mailing list
| public-esw-thes@w3.org.

This is good, though as I mention above it is vague about what
would happen with the vocabulary when the BPD charter runs out.


-- 
Dr. Thomas Baker                        Thomas.Baker@izb.fraunhofer.de
Institutszentrum Schloss Birlinghoven         mobile +49-160-9664-2129
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                    fax +49-2241-144-2352
Personal email: thbaker79@alumni.amherst.edu

Received on Wednesday, 30 March 2005 16:01:23 UTC