On Thu, 2005-03-10 at 14:27 +0000, Miles, AJ (Alistair) wrote:
> Hi all,
>
> Firstly I should say the designers of SKOS Core have considered
> interoperability with DQC-RDF a major design goal from the very
> beginning. I'm really glad we're having this discussion, as it gives
> us a chance to evaluate whether we can reasonably achieve that goal,
> with the SKOS Core Guide and Vocabulary Specification documents about
> to go to first public working draft.
I'm very happy to hear that!
> Regarding the relationship between a 'SKOS Concept Scheme' and a 'Vocabulary Encoding Scheme' ...
>
> One can declare a class of concepts as a subclass of a restriction on
> the skos:inScheme property. So, for example (using the AAT as a
> hypothetical example):
I understand what you are saying, but I'm not sure I understand the need
to discuss inferences in this context... except to see that the
"obvious" rules are sane.
> A distinction is made in SKOS core between a 'concept scheme' and a
> 'class of concepts', and a relationship can be formally asserted
> between the two via an expression such as the above. This distinction
> is made in SKOS Core because we reached a consensus that a concept
> scheme is more than just a set of concepts - it may also include
> semantic relationships between concepts (see the definition of
> skos:ConceptScheme in [1]; see also the section on extended concept
> types in the section [2] of an earlier draft of the SKOS Core Guide,
> which was dropped from the latest draft because it will probably be
> moved to a separate note).
That seems like a good summary of the situation. Now that I've seen
this, could you clarify the following?
Quoting from [1]: "As mentioned in the introduction, a 'concept scheme'
is defined here as: a set of concepts, optionally including statements
about semantic relationships between those concepts."
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.
Or am I missing something?
>
> (Of course, providing the URI of a conceptual resource is highly
> desirable, as it removes the difficulty of having to merge blank nodes
> on the basis of a combination of properties, which DCQ-RDF currently
> necessitates; see also the section 'Concept Identity' in [3] (an
> earlier draft of the SKOS Core guide), dropped from the latest draft
> because it depends on the outcome of this discussion, which at the
> time had not yet begun :)
Hmmm. DCQ/RDF certainly allows the use of URIs instead of just blank
nodes. No blank node merging is necessary. Where did you get that idea
from? Actually, the fact that it uses URIs is a fundamental reason for
this discussion.
> Another way of expressing this position is to say that I believe the
> following statements are entirely reasonable:
>
> dct:DDC rdfs:subClassOf skos:Concept .
> dct:LCSH rdfs:subClassOf skos:Concept .
> dct:MESH rdfs:subClassOf skos:Concept .
> dct:UDC rdfs:subClassOf skos:Concept .
>
> ... or more generally: any class that is intended to 'qualify' the
> dc:subject property is a sub-class of skos:Concept.
Well, it would seem the definition of skos:Concept is loose enough....
In principle I agree, though.
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.
>
> I believe we can take this position if we choose, because the
> semantics of the rdf:value property are essentially nil, and because
> concommitantly DCMI has as yet made only a very vague ontological
> commitment to the nature of any resource that is a member of a class
> of 'vocabulary encoding scheme values'.
Again, rdf:value is not part of the problem at all.
>
> How does that sound?
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?
/Mikael
|