- From: Thomas Baker <thomas.baker@bi.fhg.de>
- Date: Mon, 10 Jan 2005 14:38:41 +0100
- To: SWAD Europe Thesaurus <public-esw-thes@w3.org>
Date: Thu, 23 Dec 2004 10:52:24 +0100 From: Thomas Baker <thomas.baker@bi.fhg.de> To: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk> Cc: "'public-swbp-wg@w3.org'" <public-swbp-wg@w3.org> Subject: Re: [ALL] PORT documents for internal review - 2/2 Sender: public-swbp-wg-request@w3.org 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 Monday, 10 January 2005 13:37:10 UTC