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:

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
> [1] The subjects used to classify the content
> [2] The current search and browsing experience for around 75,000 articles
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, 1 October 2008 21:55:28 UTC