Hi Mikael,
<snip>
> I fail to see what, precisely, in this definition that makes it
> difficult for a ConceptScheme to also be a Class with its extension ==
> its set of instances per above. That it has more properties
> is no issue
> from a semantic point of view as far as I can see.
>
> In fact, the ConceptScheme would even seem to be *the* canonical
> representative of that set of instances, and it would thus
> seem to be a
> useful addition to the SKOS model (and its users!) to make
> that a formal
> fact as well.
>
<snip>
> Do you also agree that we *could* make the following assertions:
>
> dct:DDC rdf:type skos:ConceptScheme
>
> etc.
>
> ... or more generally: any sub-class of skos:Concept is potentially a
> ConceptScheme? Not all of the are, of course, but DDC etc are
> certainly
> candidates.
>
<snip>
> I think we agree on the overall relationships between the notions, but
> I'm for simplification and reuse in this case. If a ConceptScheme is a
> set of instances, why aren't we allowed to use it as such?
>
Your position is imo is a logically consistent position to take, and could be made to work as a convention. However, for the moment at least, I don't favour it, because I feel the abstraction folds several layers into one, which may not be a problem for current usage scenarios but could cause problems in the future. But that's just a feeling, I'll have a go at explaining it here, hopefully we can get a bit closer ...
I favour the following position (which isn't entirely consistent with what's currently written in the SKOS Core Guide [1] & Spec [2] but we're still working on them :) ...
Definition: A concept scheme is a [conceptual work/information resource] that identifies a set of concepts and explains their meaning and proper use.
Comment: A book, an xhtml file and an rdf/xml file may all be valid representations of a concept scheme, in so far as they convey statements in some language that express the information content of the concept scheme.
One reason I favour this position is that it is consistent with the recommended pattern for declaring RDFS/OWL ontologies. This pattern follows e.g.
--- RDF/N3 (standard namespaces)
<http://www.example.org/ontology> a owl:Ontology .
<http://www.example.org/ontology#aClass> a rdfs:Class;
rdfs:isDefinedBy <http://www.example.org/ontology> .
<http://www.example.org/ontology#aProp> a rdf:Property;
rdfs:isDefinedBy <http://www.example.org/ontology> .
--- RDF/N3
... and where an HTTP GET against the URI <http://www.example.org/ontology> should return an application/rdf+xml representation of the ontology.
My proposal is for SKOS Core to follow the same pattern, e.g.
--- RDF/N3 (standard namespaces)
<http://www.example.org/conceptscheme> a skos:ConceptScheme .
<http://www.example.org/conceptscheme#aConcept> a skos:Concept;
skos:inScheme <http://www.example.org/conceptscheme> .
--- RDF/N3
(Btw whether you use # or / URIs in the above examples I think is irrelevant wrt to the current discussion.)
In fact, the property skos:inScheme was originally a sub-property of rdfs:isDefinedBy, but I changed that for what I now think were erroneous reasons. Whether it should go back or not is open to further evaluation - I would like to better understand the relationship between these two properties (and I have got that wrong in the past, probably my biggest wopper to date :).
Another reason I favour this position is that it facilitates modelling clarity. So, for example, if you begin with the following declarations:
--- RDF/N3 (standard namespaces)
@prefix ex: <http://www.example.org/vocab#> .
ex:Concept a rdfs:Class;
rdfs:subClassOf skos:Concept.
--- RDF/N3
... it's hard to forget or misunderstand that, when you say that something 'is a ex:Concept', you are talking about something that is a conceptual resource. I.e. it's easy to write code examples and documentation that lead you the reader to have clear expectations about the appropriate set of properties to use in making statements about such a resource, and clear expectations about the behaviour of that resource in response to HTTP interaction where the resource has been denoted by an HTTP URI reference.
If, on the other hand, you have:
--- RDF/N3 (standard namespaces)
@prefix ex: <http://www.example.org/vocab#> .
ex:AAT a rdfs:Class;
rdfs:subClassOf skos:Concept
---
... it is easy (without well written documentation that requires careful reading) to get confused about what the hell sort of thing a resource of type ex:AAT is supposed to be.
You might think this is close to an argument about syntactic sugar, and many have argued (rightly imo) that what you use for URIs is utterly irrelevant because the damn things should only ever be handled behind the scenes. But, for example, what would you use as an rdfs:label for the ex:AAT class? Would you say:
ex:AAT rdfs:label 'The Art & Architecture Thesaurus'.
... or would you say e.g.:
ex:AAT rdfs:label 'The class of concepts from the Art & Architecture Thesaurus'.
... ?
You could end up with RDF statements that render into english as 'resource x is of type The Art and Architecture Thesaurus'.
I believe that, to allow the same resource to be both a concept scheme and a class of concepts doesn't promote clarity. I think a lot of people will get very confused about why or how the two things can be the same thing, and that will reduce perceived usability.
So anyway, I'll leave it there for now, but in summary my feeling is that, for the short term at least, it's best to model these two sorts of thing (a 'concept scheme' and a 'class of concepts') as distinct resources, until we have a better understanding of what sort of thing we want a 'concept scheme' to be. In the mean time, a formal relationship between the two types of entity can be expressed via an OWL restriction on the skos:inScheme property, as outlined in an earlier message.
Cheers,
Alistair.
[1] http://www.w3.org/2004/02/skos/core/guide/2005-02-15
[2] http://www.w3.org/2004/02/skos/core/spec/2005-03-03
|
