On Oct 15, 2009, at 1:25 AM, Thomas Baker wrote:
> >David Wood suggests two changes in how DCAM constructs are
> >represented in RDF [1]:
> >
> >1. Instead of using dcam:memberOf to relate a value to a
> > DCAM Vocabulary Encoding Scheme [1, section 4.5], David
> > suggests using skos:inScheme.
Points made about proposal #1 to date:
-- The range of skos:inScheme is skos:ConceptScheme [3].
-- The domain of skos:inScheme was left unspecified [2] in
order to provide the flexibility to extend a concept scheme
with classes of resource other than skos:Concept (i.e., the use
of skos:inScheme does not imply that the subject is a concept).
-- That said, the SKOS Reference does indeed say [3]:
"A SKOS concept scheme can be viewed as an aggregation of one
or more SKOS concepts."
implying that a SKOS concept scheme is intended to be
understood as a set of SKOS concepts. However, the wording
"can be viewed" seems vague enough so as not to actually
_contradict_ the notion of a skos:ConceptScheme as a set of
things of any type (i.e., instances of classes other than
skos:Concept).
-- Bernard elaborates on the consequences of entailments [5]:
> #1 : Complete agreement, being aware of consequences. If
> the domain of skos:inScheme is open, its range is
> skos:ConceptScheme, so using this property entails that any
> dcam:VocabularyEncodingScheme used as the object of
> skos:inScheme is a skos:ConceptScheme. The following
> logical step is to declare dcam:VocabularyEncodingScheme as
> a subclass of skos:ConceptScheme. And the next one is
> asking what is specific to this subclass. If there is no
> specificity, dcam:VocabularyEncodingScheme could as well
> (should?) be replaced in the abstract model by
> skos:ConceptScheme. Do you want to go this far in
> entailments?
In other words, replacing dcam:memberOf with skos:inScheme
suggests that we also declare:
dcam:VocabularyEncodingScheme rdfs:subClassOf skos:ConceptScheme
and that we replace the notion of VES in DCAM with
that of SKOS concept scheme.
-- dcam:memberOf could be declared a subproperty of skos:inScheme:
dcam:memberOf rdfs:subClassOf skos:inScheme
My personal position, in light of the above:
-- That DCMI should declare both:
dcam:VocabularyEncodingScheme rdfs:subClassOf skos:ConceptScheme
and
dcam:memberOf rdfs:subPropertyOf skos:inScheme
-- That the DCAM Description Set model [4] should be revised to
use skos:ConceptScheme instead of (or rather in addition to)
dcam:VocabularyEncodingScheme, underlining the equivalence of
the two and emphasizing that a SKOS concept scheme is
understood _not_ to be limited to SKOS concepts.
-- That DCAM should be revised to use skos:inScheme instead of
dcam:memberOf -- _unless_ we do in fact see a significant difference
between a SKOS concept scheme and a VES.
I would want to get some input on whether sub-property relations
is the way to do this (as opposed to, say, owl:equivalentProperty [6]).
Am I overlooking anything?
Tom
[1] http://dublincore.org/documents/dc-rdf/#sect-4
[2] http://www.w3.org/TR/skos-reference/#L2805
[3] http://www.w3.org/TR/skos-reference/#schemes
[4] http://dublincore.org/documents/abstract-model/
[5] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0910&L=dc-architecture&P=2739
[6] http://www.w3.org/TR/owl-ref/#equivalentProperty-def
--
Thomas Baker <[log in to unmask]>
|