RE: [Moderator Action] RE: SKOS Public Working Drafts

Hi Nicolas,

Many thanks for these comments, they are extremely valuable.  Could you tell me what you think of the responses I have made below? ...  
 
<Nicolas>
About the section "Preferred and Alternative Lexical Labels" 
I don't know too much about OWL but it might be useful to state in the SKOS Core RDFS that the preferred label must be unique: using OWL cardinality. 
</Nicolas>

The problem is that preferred labels should be unique within the context of a given language, but a concept may have a preferred label in english and a preferred label in french, for example.  E.g.

<skos:Concept rdf:about="X">
	<skos:prefLabel xml:lang="en">Fish</skos:prefLabel>
	<skos:prefLabel xml:lang="fr">Poisson</skos:prefLabel>
</skos:Concept>

As far as I know, you cannot represent that constraint using OWL.  You could however express this constraint as a SPARQL query [http://www.w3.org/TR/rdf-sparql-query/], e.g.

PREFIX validation: <???>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
CONSTRUCT 
{
	[] a validation:Error;
		validation:cause ?x;
		rdfs:comment 'Cause has two preferred labels for the same language.';
	.
}
WHERE
{
	?x skos:prefLabel ?p1.
	?x skos:prefLabel ?p2.
	FILTER lang(?p1) = lang(?p2)
}

I keep meaning to write up a validation note, I just haven't got to it yet.

<Nicolas> 
About the section "The skos:Concept Class" 
The Document does not make any mention of the possibility of extending SKOS.
Extension of a concept 
In some of our lists, we have different types of concepts. For example in LGCL we used to have both "category" and "non-category" concepts.
I assume that there would be nothing stopping me create a new rdfs:Class subclass of skos:Concept.
But is it good practice? Should the guide make this clearer?
Extension of a label 
We need to be able to represent the fact that some alternative labels (non-preferred) are of the type acronym, synonym, misspelling, etc.
I would like to be able to define a property "synonym" which is a sub-property of altLabel, or a property "misspelling" which is a sub-property of "hiddenLabel", etc. 
Same comment as above. Is it good practice? Should the guide make this clearer?
</Nicolas>

The intention is to write a separate note that says how to do extensions.  The two examples above are fine as far as I'm concerned, and would make good examples for an extensions note.  The farthest I've got with writing the note is the wiki page at http://esw.w3.org/topic/ExtendingSkosCore ... feel free to add some examples or text to this page :)  It will also ultimately include the examples that were in an earlier editor's draft of the SKOS Core Guide, but got chopped to help move things along faster, see http://www.w3.org/2004/02/skos/core/guide/2004-11-25#secextending 

<Nicolas>
About the section "Concept Schemes" 
It might be useful to define some inference rules such as: "if myConceptScheme hasTopLevel myConcept" then "myConcept inScheme myConceptScheme".
</Nicolas>

You're right, this relationship should be captured somehow.  One (hack) way would be to assert {skos:inScheme owl:inverseOf skos:hasTopConcept.}, although a better way would be to declare a new property {skos:hasConcept rdfs:subPropertyOf skos:hasTopConcept; owl:inverseOf skos:inScheme.}.  I wouldn't object to making this addition.  

<Nicolas>
About the section "Primary Subjects" 
(Same comment as above). It might be useful to say in the SKOS Core RDFS that the primary subject must be unique: using OWL cardinality.
</Nicolas>

This is similar to the skos:prefLabel problem - a resource may have only one primary subject *per subject scheme*, but may have one primary subject from scheme X and one from scheme Y.  The SPARQL expression to detect a violation of this constraint would be ...

PREFIX validation: <???>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
CONSTRUCT 
{
	[] a validation:Error;
		validation:cause ?r;
		rdfs:comment 'Cause has two primary subjects for the same concept scheme.';
	.
}
WHERE
{
	?r skos:primarySubject ?s1.
	?r skos:primarySubject ?s2.
	?s1 skos:inScheme ?x.
	?s2 skos:inScheme ?y.
	FILTER ?x = ?y
}

<Nicolas>
About the section "Published Subject Indicators" 
(Same comment as above). It might be useful to state in the SKOS Core RDFS that the subject indicator must be unique: using OWL cardinality 
It could also be useful to define an inverse property "isSubjectIndicatorOf" that could be used in the metadata of the document itself. 
</Nicolas>

Actually I believe the constraint is that all concepts with the same subject indicator are necessarily the same concepts.  This is already stated in the SKOS Core RDFS/OWL description, because {skos:subjectIndicator a owl:InverseFunctionalProperty}.

Again I wouldn't object to an inverse property, although the whole PSI area probably needs further study.

<Nicolas>
About the section "Concept Scheme Versioning" 
In the past, a lot of the users of our lists had problems migrating from a version of the list to another. Hence, I was quite interested by this section. 
The example shows that the version 2 of the concept scheme has a "owl:priorVersion" which is the version 1.
OWL describe the range of priorVersion has being the elements of the class ontology; however, the SKOS Core RDFS does not define a concept scheme as being an ontology.
Is this omission voluntary?
</Nicolas>

Yep, this is a deliberate omission, because the relationship between SKOS concept schemes and OWL ontologies still needs to be properly described.  That's why this section is in the 'open issues' section.  The whole versioning problem has yet to get properly described too.  See also what I wrote recently at http://esw.w3.org/topic/ConfigurationManagement ... not sure how this would translate for SKOS concept schemes.

<Nicolas>
Another general comment 
I have read on the web some discussion between "ontologists" arguing that we should never redefine an abstract concept that has already been defined elsewhere. Is this the case with SKOS?
Should we re-use the URI of a concept defined by someone else in a different taxonomy? 
Or should we define a URI for all our concepts and use a mapping (such as "exactMatch") to map to a concept of a different list (as explained in the section "Concept Identity and Mapping")? 
In my opinion, the second solution is better (because we keep control of all our concepts) but what would SKOS recommend?
</Nicolas>

I depends on the situation.  You can probably re-use other people's concepts, if you trust that those concepts are stable.  The problem would come if you re-use someone else's concepts and they get changed.  I'm glad you brought this up, we probably ought to directly address the issue of 're-use' in the guide.

<Nicolas>
Yet, another general comment 
We also have an example of a list which is a subset of another list. For example the list "IPSV abridge" is a subset of the list "IPSV". If the answer of my question above is "not to reuse URI of another controlled list"; what should we do in this case? In this specific case I would prefer to re-use the same URIs for concepts. And I would use DCMI to state that a concept scheme dcterms:isPartOf another concept scheme. Is it a good practice?
</Nicolas>

That would be one way to do it.  Another way would be to declare a class of concepts for each scheme, and declare that one class was a subclass of another.  I'm not sure what should be best practice.

<Nicolas>
In the SKOS Core RDFS I believe that the vocabulary could have been more restricted using OWL rules. See point 1, 3, 4, 5, 6 above. Is there any reason to keep the vocabulary unrestricted? Is it to keep it flexible? 
</Nicolas>

Flexibility is one factor.  For example, currently you can use the SKOS Core documentation properties with either a literal or a blank node or a named resource.  Without this flexibility we would have to add a lot more properties or classes to SKOS, and the extensibility would be complicated.  Also several of the SKOS Core constraints cannot be expressed in OWL, as described above.  However, if there are any particular semantics or rules that could be expressed in OWL, I'd be more than happy to have them added.  Should we declare that {skos:semanticRelation a owl:ObjectProperty.} for example?
 
Once again many thanks for taking the time with this, and any further suggestions or comments would be most welcome.

Yours,

Alistair.

Received on Friday, 8 July 2005 15:38:02 UTC