Re: ISSUE-160: Allowing collections in semantic relationships

Hi Doug,

Thanks for your response. Further comments inline.

On Sun, Nov 16, 2008 at 12:56:39PM -0000, Tudhope D S (AT) wrote:
> Hi Al
>  
> thanks for getting back
> I take your points about indexing and correspondence between SKOS and BSI.
> However, they don't address the main issue I wanted to raise. I see your personal note deals with it more and I think indicates that this issue is still somewhat under consideration?
>  
> I may have confused things by suggesting a work around. Let's set aside the non-indexing issue for now.
> I'll restate the issue:
> Concern: Insufficient support/guidance for legacy systems wrt guide terms / facet indicators
>  
> My concern is that SKOS collections do NOT represent common practice in most existing thesauri
> and (if this is true) there is a danger that they might constitute a significant barrier to take up of SKOS by vocabulary owners who would otherwise wish to do so, unless appropriate guidance/alternatives are available.
>  
> I think conversion of legacy thesauri to SKOS is an important application for SKOS and its wider take up.
> Do we know how many thesauri actually follow the SKOS collections for such structures? 
> I don't think I know of any though I expect a few exist.
> Most that I know incorporate facet indicators as part of the hierarchy.  (I'm happy to be corrected if this not the case)

I'm not sure what you mean by "part of the hierarchy".

Consider the following example. The systematic display for my example
aeroplane thesaurus looks like this:

---
aeroplanes
.<aeroplanes by wing number>
..monoplanes
..biplanes
..triplanes
---

The alphabetic display for my thesaurus looks like this:

---
aeroplanes
  NT biplanes
  NT monoplanes
  NT triplanes

biplanes BT aeroplanes

monoplanes BT aeroplanes

triplanes BT aeroplanes
---

Now, is "aeroplanes by wing number" part of "the hierarchy"?

My point is, for a thesaurus like this, you have an *open choice* about
how to represent the underlying data using SKOS.

The following choice would be compatible with the above displays,
would be consistent with the SKOS data model, and in my opinion
follows best practice (also consistent with BS8723-5):

---
ex:aeroplanes rdf:type skos:Concept ;
  skos:narrower ex:monoplanes, ex:biplanes, ex:triplanes .

ex:aeroplanes_by_wing_number rdf:type skos:Collection ;
  skos:member ex:monoplanes, ex:biplanes, ex:triplanes .
---

The following choice would also be consistent with the SKOS data
model, although in my opinion is not best practice:

---
ex:aeroplanes rdf:type skos:Concept ;
  skos:narrower ex:aeroplanes_by_wing_number .

ex:aeroplanes_by_wing_number rdf:type skos:Concept ;
  skos:narrower ex:monoplanes, ex:biplanes, ex:triplanes .
---

What I'm trying to say is, in my experience, for a thesaurus where
node labels have been used, *either* of the above approaches could
reasonably be taken. 

>  
> What do we expect vocabulary owners who do not follow the SKOS collections semantics to do?
> If we expect them to change their vocabulary structure is that a realistic expectation?

Again, I'm not sure what you mean by "change their vocabulary structure"?

For a thesaurus such as the example above, either choice could
reasonably be made wrt to the SKOS representation. In either case, no
change would be required to the systematic or alphabetic displays. 

How the data is represented within whatever thesaurus management
system is used to manage the thesaurus is essentially irrelevant, and
need not be changed either. How you structure and manage your data
within your systems, and how you expose your data to the rest of the
world, need not be the same.

> I personally like the SKOS collections semantics but the issue is a concern because I'd like to see wide take up of SKOS by existing vocabularies. Successful standards need to strike a balance between best practice and legacy practice. Antoine's extensions [your ref 6 below] seem to go towards meeting this issue thought I'm not sure what their status is?
>  
> I think though at least some guidance is needed in the primer with some suggestions for what to do if legacy vocabularies owners do not want to completely restructure for guide terms/facet indicators. Maybe this could be considered for final primer version?

To reiterate, I don't believe that using the SKOS collections
framework as illustrated in the first option above requires any legacy
vocabularies to restructure anything. How they structure their data
internally and how they expose their data to the world could be (and
often are) different.

Does this make sense? 

Kind regards,

Alistair


> ________________________________
> 
> From: Alistair Miles [mailto:alistair.miles@zoo.ox.ac.uk]
> Sent: Thu 06/11/2008 09:34
> To: Tudhope D S (AT)
> Cc: public-swd-wg@w3.org
> Subject: ISSUE-160: Allowing collections in semantic relationships
> 
> 
> 
> Dear Doug,
> 
> Thank you for your support and your helpful comments. In response to
> the comment below:
> 
> On Sat, Oct 04, 2008 at 01:54:26PM +0000, SWD Issue Tracker wrote:
> >
> >
> > ISSUE-160: Allowing collections in semantic relationships
> >
> > http://www.w3.org/2006/07/SWD/track/issues/160
> >
> > Raised by: Antoine Isaac
> > On product: All
> >
> > Raised by Doug Tudhope in [1]
> >
> > While SKOS collections represents best practice in thesaurus construction, many
> > prominent existing thesauri (and related KOS) do not follow the SKOS collections
> > semantics. Instead, they model guide terms, facet indicators etc as part of a
> > hierarchy using standard Broader/Narrower relationships. This creates a problem
> > in converting such existing KOS into SKOS. From discussions it appears other
> > people have come to a similar judgment in converting such cases to SKOS - being
> > reluctant to change the existing structure of a KOS designed by a third party.
> > The pragmatic decision is often to create a (nonSKOS) property of a concept, to
> > say essentially, 'NOT_FOR_INDEXING'. This allows a basic distinction to be made
> > between a facet indicator (or guide term) and a concept available for indexing.
> >
> > Can we consider if something like this could be introduced into SKOS to
> > facilitate conversion of many legacy KOS? The primer can always encourage the
> > full collections approach as best practice.
> 
> The requirement to indicate that some concepts are not intended for
> use in indexing was raised in the SKOS Use Cases and Requirements
> document [2]. Meeting this requirement was then discussed as
> ISSUE-46. The working group resolved to close this requirement because
> all matters related to indexing were deemed out of scope for SKOS, and
> better treated by vocabularies such as Dublin Core [3] or other third
> party vocabularies. We propose to make no change to the SKOS
> Reference, can you live with this?
> 
> Kind regards,
> 
> Alistair
> Sean
> 
> Personal comment by Alistair: I realise that the treatment of KOS
> elements such as guide terms, facet indicators and node labels, and
> the choice of whether to use the SKOS collections framework or whether
> model as you describe, remains a difficult issue, and requires careful
> judgment. However, on a positive note, I was pleased to learn recently
> of the very close correspondance between the modeling of node labels
> in the BS 8723-5 UML model and the modeling of collections in
> SKOS. Nicolas Cochard did an excellent job of illustrating the
> alignment between these two models at the ISKO event in July [4,5]. I
> hope that extensions to SKOS and best practices based on the new BS
> 8723-5 data model will help to clear up some of the difficulties here
> in the near future.
> 
> See also Antoine's message [6] for some suggestions for the
> development of extensions to meet your requirement.
> 
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0062.html
> [2] http://www.w3.org/TR/2007/WD-skos-ucr-20070516/#R-IndexingAndNonIndexingConcepts
> [ISSUE-46] http://www.w3.org/2006/07/SWD/track/issues/46
> [3] http://www.w3.org/2008/05/07-swd-minutes.html#item10
> [4] http://www.iskouk.org/presentations/cochard_BS8723-exchange-format.pdf
> [5] http://www.iskouk.org/SKOS_July2008.htm
> [6] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0286.html
> 
> --
> 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
> 
> 
> ----- End forwarded message -----
> 
> --
> 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
> 
> 

-- 
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 Saturday, 22 November 2008 11:09:04 UTC