Re: Relationships involving collections

Alasdair Gray wrote:

>> aa:1 a skos:Concept ;
>>  skos:prefLabel "Sources as function of wavelength" ;
>>  skos:narrower aa:2 .
>>
>> aa:2 a skos:Collection ; rdfs:label "Gamma Rays" ;
>>  skos:member aa:3 ;
>>  skos:member aa:4 ;
>>  skos:member aa:5 .
>>
>> aa:3 a skos:Concept ; skos:prefLabel "Gamma ray bursts" .
>> aa:4 a skos:Concept ; skos:prefLabel "Gamma ray observations" .
>> aa:5 a skos:Concept ; skos:prefLabel "Gamma ray theory" .
 >
> That is what I was intending. However, this is *not* compliant with the 
> latest working draft [4] as skos:narrower cannot be applied to 
> collections. In fact, this raises the question, how do you state where a 
> collection fits within a hierarchy? All the examples of 
> collections/arrays show them within a hierarchy but by my understanding 
> this can no longer be stated in SKOS.

Well, then the latest working draft needs to explain thatp. Maybe this 
is the way it is intended: First define the hierarchy without any 
collections:

aa:1 a skos:Concept ;
   skos:prefLabel "Sources as function of wavelength" ;
   skos:narrower aa:3 ;
   skos:narrower aa:4 ;
   skos:narrower aa:5 .

aa:3 a skos:Concept ; skos:prefLabel "Gamma ray bursts" .
aa:4 a skos:Concept ; skos:prefLabel "Gamma ray observations" .
aa:5 a skos:Concept ; skos:prefLabel "Gamma ray theory" .

Then group concepts as you like:

aa:2 a skos:Collection ; rdfs:label "Gamma Rays" ;
  skos:member aa:3 ;
  skos:member aa:4 ;
  skos:member aa:5 .

You can then infer that because all members of aa:2 (aa:3, aa:4, aa:5) 
are narrower concepts of aa:1, an application should display them 
grouped in the hierarchy.

So far no problem - the application has to infer and analyse a bit more, 
that's all.

 > From the point of view of providing interfaces to users who do not
 > want to concern themselves with what is a collection and what is a
 > concept, these rules will be essential. This is in fact something I am
 > in the midst of developing, a mapping editor for skos vocabularies.

A mapping editor should provide a possibility to map groups to concepts, 
but in the exported SKOS RDF, the mapping must be between concepts only. 
The open question is how to encode the "virtual" mapping between a 
concept and the group. Maybe you can always infer it from the direct 
mapping relations.

I think it's time for a reference implementation[*] of SKOS. Without a 
reference implementation is predetermined to be used in different, 
incompatible ways! Any favored programming languages?

Greetings
Jakob

[*] The reference implementation should implement all the rules in the 
specification. You should validate a KOS in SKOS and all entailment 
rules should be expanded. Furthermore it should give you additional 
information about a KOS, for instance whether it is monohierarchical, 
information about groups etc.

-- 
Jakob Voß <jakob.voss@gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de

Received on Tuesday, 5 February 2008 15:23:06 UTC