Re: SKOS comment

Dear Erik,

Thanks again for these detailed comments and suggestions. 

All of these comments are still relevant to the 2008-08-29 Last Call
Working Draft of the SKOS Reference, therefore we have decided to
handle them within our last call process.

Your comments have been raised as the following issues: ISSUE-147,
ISSUE-148, ISSUE-149, ISSUE-150, ISSUE-151, ISSUE-152. The Working
Group's issue tracker system is online at:

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

We hope to respond by Friday 10th October. Our apologies for not
taking your comments into account sooner.

Kind regards,

Alistair Miles

On Fri, Jun 27, 2008 at 05:17:10PM -0700, Erik Hennum wrote:
> 
> 
> Hi, Esteemed SKOS Editors and Committee:
> 
> We've been using SKOS to good effect for a couple of years now. (FYI, you
> can see the work in progress at [1] and [2].)
> 
> In general, the 2008-6-9 draft makes substantial progress on formalizing
> and completing SKOS without losing the clarity that makes SKOS appealing.
> 
> 
> At the risk of ingratitude, here are some comments:
> 
> 
> 1.  Notations as plain literals
> 
> While it should certainly be possible to specify a datatype for a notation,
> relying on the datatype to identify the classification scheme and thus
> effectively requiring the datatype seems complex and a barrier to adoption.
> 
> Would it be possible to use a distinct skos:ConceptScheme instead of a
> datatype to identify each notational classification scheme?  enumerating
> the notations with skos:Concepts?  Mapping properties could then associate
> the concepts from the notational classification scheme with concepts in the
> scheme that's the focus of interest.  The datatype could then be optional
> and used for validation of value format (as is commonly expected for XML
> Schema datatypes).
> 
> The cost would be some indirection, but that could be mitigated by minting
> URI identifiers for notational concepts in which the final step is a
> recognizable variant on the notation for the concept.  The benefit would be
> consistency, simplicity, and a public, reusable SKOS definition of each
> notational classification scheme.
> 
> 
> 2.  Irreflexive and noncyclical hierarchies
> 
> While it makes good sense to have an abstract base to handle unexpected
> cases, the draft acknowledges in Section 8.6.7. Reflexivity of skos:broader
> and Section 8.6.8. Cycles in the Hierarchical Relation (Reflexivity of
> skos:broaderTransitive) that many applications expect hierarchical
> relationships to be irreflexive and noncyclical.
> 
> Given that this requirement will be quite common, is it appropriate to
> leave it as an exercise for each application to solve in a different way?
> Or would it be better to define subproperties with these constraints so
> this common requirement can be addressed by common SKOS infrastructure?
> 
> 
> 3.  Asymmetric associations
> 
> In our experience, while we've had no need for symmetric associations,
> we've had considerable need for directional, non-hierarchical associations.
> For instance, our target audience perceives a directional association
> between a hardware platform and the operating systems that run on the
> platform and again between an operating system and the software
> applications that run on the operating system.
> 
> In Section 8.6.3. Symmetry of skos:related, the draft makes a point of
> providing examples of asymmetric subproperties of skos:related, suggesting
> that our experience may not be unusual.
> 
> Is this requirement sufficiently common that it makes sense to provide an
> asymmetric subproperty of skos:related as part of the standard rather than
> have many adopters solve the same problem in different ways?  Effectively,
> this subproperty would be a broader / narrower relationships that does
> _not_ entail or imply the weak transitive associations that construct the
> hierarchy.
> 
> 
> 4.  Subsumption hierarchies
> 
> We've had a need to distinguish subsumptive relations (for which we
> currently use the SKOS broaderGeneric / narrowerGeneric extension) from
> broader relations where the broader concept is not fully subsumptive.
> 
> For instance, there is consensus in our target audience that the concept of
> Linux subsumes the concept of RedHat Linux.  By contrast, the High
> Availability concept subsumes the overall purpose but not the operational
> tasks associated with the Disaster Recovery concept.  (In passing,
> subsumption relations seem much more common between proper-noun concepts
> than between general concepts.)
> 
> The distinction is important because subsumption is much more reliable for
> qualifying content during search applications (and can be treated as
> strongly transitive).  Has the committee considered carrying forward this
> experimental distinction from the previous version of SKOS as an optional
> subproperty of broader / narrower?
> 
> 
> 5.  skos:member definition
> 
> Should the specification define skos:member as having a range of
> skos:Concept or skos:Collection? Should skos:member have an inverse
> skos:isMemberOf property?
> 
> 
> 6.  Prefix for extension labels
> 
> While namespace prefixes are completely arbitrary in principle, in practice
> conventional namespaces prefixes are useful for reinforcing understanding.
> Should the conventional namespace prefix for the extension labels
> incorporate the "skos" name as a reminder of the association as in "skosl"
> or "skosxl"?
> 
> 
> 
> Hoping that's useful,
> 
> 
> Erik Hennum
> ehennum@us.ibm.com
> 
> 
> [1] The subjects used to classify the content
> http://publib.boulder.ibm.com/infocenter/systems/advanced/viewTaxonomy.jsp
> 
> [2] The current search and browsing experience for around 75,000 articles
> http://publib.boulder.ibm.com/infocenter/systems/index.jsp
-- 
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, 1 October 2008 21:55:28 UTC