Ricardo, Sounds good to me - this is pretty much how I saw the solution as well. Kevin

...

...

ricardo@TDWG.ORG 16/11/2005 3:24:27 a.m. >>>

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/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++