[VM] Review of 16 March Editor's Draft

Comments on 

    Principles of Good Practice for Managing RDF 
    Vocabularies and OWL Ontologies
    Editor's Draft 16 March 2008 [1].

It's great to see this draft move forward.

In my comments, there are some minor points about style
and emphasis but also a few substantive points which, in my
opinion, require some further discussion and explicit consensus
from this group before publishing as a Working Draft.

1. I agree with Ralph [2] that the notions of "Web ontology",
   "OWL ontology", and "RDF vocabulary" need to be clarified.
   In particular, there remains an apparent contradiction between
   Section 1, first sentence:

        An RDF vocabulary is a set of resources denoted by URIs. 

   and Section 2.1, first sentence:

        An RDF vocabulary consists of a set of URIs.

   Attention has been drawn to this apparent contradiction
   in various BPD and SWD telecons over the years; it's
   still there in the draft; and I must admit that I still
   do not entirely grasp its implications.  The 2004 RDF
   Recommendation documents say, for example (from Primer):
   "Since RDF uses URIrefs instead of words to name things in
   statements, RDF refers to a set of URIrefs (particularly
   a set intended for a specific purpose) as a vocabulary."

   This draft should at any rate explain this group's
   understanding of what an "RDF vocabulary" is -- for example,
   compared to "_the_ RDF vocabulary" or an "OWL ontology", and
   saying whether its URIs (or URIrefs??) "are" or "denote"
   the terms of the vocabulary.  If that position contradicts,
   or seems to contradict, the position in other current
   RDF documents, then the draft should point this out
   somehow, citing relevant sources.

2. The draft says that resources in an RDF vocabulary will
   "usually (but not necessarily) be of type rdf:Property,
   rdfs:Class, owl:Class, or skos:Concept."   Maybe this
   is close enough, but can we define the universe of RDF
   vocabularies more precisely?  Would a vocabulary declaring
   things to be ex:Property, where ex:Property has no declared
   relation to rdf:Property, be an RDF vocabulary?

   Can we say that the relationship to _the_ two main RDF
   and RDFS vocabularies is a defining characteristic of RDF
   vocabularies?  To my way of thinking, an RDF schema has
   the function of declaring an ontological commitment for
   how the resources described therein fit into the RDF/RDFS
   model -- saying, in essence, "this thing here is a Property
   as defined by the RDF specification", and "this thing here
   is a Class".  If the classes of OWL ontologies and SKOS
   concept schemes are subsets of the class of RDF vocabularies
   (Ralph put it the other way around in [2]...?), then all
   RDF vocabularies have the function of relating their terms,
   ultimately, to the RDF/RDFS model.

   Can we agree on this, and should the note say this more
   clearly?

3. A few stylistic points: 
   -- suggest avoiding "we" (e.g., Section 2, paragraph 2)
   -- "Web" should always be uppercase here
   -- suggest avoiding constructs such as "owner(s)" and
      "developers/maintainers"

4. I suggest dropping the reference to CORES resolution,
   which reports on discussions as of 2002 and is now dated.

5. The section Status of this Document cites things that
   seem out of scope for a Status section, such as references 
   to Web applications.

6. Introduction, fourth paragraph. It is not clear to me why
   portals are highlighted so prominently in the Introduction.
   The paragraph says that "repositories" supply additional
   metadata that is "almost as important as the vocabulary
   itself".  This seems to emphasize the importance of
   third-party contextual information (in this case from a
   Web application) for using a vocabulary.  I had assumed
   we would want to emphasize a "follow your nose" approach
   as the main take-home message, and this appears to point
   in another direction.

7. Section 2.1, paragraph 7 on "URI schemes".
   W3C uses HTTP URIs (and not, for example, "info:" URIs).
   What is meant here by "URI schemes", I think, is methods
   for constructing URI strings.  However, I think we need
   to be emphasizing the principle of URI opacity [3].
   Does the example encourage vocabulary managers to design
   URIs which embed enough information in their strings to
   "assist potential users in finding various artifacts on
   [a Web] site" (or am I perhaps misunderstanding the point
   of the example)?

8. Section 2.2, "Provide Readable Documentation", final
   paragraphs.  The paragraph-long descriptions of specific
   tools for change management seem a bit out-of-place here.
   It is good to say that documentation should also cover
   changes, but the focus on specific tool functionalities
   and interfaces distracts from that point.  The general
   point about tracking, documenting, and annotating changes
   is perhaps a better fit to the section on versions.

9. Section 2.3, last paragraph.  Section 2.3 is about
   articulating maintenance policies for "RDF vocabularies",
   but the list covers vocabularies "and other artifacts
   that have a published maintenance policy".  The list
   mixes two different types of thing -- the SKOS, DCMI, and
   OWL vocabularies; and artifacts that are not themselves
   vocabularies (the URIs for W3C Namespaces guide and the
   Catalog of OMG Specifications).  Instead of references to
   "vocabularies covered by policies", perhaps the list should
   reference policy documents themselves, such as [4].  This
   however raises the question of what to cite for SKOS; see 
   next point...

10. Section 2.3.1, Maintenance policies for SKOS.  This
   section is particularly relevant in light of the proposal
   currently on the table for handling deprecated properties
   [5] and our discussion on Tuesday [6].

   The SKOS Core Vocabulary Specification WD of 10 May
   2005 (not yet actually cited in the draft) has a Policy
   Statement [7] that as yet has no equivalent in the current
   SKOS Reference.  If we want to publish a note advising
   vocabulary maintainers to "Articulate Maintenance Policies",
   then somewhere we need to record our positions on these
   issues with regard to SKOS.  I think we should do so in the
   SKOS Reference itself.  Indeed, if we were not to move this
   forward, we would perhaps need to remove the discussion
   of SKOS from the Vocabulary Management note altogether,
   else we be in the position of citing an obsoleted document
   as an example of good practice for maintenance policy.

   Discussion of the Vocabulary Management note in Washington
   will be limited to just one or two hours, however any
   discussion we would have on SKOS policies would be directly
   reusable in this context.

11. Section 3, Research Topics.  Section 3 is devoted to
   describing topics of advanced research in reasoning.
   As this section amounts to one fifth of the draft's body,
   I have a concern about the message it sends.  To my way
   of thinking, very high-level principles such as "provide
   documentation" aim at encouraging newcomers to take the
   plunge and publish a vocabulary.  The emphasis here on
   advanced research seems to raise the bar,
   or at any rate it sends the message that RDF vocabularies
   can be intimidatingly complicated.  It is also the section
   of the draft which will gost quickly go out of date.
   My preference would be to de-emphasize open research
   issues in favor of the simple principles.

Tom

[1] http://www.w3.org/2006/07/SWD/Vocab/principles-20080316
[2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0030.html
[3] http://www.w3.org/TR/webarch/#uri-opacity
[4] http://dublincore.org/documents/dcmi-namespace/
[5] http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0032.html
[6] http://www.w3.org/2008/04/08-swd-minutes.html#item03
[7] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20050510/#secPolicies

-- 
Tom Baker - tbaker@tbaker.de - baker@sub.uni-goettingen.de

Received on Thursday, 10 April 2008 12:16:50 UTC