SKOS comment (s) from PFWG

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