On Wed, 9 Mar 2005, Mikael Nilsson wrote:
> Well, I think it's somewhat inevitable. What if DC used some other
> method of linking Vocabulary encoding schemes to a value, such as a
> dcterms:inScheme property? That wouldn't help a bit, as ontology
> designers would still need to be aware of this property in order to be
> compatible.
Yes, agreed.
> Compatibility isn't something that happens when you look the
> other way... and now that DC and SKOS *are* aware of each other,
> compatibility is at least an option.
Yes.
> That said, it isn't really a question of incompatibility, just
> incompleteness. The SKOS core guide says:
>
> "To use SKOS-Core with Dublin Core, make concepts the objects of
> statements using the dc:subject property."
>
> There is no mention of vocabulary encoding schemes. And this will work
> in all syntaxes that support using value URIs.
Yes, that was basically what I was thinking. And those value URIs can
be deployed without a vocabulary encoding scheme URI. I agree that means
the "statement" carries less information, but it can be done without
breaking anything and without changing anything.
> What would be needed to complement SKOS is a notion of "class of
> concepts". As SKOS has chosen not to introduce that, there simply are no
> vocabulary encoding schemes for SKOS values.
Yes. Or there is the class skos:Concept as "vocabulary encoding scheme",
which I think fits the DCAM - but it tells an application only
that the value is an SKOS concept.
> Or if you like, you can add
> one of your own without breaking anything.
Yes, agreed. And that was Andy's point, I think - and that it would be
onerous for DC implementers who wanted to reference SKOS concepts _and_
use a "vocabulary encoding scheme URI" (other than skos:Concept) if they
had to do that (and I can certainly imagine that many implementers would
be confused about exactly why they couldn't just use an SKOS concept
scheme URI as a Vocabulary Encoding Scheme URI).
> Incomplete, but not wrong.
>
> Of course, it would be nice if SKOS and DC could sort it out. It would
> be a pity if SKOS would fall into the class of interoperability
> standards that tries to do things afresh without looking at existing
> standards and practices. While using rdf:type is certainly a modeling
> choice by DC, I don't think it's entirely unreasonable.
Oh, yes, agreed. I wasn't suggesting that rdf:type or skos:inScheme was
better or worse (though I wondered whether there may be issues to do
with the use of instance/class relations that conditioned the SKOS
decision.)
I do agree that it would be ideal if the models aligned a bit better,
particularly in terms of explaining the combined use of those models to
users (I can already see "So tell me again why an SKOS Concept Scheme is
different from a Vocabulary Encoding Scheme" becoming a VFAQ!)
But OTOH I was hesitating to say that it was strictly necessary that SKOS
provided a "class of SKOS concepts" mechanism in order for SKOS concepts
to be referenced in DC metadata descriptions.
Pete
|