Re: [SKOS] SKOS ontology sanity-check?

Hello,

I have finished checking the SKOS RDF file [1].

There are really not many important mistakes/comments (most important comments are put between stars).
 
I however decided to suggest many changes, even if really minor, on the basis that this could improve improve the overall quality.

I will check the SKOS XL file a bit later...

Cheers,

Antoine

[1] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos.rdf


=============== general comments


*Dublin core namespace:*
The new DC namespace http://purl.org/dc/terms/ is introduced as namespace in the ontology, but only the legacy one (http://purl.org/dc/elements/1.1/) is used. To keep consistency with the Primer (which was moved from dc: to dct: after a comment from Tom) I would suggest move to the new one. Note that this comment partly applies to the Reference document: it uses dc:title in section 1.3, but never defines the DC namespace. Maybe this is the opportunity to position this title in the dct namespace.
(note: for the sake of clarity, I have not further considered this aspect when making suggestions for specific changes below, when these concern DC-based triples)


*Labeling:*
I know that we already discussed that, and we have to live with the legacy URI local names, despite the fact that I personally find them horrible :-)
But are we forced to use the same (lack of) policy for the natural language rdfs:labels?
I don't really understand why the rdfs:label of hasTopConcept is "has top concept" while the rdfs:label of inScheme is not "is in scheme"! Or why the natural language rdfs:label of OrderedCollection is "Ordered Collection" with upper case O and C whereas "broadMatch" has a label "broad match" with only lower case.
These are minor comments, but maybe one days these labels will be used in some application. And as I have not checked this aspect very much in this review, I'd like to draw your attention on this...


Granularity of (rdfs:)comments:
As we are eating our own dog food and use skos:definition in the ontology (which is very nice!) maybe we could use skos:scopeNote, which imo applies to many rdfs:comments. Please come back to me if you also think it is worth doing this.


Semantics:
Even if we may not include them in the Reference RDF now, I would suggest to already create a file containing the axioms that OWL2 allows to represent. That's not huge work, and we could validate it right now, avoiding us to do this in a hurry later, or even to forget about it before the WG comes to its end. I can give it a try if you think this would be useful!


=============== comments on specific parts of the ontology

