Re: ISSUE-160: Allowing collections in semantic relationships

Sounds ok.
If you think it is appropriate, you could add a "practice" note, as you 
asked me to do for answering Michel Panzer's comment. [1]

Please note that it is possible to coin a practice for solving 
R-IndexingAndNonIndexingConcepts [2], provided you make your own (small) 
extension to SKOS. The SKOS Primer gives some general hints on the 
approach [5]. Your proposed solution -- "create a (nonSKOS) property of 
a concept, to say essentially, ‘NOT_FOR_INDEXING’" -- is a first proper 
way to do this. You can also solve the problem by subclassing 
skos:Concept. The following steps should then be taken:
- first, identify an indexing property you want to use to assign 
concepts to other resources (e.g. dc:subject).
- second, define a subclass of skos:Concept, for instance 
my:NonAssignableConcept, which is defined as not being usable as the 
object of statements involving the chosen indexing property. This can be 
done in OWL, using a property inverse of the indexing property and an 
appropriate OWL cardinality constraint.

I hope this helps. Note that if you agreed with the practice proposed in 
the second part of this mail, or want to push your own solution, we 
would encourage you to publish a brief best practice note and inform the 
SKOS community via the mailing list. We'd also be more than happy to set 
up a "SKOS community best practices" wiki page to collect links to such 




> Here's a draft response to Doug on ISSUE-160, comments welcome.
> --- begin draft message ---
> 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
>> 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.
> [1]
> [2]
> [ISSUE-46]
> [3]
> [4]
> [5]

Received on Thursday, 23 October 2008 11:50:14 UTC