Hi Tom,
My 2 cents would be *not* to include such local identifiers. They will make DCAM more complex to understand. Especially if one considers the potential redundancy with:
- URIs -- it's more difficult to encourage the use of URIs if you still have local identifiers at the same level in your AM. Unless you've got a real use case for local identifiers in the DC world. But is it the case?
- dc:identifier -- if local identifiers should indeed have a "lower status" in the AM (ie., without a clear use case) then dc:identifier (or a sub-property of it) can be used to pass them on to data consumers.
Antoine
> On Tue, Jan 03, 2012 at 02:19:21PM -0500, Tom Baker wrote:
>> DescribedResourceID - new!
>> ValueURI
>> ValueID - new!
>
> Section 2.4 of DCAM [1] notes:
>
> Each non-literal value may be the described resource in a separate
> description within the same description set - for example, a separate
> description may provide metadata about the person that is the creator of
> the described resource. A literal value can not be the described resource
> in a separate description.
>
> and Section 6 (Encoding Guidelines) says:
>
> Encoding guidelines should indicate how a non-literal value can be treated
> as a described resource in a separate description in those cases where a
> non-literal value surrogate does not include a value URI.
>
> In other words, the existing DCAM relegates handling of local identifiers
> (blank-node identifiers) to Encoding Guidelines and does not include these
> in the core Description Set Model.
>
> If we assume that the Description Set Model should provide a full set of
> required syntactic slots, however, then I should think we would want to put
> such local identifiers into the core model. Again, I think we should take the
> hint from DC-TEXT, which includes entities for ValueId and ResourceId [2] not
> present in the DCAM Description Set Model itself.
>
> Tom
>
> [1] http://dublincore.org/documents/abstract-model/
> [2] http://dublincore.org/documents/dc-text/
>
|