SKOS comment

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