Maybe I'm missing something, but i'll jump into the dialog midstream...

URI : Seems like local identifiers align with RDF blank nodes as a structural element to tie together a graph of entities. The same argument is made in LoD concerning blank nodes. They limited thier use in an effort to reduce the complexity of the LoD model allowing it to be more easily implemented, which is jumpstarting the "Data Web" and possibly the most active use of DC to date.

dc:identifier : I still think is vague to just define blank nodes being restricted to being only in an identifier value. They are generally subjects/entities referenced by the value. This importance seems overlooked in the definition.

Note the exclusion of blank nodes in LoD is also for the benefit of Supporting efficient SPARQL querying of the graph. So I think that's a sensible observation. I think DCAM should target the "practical" and not the "full" expression of RDF semantics. There's a lesson here to learn from LoD. The full suite of RDF constructs Would make the LoD cloud to complex to support by query tools.

You know what they say about when you have a hammer... Everything starts to look like a nail.

Mark

On Wednesday, January 4, 2012, Antoine Isaac <[log in to unmask]> wrote:
> 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/
>>
>

--

[log in to unmask]" alt="@mire Inc.">

Mark Diggory
2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
Esperantolaan 4, Heverlee 3001, Belgium
http://www.atmire.com