RE: [VM] Review of 16 March Editor's Draft

> It's great to see this draft move forward.


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

Yes, this contradiction must be dealt with before publication, I think.

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

The RDF semantics [1] is unequivocal, from section 0.3:

A name is a URI reference or a literal. These are the expressions that need
to be assigned a meaning by an interpretation


A set of names is referred to as a vocabulary. The vocabulary of a graph is
the set of names which occur as the subject, predicate or object of any
triple in the graph.

Grasping the disctinction between the syntax of RDF and its model-theoretic
semantics has, for me, been extremely valuable. I recommend using the word
"vocabulary" strictly in the sense used at [1] (i.e. as meaning a set of
names), because it helps to reinforce the distinction between an RDF graph
(a set of triples) and its interpretation (the set of resources, and the
sets classes, properties and their extensions).

>From the OWL semantics [2], section 3.1:

An OWL vocabulary V consists of a set of literals VL and seven sets of URI
references, VC, VD, VI, VDP, VIP, VAP, and VO...

I.e. [2] is again clear that a vocabulary is a set of names. 

However, again from [2], section 2.1:

An OWL ontology in the abstract syntax contains a sequence of annotations,
axioms, and facts.

So the notion of an OWL ontology, strictly speaking, is quite different from
the notion of a vocabulary. The notion of an OWL ontology, as defined at
[2], is something akin to a document, and as such is much closer to the
notion of an RDF graph than to the notion of an RDF vocabulary.

To sum up:
 * "RDF vocabulary" and "OWL vocabulary" mean something very similar (a set
of names)
 * "RDF graph" and "OWL ontology" mean something fairly similar (a set of
assertions, more or less) 

The word "term" is problematic, as illustrated very nicely in Tom's comment
above. You could use "term" in a strict sense to be synonymous with "name",
but then you might as well use "name" instead. I recommend avoiding "term"




Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
United Kingdom
Tel: +44 (0)1865 281993

> 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]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> 20050510/#secPolicies
> --
> Tom Baker - -

Received on Friday, 11 April 2008 10:34:03 UTC