Re: SKOS comment (s) from PFWG

Dear Al,

Thank you for your detailed and valuable comments. These have been
raised as ISSUE-178, ISSUE-179, ISSUE-180. The SWDWG issue tracker is
online at:

We hope to provide a response by 17 October.

Kind regards,

Alistair Miles
Sean Bechhofer

On Fri, Oct 03, 2008 at 11:18:43PM -0400, Al Gilman wrote:
> <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, 
> reference-20080829/
> 2.       SKOS Primer,

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

Received on Wednesday, 8 October 2008 09:59:52 UTC