[Esip-preserve] On Earth Science Data File Uniqueness

[Bruce Barkstrom]

Curt's approach is a bit pessimistic.  One approach would be to recommend
that anyone creating a UUID should put it in a tabulation of created objects
and perhaps make that tabulation available to some socially responsible
registration authority.  This approach wouldn't require real-time
registration,
but would at least let someone know that an object with the ID had been
created.

Bruce B.

On Wed, Feb 9, 2011 at 2:58 PM, Ruth Duerr <rduerr at nsidc.org> wrote:

> Well this has been an interesting discussion today.  I've heard good
> compelling arguments for two competing best practices for using UUID's
> (Chris' use of a message digest form of UUID and Curt's pure Unique
> Identifier form of UUID).  Both seem to be variants on the Unique Identifier
> use case from the assessment paper with different implications for
> provenance (Chris's a Unique Identifier with trust value and Curt's a Unique
> Identifier with provenance value).  I also suspect that there are actually
> many more use case and use case variants than we've even heard about yet.  I
> think that this just reinforces one of the conclusions of the paper, that
> multiple identifiers will absolutely be required.
>
> As for Bruce's question - if all I have is a Unique Identifier (and no
> Unique Locator) how do I find the file and all the rest of the information
> about it - that's always been a problem, one that Unique Identifiers by
> definition have nothing to say about.  In order to have received the file,
> someone somewhere must have had the Unique Locator - they should have passed
> that along either explicitly or within the metadata...  If they didn't, oh
> well.... maybe a Google search for the UUID will help or maybe you should go
> back and ask them for it.
>
> Ruth
>
> On Feb 9, 2011, at 12:27 PM, Bruce Barkstrom wrote:
>
> My argument is "where do you go to get metadata when
> all you've got is an ID?"  UUID's are fine - but certainly don't
> contain redirection addresses.  To paraphrase, "knowing that
> this file is called 'Bob' doesn't tell me which family to call to
> find out where I should return him, nor does it tell me what
> format he's in."  So where do we get that.  In human terms,
> where do we find his birth certificate?  This is kind of an inverse
> to the problem "given an ID, where do I find a file?" which is the
> locator use case problem.  This one is "I've got an ID and a file,
> where do I go to find out about if if that's all I've got?"
>
> Bruce B.
>
> On Wed, Feb 9, 2011 at 10:21 AM, Curt Tilmes <Curt.Tilmes at nasa.gov> wrote:
>
>> On 02/09/11 10:14, Bruce Barkstrom wrote:
>> > The question on my mind is sort of "If you come across a file with a
>> > UUID, who produced it?"
>>
>> I agree, that is an important question and needs to be addressed, but
>> UUID doesn't address it, nor was it intended to.
>>
>> > This isn't quite the same as the unique locator use case in the
>> > paper, since the question isn't "which sources could provide me with
>> > an authentic copy of a particular kind of file?"  It's more along
>> > the line of "where did this fellow 'Bakak' come from?"
>>
>> Sure, but without the identifier, you would still have the question
>> "where did this fellow come from?"  to which the response is "Who are
>> you talking about?"
>>
>> The identifier at least allows you to refer to him by name..
>>
>> Is your argument that we SHOULD have good metadata (I agree), or that
>> we SHOULD NOT assign UUIDs?
>>
>> Curt
>> _______________________________________________
>> Esip-preserve mailing list
>> Esip-preserve at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-preserve
>>
>
> _______________________________________________
> Esip-preserve mailing list
> Esip-preserve at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-preserve
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-preserve/attachments/20110209/a50e0bdb/attachment-0001.html>