ontology definition:
<dc:title xml:lang="en">SKOS Core Vocabulary</dc:title>
-> <dc:title xml:lang="en">SKOS Vocabulary</dc:title>
(we don't want to carry forward the "Core" brand, do we?)


Concept:
<skos:definition xml:lang="en">An abstract idea or notion; a unit of thought.</skos:definition>
-> <skos:definition xml:lang="en">An idea or notion; a unit of thought.</skos:definition>
("abstract" could be read as focusing on abstract notions like freedom, intelligence, etc, while KOSs can be about more down-to-earth stuff. And "Core" seems to be removed from the Reference, as well)


ConceptScheme:
<skos:definition xml:lang="en">A set of concepts, optionally including statements about semantic relationships between those concepts.</skos:definition>
-> I'm quite uncomfortable with the "optionally including statements", as it lets readers think this is done trivially, which is not the case. But if you have written this being conscious of such potential objections, I will follow you :-)


*Collection:*
<rdfs:comment xml:lang="en">Labelled collections can be used with collectable semantic relation properties e.g. skos:narrower, where you would like a set of concepts to be displayed under a 'node label' in the hierarchy.</rdfs:comment>
-> <rdfs:comment xml:lang="en">Labelled collections can be used where you would like a set of concepts to be displayed under a 'node label' in the hierarchy.</rdfs:comment>


inScheme:
<skos:definition xml:lang="en">A concept scheme in which the concept is included.</skos:definition>
-> <skos:definition xml:lang="en">Relates a resource (for example a concept) to a concept scheme in which it is included.</skos:definition>
(the domain has been updated since SKOS 2004, and I don't like a definition that may be read as "inScheme is a concept scheme")


hasTopConcept:
<skos:definition xml:lang="en">A top level concept in the concept scheme.</skos:definition>
-> <skos:definition xml:lang="en">Relates, by convention, a concept scheme to a concept which is topmost in the broader/narrower concept hierarchies for that scheme, providing an entry point to these hierarchies.</skos:definition>


isTopConceptOf:
For non-OWL aware applications, I would make explicit the domain and range that can be inferred from the ones of hasTopConcept:
   <rdfs:domain rdf:resource="#Concept"/>
   <rdfs:range rdf:resource="#ConceptScheme"/>
(you did something similar for skos:hasTopConcept rdf:type rdfs:Property and in other places, and I find this a very good idea)


*prefLabel*
   <!-- S14 (not formally stated) -->
   <rdfs:comment xml:lang="en">It is recommended that no two concepts in the same KOS be given the same preferred lexical label for any given language tag.</rdfs:comment>
->
   <!-- S14 (not formally stated) -->
   <rdfs:comment xml:lang="en">A resource has no more than one value of skos:prefLabel per language tag.</rdfs:comment>
(by the way, how come that this has not been spotted by your script that compares the RDF file with the Reference specs? Looks like a bad sign :-( )


scopeNote:
<skos:definition xml:lang="en">A note that helps to clarify the meaning of a concept.</skos:definition>
-> <skos:definition xml:lang="en">A note that helps to clarify the meaning and/or the use of a concept.</skos:definition>
(that's really not crucial, but I have observed that usage is an important part of many scope notes in KOSs)


semanticRelation:
<skos:definition xml:lang="en">A concept related by meaning.</skos:definition>
-> <skos:definition xml:lang="en">Links a concept to a concept related by meaning.</skos:definition>


broader:
<skos:definition xml:lang="en">A concept that is more general in meaning.</skos:definition>
-> <skos:definition xml:lang="en">Relates a concept to a concept that is more general in meaning.</skos:definition>


narrower
<skos:definition xml:lang="en">A concept that is more specific in meaning.</skos:definition>
-> <skos:definition xml:lang="en">Relates a concept to a concept that is more specific in meaning.</skos:definition>


related
<skos:definition xml:lang="en">A concept with which there is an associative semantic relationship.</skos:definition>
-> <skos:definition xml:lang="en">Relates a concept to a concept with which there is an associative semantic relationship.</skos:definition>


*narrowerTransitive*
<skos:definition>skos:narrowerTransitive is a transitive superproperty of skos:broader. By
     convention, skos:narrowerTransitive is not intended to be used in assertions, but provides a
     mechanism whereby the transitive closure of skos:narrower can be queried.</skos:definition>
->
<skos:definition>skos:narrowerTransitive is a transitive superproperty of skos:narrower.</skos:definition>
(apart from the error on "superproperty of skos:broader", I had nothing strong against the long definition. But it is partly redundant with the rdfs:comment, and is not homogeneous with the spec of broaderTransitive)


member
<skos:definition xml:lang="en">A member of a collection.</skos:definition>
-> <skos:definition xml:lang="en">Relates a collection to one of its members.</skos:definition>


memberList
<skos:definition xml:lang="en">An RDF list containing the members of an ordered collection.</skos:definition>
-> <skos:definition xml:lang="en">Relates an ordered collection to the RDF list containing its members.</skos:definition>
(this formulation also makes the functionality clearer)


*mappingRelation*
<skos:definition xml:lang="en">Definition</skos:definition>
-> <skos:definition xml:lang="en">Relates two concepts coming, by convention, from different schemes, and that have comparable meanings</skos:definition>


============================


>> Hi,
>>
>> Note that the second comment raised by Magnus in [1] raises the issue of the sanity-checking the SKOS ontology at [2].
>>
>> I have the feeling that even though this document is crucial for the Recommendation, we (*as a group*) have not scrutinized it as thoroughly as we did for the Reference.
>>
>> Is this feeling right? If yes, I'd propose we take action on this, by having one or two persons browse and validate it.
>> I don't know how this should formally handled with. But I'd be happy to volunteer to make a small review, if need be.
> 
> Yes, it would be great to get some more eyes on the formal schemas for
> SKOS [2] and XL [3].
> 
> I did run some scripts over them to check for consistency with the
> SKOS Reference, but my scripts are fairly simple so cannot check for
> everything.
> 
> FWIW I did...
> 
> [4] --[5]-> [6] (extract formal prose sentences from reference)
> [6] --[7]-> [8] (generate python version of skos as triples)
> [6] --[9]-> [10] (generate python version of xl as triples)
> [2]+[8] --[11]-> [12] (check python skos against rdf skos)
> [3]+[10] --[13]-> [14] (check python xl against rdf xl)
> 
> Cheers,
> 
> Al
> 
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2009Feb/0014.html 
> [2] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos.rdf
> [3] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos-xl.rdf
> [4] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/
> [5] http://www.w3.org/2006/07/SWD/SKOS/reference/utils/extract-statements.xsl
> [6] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos.txt
> [7] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/GeneratePythonSkos.py
> [8] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skos.py
> [9] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/GeneratePythonSkosXl.py
> [10] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/skosxl.py
> [11] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/CheckSchema.py
> [12] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/check-schema-report.txt
> [13] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/CheckSchemaXl.py
> [14] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/check-schema-report-xl.txt
>

Received on Monday, 9 March 2009 09:53:44 UTC