Basic requirements for a basic GUID infrastructure

[Ricardo Scachetti Pereira]

    Rich,

    I think the ongoing discussion about taxon names and concepts is
within the boundaries defined for the GUID group. We actually benefit
from having a broader scope at this point because we want to explore a
wide variety of use cases and cover a broader range of uses for GUIDs in
our domain. I don't see much problem if not everyone can or want to
follow the particular discussion details.
    I also think that the specimen group has a similar concern about how
many "kinds" of GUIDs we have. For example, we can issue GUIDs to a
survey or collecting event, a lot, an individual, parts of an
individual, tissues, etc. However, Donald suggested a neat solution to
break down the problem into smaller manageable pieces, which is to
develop a shared ontology and relate each record in our specimen network
to the classes in the ontology. So in the end, we only have one kind of
GUID and many metadata services laying on top of that doing the various
mappings. In my opinion, this kind of solution lay down a number of
requirements for an underlying GUID infrastructure:

1) Identifiers deliver you to objects (where feasible).
2) Identifiers deliver you to object metadata.
3) Each object should wear its own identifier (desirable).
4) Identifiers are issued in a descentralized manner, i.e., by
independent agents.
5) Ids identify digital objects, not physical ones.
6) Other requirements I missed?

    Then I pose the question, would the above assumptions fulfill the
requirements of the candidate solutions laid out in the previous taxon
concepts and names discussion?
    You might argue that the current taxon names and concepts discussion
would require a centralized ID issuing authority, but still, the
descentralized architecture is more general than the centralized one,
i.e., a central issuing facility would use basic components created by
the descentralized architecture, plus some more software.
    Cheers,

Ricardo



Richard Pyle wrote:

>Yes, but I think there is at least *one* relavent point to this that is more
>directly related to GUIDs for taxon objects: one kind? two kinds? three
>kinds? more?  I think we generally assume that there is only one "kind" of
>GUID for specimens (i.e., we aren't speaking in terms of one "kind" of GUID
>for whole specimens, and another separate "kind" of GUID for specimen parts,
>and yet another separate "kind" of GUID for multi-part "specimens" like
>multi-taxon fossil specimens...etc.).  Similarly, we are generally thinking
>in terms of one "kind" of GUID for Documentation instances (not separate
>"kinds" for journal articles vs. books; or even published vs. unpublushed).
>Therefore, I think there should be only one "kind" of GUID for taxon objects
>as well -- and the only one that I know of that can broadly accomodate all
>sorts of subtypes is the generic "NameUsage" instance.
>
>If the question of "How many 'kinds' [domains] of taxon GUIDs should there
>be?" is beyond the scope of this discussion, then frankly I'm not clear on
>what sorts of topics fall *within* the scope of this discussion (other than
>the trusty LSID vs. DOI vs. whatever debate).
>
>
>
>>I'm very sorry that my real life prevents to contribute, or even to
>>read the on-going important discussion on GUID...
>>
>>
>
>Likewise, my apologies to the list if my rantings are not relevant to (or
>are external to) what is supposed to be discussed on this forum.
>
>Aloha,
>Rich
>
>
>






_______________________________________________________
Yahoo! Acesso Grátis: Internet rápida e grátis.
Instale o discador agora!
http://br.acesso.yahoo.com/