> David Wood suggests two changes in how DCAM constructs are
> represented in RDF :
> 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 .
> 2. Instead of using rdf:value to relate a value to a
> DCAM Value String [1, section 4.6], David suggests using
> skos:prefLabel .
> Some first reactions:
> -- The domain of skos:inScheme was left unspecified 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).
> Also, skos:inScheme is better-known than dcam:memberOf.
> So #1 seems like a sound idea.
And the range of skos:inScheme is skos:ConceptScheme?
"A SKOS concept scheme can be viewed as an aggregation of one or more SKOS concepts."
If an skos:ConceptScheme is really a set of things of any type, then the change should be OK.
Or we could keep dcam:memberOf and make it a subproperty of skos:inScheme? (Though yes, I appreciate that means apps having to make the inference)
I don't feel strongly either way on proposal (1).
> -- The domain of skos:prefLabel was also left unspecified ,
> so its use does not imply that the subject of a statement is
> a SKOS concept. On the other hand, I believe the
> correct use of rdf:value has long been unclear.
> So #2 seems like a good idea too, though as part of such a
> change we would need to understand better where the problem
> with rdf:value lies.
Two points occur to me on proposal (2):
(a) According to
the range of skos:prefLabel is the class of plain literals. The DCAM notion of value strings currently includes typed literals. See e.g. the example in 4.3 of
where both a plain and typed literal are provided
So (with the current concept of "value string") I don't think skos:prefLabel would work as a straight substitute for the use of rdf:value?
(b) I didn't think the DCAM notion of value string carried a sense of "preferred", so another of the SKOS label properties may be more appropriate (skos:altLabel?) - but that still leaves the range question.
I see SKOS also has a skos:notation property but that seems to be explicitly for "non-natural-language" literals?