Re: [ALL] PORT documents for internal review - 2/2

Some finer points of wording and presentation:

1. As I pointed out in an earlier posting, this draft should
   point back to the earlier SKOS guide (which confusingly
   called itself Version 1.0) and the relationship between
   the two should be clarified.

2. The acronyms in References should perhaps be in alphabetical
   order.

3. Is "Semantic Web" supposed to be capitalized or is the
   capitalization optional?  What is W3C practice in this 
   regard?

4. Some of the URI references used in the examples of SKOS
   Core Guide seem odd.  For example:

         http://www.example.com/bananas#concept
         http://www.example.com/wetness#concept

   According to the RDF Primer, "#" indicates that what
   follows is a fragment identifier. The Primer itself uses
   URIrefs such as:

         http://www.w3.org/2000/10/swap/pim/contact#mailbox
         http://www.w3.org/2000/10/swap/pim/contact#personalTitle

   meaning something like:

         the property "mailbox" in the "contact" vocabulary
         the property "personalTitle" in the "contact" vocabulary.

   Never mind that URIrefs are in principle opaque...!
   Following the RDF Primer example, one might take the
   SKOS Core examples above to mean something like:

         the concept of "concept" in the "bananas" vocabulary
         the concept of "concept" in the "wetness" vocabulary

   instead of what was probably intended:

         the concept of "bananas" in an example vocabulary
         the concept of "wetness" in an example vocabulary.

5. The "Term Summary Tables" (page 3 of the Vocabulary
   Specification) are similar to the set of "term attributes"
   used to describe DCMI metadata terms (see Introduction
   to [1]).  As I have discussed with Alistair, it would
   be nice if Dublin Core, SKOS, and perhaps FOAF could
   converge to some extent on a set of attributes (and their
   RDF expressions) that could be offered as a model to
   maintainers of other vocabularies.  I will be interested
   to pursue whether this would be a good topic for a future
   SWBPD note by the Vocabulary Management group.

6. The phrase "extending SKOS Core" seems problematic for
   exactly the same reasons that the phrase "extending Dublin
   Core" is now seen as problematic in the DCMI context.
   Taken literally, the phrase implies that one is adding
   terms to the vocabulary maintained by DCMI.  Whereas it is
   typically intended to mean that Dublin Core (or SKOS) terms
   are being used together with terms from other vocabularies
   in constructing a more expressive model.  This ambiguity
   could perhaps be avoided with careful re-wording.

7. In sections such as Annotation Constraints, the text says
   "a concept may have no more than one definition per
   language".  This seems a touch too prescriptive, as if
   the Guide were declaring constraints for an XML schema
   instead of providing guidance in an Open World context.
   Maybe "should"?

8. I found myself stumbling over the phrase "Structured
   Value" as a label for object nodes which are themselves
   subjects of further assertions (i.e., which themselves
   have properties).  I recognize that this is due to the
   particular way "structured value" has been used over time
   in the context of DCMI.  Others without this historical
   baggage may not share this reaction.

   Querying Google for "'structured value' site:w3.org" yields
   a dozen or so hits from circa 1999 followed by the draft
   SKOS Core Guide.  Hmm...  One finds "structured property
   value" explained in, for example, the RDF Primer.  In the
   SKOS Core Guide, however, the notion of "structured value"
   is explained less in modeling terms than as a style of XML
   encoding ("Structured Value Usage Style").  This relates
   to the point in my previous posting about presenting the
   RDF/XML serialization syntax ahead of (or instead of)
   labeled directed graphs.

   In the DCMI context, Andy Powell et al have clarified
   the (quite different but historically related) issue of
   "Dublin Core structured values" by distinguishing between
   value representations with inherent structure -- e.g.,
   labelled strings, unlabelled strings, and marked-up text --
   as opposed to "related descriptions" (see Appendix A in
   [6]).  What the SKOS Guide calls a "structured value",
   then, is what the DCMI Abstract Model calls a "related
   resource description".  To my way of thinking, the phrase
   "related resource description" is more helpful.

   If the SKOS Guide is aimed at RDF-literate readers, the
   concept of "structured value" could perhaps be clarified
   by explaining first what is meant in modeling terms, citing
   the RDF Primer and possibly emphasizing that it is about
   describing a related resource.

   At any rate, glossing over the model for the sake of
   emphasizing syntax guidelines seems like a risky strategy
   -- a potential source of modeling errors on the part of
   readers looking for syntax recipes.

9. The Guide talks about "describing" a thesaurus using RDF.
   I hesitate to make the following point, because RDF is after
   all the "Resource Description" Framework, but -- again,
   seen through Dublin Core glasses -- the phrase "resource
   description" is widely associated with the creation of
   catalog-like descriptions of resources ("metadata").

   In this usage, the phrase "RDF description of a thesaurus"
   evokes an image of "metadata" about the thesaurus -- i.e.,
   a set of assertions about Title, Creator, Publisher, and
   Subject -- encoded in RDF/XML angle brackets.  Whereas SKOS
   Core is really about modeling the thesaurus structure
   itself in terms of directed labeled graphs.  The abstract
   for the Quick Guide seems to acknowledge the difference by
   distinguishing between an RDF description "of a thesaurus"
   and an RDF description "of thesaurus metadata".

   (Even so, the notion of creating a "description"
   of "metadata" seems confusing because if metadata is
   inherently already a description, one could take this to
   mean "creating a description of a description".)

   The potential confusion could perhaps be avoided if one
   were to characterize SKOS Core as something used in creating
   an RDF "expression", or RDF "model", of a thesaurus.

10. Keeping the focus on the word "description", I find myself
   confused by the formulation in the Guide's Abstract,
   repeated elsewhere in the draft:

      "SKOS Core is a ...  Vocabulary for describing
      concepts and concept schemes".  

   ...whereby a concept scheme is:

      "a description of a set of concepts".

   Again, one might conclude that SKOS Core is a vocabulary
   for describing a description.  When I read through this
   and other sections, I find myself wanting to cross out
   the words "a description of" here and there.

11. I see two ways one might address the "description"
    problem:

   -- Stick to RDF usage and explain to the reader up-front
      what is meant by "description" -- i.e. that it is being
      used in a very broad sense -- which could also entail
      explaining what is meant by the references to "metadata"
      (i.e., a particular type of description, subject itself
      to "description" in RDF).

   -- Use a word other than "description", such as
      "expression", to convey the notion that one is expressing
      a thesaurus in, or translating a thesaurus into, the
      context of an RDF model.

    In the Abstract, for example, one might cut the phrase
    "a description of" here and there (the spots marked "[*]")
    and come up with something like:

        SKOS Core is a model and supporting vocabulary for
        describing concepts and concept schemes.  (A 'concept
        scheme' is defined here as [*] a set of concepts,
        optionally including [*] semantic relationships
        between those concepts.)  The main function of SKOS
        Core is to express linguistically oriented knowledge
        organization systems, such as thesauri, in RDF --
        a form processable by Semantic Web applications.

[1] http://dublincore.org/documents/dcmi-terms/
[2] ftp://ftp.cenorm.be/public/ws-mmi-dc/mmidc133.pdf
[3] http://dublincore.org/documents/dcmi-namespace/
[4] http://purl.org/dc/elements/1.1/format
[5] http://dublincore.org/usage/terms/history/#format-002
[6] http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/


-- 
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 Thursday, 23 December 2004 09:51:42 UTC