Re: SKOS comment

Hi, Alistair:

Thanks for considering the input and please let me know if we can clarify
any points.


Erik Hennum
ehennum@us.ibm.com



                                                                                              
  From:       Alistair Miles <alistair.miles@zoo.ox.ac.uk>                                    
                                                                                              
  To:         Erik Hennum/Oakland/IBM@IBMUS                                                   
                                                                                              
  Cc:         public-swd-wg@w3.org                                                            
                                                                                              
  Date:       10/01/2008 03:00 PM                                                             
                                                                                              
  Subject:    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