- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 3 Oct 2008 23:18:43 -0400
- To: public-swd-wg@w3.org
- Cc: wai-liaison@w3.org
- Message-Id: <CD162CED-7D10-4ECD-A3BA-2D391C749808@IEEE.org>
<note class="inTransmittal"> The following comments have received rough-consensus support in the Protocols and Formats Working Group. We would be glad to discuss them with you if you feel they are unclear or inadvisable. Thank you for your work on SKOS. Al /chair, PFWG </note> Comments on SKOS reference draft in last call [1]: (1) Re: Section 8: Semantic Relations We understand that SKOS has been devised to be universally applicable to various types of knowledge organization systems, many of which do not have semantically clear-cut relations, but are rather inaccurate in their meaning. However, there are use cases that would benefit from a stricter and richer definition of vocabulary for concept schemes. For example, the properties for hierarchical relationship (skos:broader, skos:narrower) are specified to indicate that ‘one [concept] is in some way more general ("broader") than the other ("narrower")’. The primer [2] even mentions the subjectivity of these properties: “skos:broader and skos:narrower enable the representation of hierarchical links, such as the relationship between one genre and its more specific species , or, depending on interpretations, the relationship between one whole and its parts.” Obviously, one can create custom-defined subproperties, but interoperability is much harder to achieve with custom-defined subproperties than with pre-defined properties that are part of the SKOS core. At a minimum, it would be helpful to have separate pairs of SKOS core properties defined for inheritance relationships (superclass- subclass) vs. structural relationships (whole-part). These would be subproperties of skos:broader and skos:narrower. So the user would have the choice between the (inaccurate) super-properties or the (semantically clearer) subproperties. (2) Re Section 5. Lexical Labels The motivation for the Integrity Conditions listed in section 5.4. (S13 and S14) is not clear. They appear to be overly constraining and badly aligned with the architecture of distributed systems, where labels could come from different sources and authors, and where redundancies may arise. Why is it okay to have no preferred label defined, but it is a clash to have the same string as preferred and alternate label? A SKOS application should be able to deal with situations where there are competing preferred labels, or one label being redundantly defined as “preferred” and “alternate”. These situations should not make the SKOS application fail. (3) Re Appendix A.2. The skosxl:Label Class The new “label framework” goes in the right direction, but does not go far enough. The skos:hiddenLabel property is considered to be useful for accessibility-related use cases (where misspellings may occur). The new properties skos:prefLabel and skos:altLabel conflict with dc:title. In fact, these properties co-exist in examples of the SKOS reference. Guidance is missing as to when to use the skos-defined label properties, and when to use dc:title. The label framework should explicitly cater for non-textual labels in image, audio or video format, and as provided in other markup languages such as MathML. Labels in other modalities may serve as alternate labels in accessibility-related use cases. SKOS should provide guidance as to how to provide images, audio and video content as alternate labels. Currently, icons are being standardized as representing concepts in an upcoming multi-part standard ISO/IEC 11581, developed by ISO/IEC JTC1 SC35. SKOS should be able to specify these icons as part of a knowledge organization system. Also, the most common label relationships should be pre-defined by SKOS. This should include: skos:acronym, skos:pronunciation. References: 1. SKOS Reference, http://www.w3.org/TR/2008/WD-skos- reference-20080829/ 2. SKOS Primer, http://www.w3.org/TR/2008/WD-skos-primer-20080829/
Received on Saturday, 4 October 2008 03:19:27 UTC