Hi James,
As one of NameUasage camp, I would rephrase as:
"Any data object reprsenting an occurrence of a NameString as it appears, or, interpreted as explicit by the data provider, within some form of static documentation."
Fine by me!
I suspect we may slipping off from data object identification to how to when one should create a data objects.
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