Re: SKOS comment (was: Re: Last Call: SKOS Simple Knowledge Organization System Reference; SKOS Primer updated)

Dear Kjetil,

The Semantic Web Deployment Working Group kindly acknowledges receipt
of your last call comment. We hope to respond by Friday 10 October.

Your comment will be tracked as ISSUE-130. The SWD Issue Tracker is

With thanks and apologies for the delay in responding,

Alistair Miles

On Fri, Sep 05, 2008 at 04:13:50PM +0200, Kjetil Kjernsmo wrote:
> Hi all!
> On Thursday 04 September 2008 17:48:15 Alistair Miles wrote:
> > The W3C Semantic Web Deployment Working Group is pleased to announce the
> > publication of a Last Call Working Draft for the Simple Knowledge
> > Organisation System Reference (SKOS):
> >
> >
> >
> > Our Working Group has made its best effort to address all comments received
> > to date, and we seek confirmation that the comments have been addressed to
> > the satisfaction of the community, allowing us to move forward to W3C
> > Candidate Recommendation following the Last Call process.
> Congratulations with the great work! I'm delighted to see SKOS moving forward 
> and look forward to the CR and eventual Recommendation. Also, I'm prepared to 
> write a testimonial for SKOS when that day comes, and work towards the 
> Norwegian press by issuing a press release! I have reviewed the specification 
> now, and I have the following comments.
> > The Working Group solicits review and feedback on this draft specification.
> > In particular, the Working Group would be keen to hear comments regarding
> > any features identified at risk, and from those implementing (among
> > others):
> >
> > * Editors:  editors that either consume or produce SKOS;
> >
> > * Services: vocabulary services that provide access to vocabularies using
> > SKOS;
> To take the last thing first: We have built a system for quality controlled 
> Internet resources which uses SKOS to assist users in finding the resources 
> they are after. The vocabulary is entirely modelled in SKOS and have both 
> hierarchical and associative links. 
> More specifically, we are using the following classes and properties:
> skos:ConceptScheme, skos:Concept, skos:hasTopConcept, skos:narrower, 
> skos:broader, skos:semanticRelation, skos:prefLabel, skos:altLabel, 
> skos:hiddenLabel and skos:note. 
> Super-users of the site may define new relations, or use skos:related. If they 
> choose to define a new relation (e.g. </antibiotics> sub:cures </infection>), 
> it will be modelled as a rdfs:subPropertyOf skos:semanticRelation. This 
> solution made the queries we use to get relations really simple. 
> Adding new concepts, set their labels and notes, and define relationships 
> between them, and create new relationships is done in a web interface.
> In addition, we have created a sub:classification property, which is similar 
> to SKOS mapping properties, but it is a owl:DatatypeProperty. The reason for 
> this is that many of the things we would map to lack useful URIs at the 
> moment, and a literals solves the immediate problem. We have not pushed for 
> inclusion of such a property in SKOS since we expect that this is a 
> short-lived temporary solution, since we expect everything to get URIs soon.
> So, to the features at risk:
> We have defined a 
> sub:isMainConceptOf  a owl:ObjectProperty ; 
>             rdfs:range skos:ConceptScheme ;
>             rdfs:domain skos:Concept ;
>             owl:inverseOf skos:hasTopConcept . 
> so it was great to see that skos:topConceptOf is in! Please keep it there, it 
> is simply much easier for us to use it in development with the present 
> architecture.
> I haven't followed the debate since this first was debated, but I would like 
> to bring this up again: I do not like the naming of skos:hasTopConcept and 
> skos:topConceptOf. As long as there are associative relationships in the 
> system, it seems meaningless to make the hierarchical relationships more 
> prominent than the associative by connecting this property to the hierarchy. 
> So, that's why I called my inverse of skos:hasTopConcept isMainConceptOf. I 
> think something like that would be better. 
> I haven't thought too carefully about it, but what if:
> <S> rdf:type skos:ConceptScheme ;
>   skos:hasTopConcept <B> .
> <B> rdf:type skos:Concept .
> <A> rdf:type skos:Concept ;
>         skos:related <B> .
> would this be consistent?
> I think that's fairly inevitable in our system, and it would certainly break 
> things if we couldn't do this. What if <B> skos:broader <C> . ?
> That's my only criticism, really.
> As for the other features at risk:
> We are using the old namespace, but changing it is no problem, so we are 
> indifferent towards that issue.
> We do not use the mapping features, so we have no implementation experience 
> either, and no strong opinion. I see how these properties could be very 
> valueable in Mass Intelligence scenario with Open Linked Data, so perhaps it 
> would be valuable to look in that direction for guidance?
> Again, thanks for putting all this work into SKOS, we allready find it very 
> useful and a good fit for our purpose. 
> Kind regards 
> Kjetil Kjernsmo
> -- 
> Senior Knowledge Engineer
> Mobile: +47 986 48 234
> Email:   
> Web:
> Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
> 1001

Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
United Kingdom
Tel: +44 (0)1865 281993

Received on Tuesday, 30 September 2008 14:39:17 UTC