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:

http://www.w3.org/2006/07/SWD/track/issues

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, http://www.w3.org/TR/2008/WD-skos- 
> reference-20080829/
> 2.       SKOS Primer, http://www.w3.org/TR/2008/WD-skos-primer-20080829/
>
>

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

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