W3C home > Mailing lists > Public > public-swd-wg@w3.org > September 2008

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

From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
Date: Fri, 5 Sep 2008 16:13:50 +0200
To: public-swd-wg@w3.org
Cc: David Norheim <dn@computas.com>
Message-Id: <200809051613.50337.Kjetil.Kjernsmo@computas.com>

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):
>
>   http://www.w3.org/TR/2008/WD-skos-reference-20080829/
>
> 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: kjetil.kjernsmo@computas.com   
Web: http://www.computas.com/

|  SHARE YOUR KNOWLEDGE  |

Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
1001
Received on Friday, 5 September 2008 14:14:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 September 2008 14:14:31 GMT