November 2005 - tdwg-tag - lists.tdwg.org

Re: GUID opacity
by Sally Hinchcliffe 17 Nov '05

17 Nov '05

Ricardo I think the issuing authority will tend to give a clue as to what the GUID refers to. However we do need to be careful that we don't rely on that being the case in any systems that we develop around them to retain opacity - otherwise we are building a layer of implicit business rules into LSIDs that they weren't designed to support and which could make the systems that rely on them more fragile than they need to be. Sally > Rich and all, > > I think Roger raised an interesting issue: GUID opacity. > Reading between the lines of the previous discussions regarding the many > types of GUIDs we should have, I suspect that some of us are assuming > that GUIDs should not be completely opaque. > > For example, when you say we should have a NameUsage GUID, for example, > would you hardcode that in the namespace of an LSID, like the following one? > > urn:lsid:some_authority.org:NameUsage:id1234 > > LSIDs and other GUID technologies require that their ids must be opaque. > However, due to the syntax of LSIDs, users might tend to circumvent that > requirement and use parts of the LSID (the namespace) for other purposes. > > In my opinion, breaking opacity might offer simple implementation path > to hardcode some semantics directly into the GUIDs without requiring any > other service layer. However, that might not be very extensible in the > sense that it doesnt allow for new classifications of GUIDs that have > been already issued. > > I think some of the specimen folks also tend to use this shortcut when > they offer to use same GUIDs for the same physical object. What is > attempted in that case is to hardcode known relationships between > specimens and to simplify identification of duplicates. But again, that > could be done in a more extensible manner via a shared ontology and > separate metadata services. > > Again, if decide to use the shared ontology idea (which we havent > discussed enough, but we should), we can keep our system flexible and > extensible, and we can leave our GUIDs semantically opaque. > > What are your thoughts on that matter? > > Cheers, > > > Ricardo > > > > > > > _______________________________________________________ > Yahoo! Acesso Grátis: Internet rápida e grátis. > Instale o discador agora! > http://br.acesso.yahoo.com/ > *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: Taxon debate synthesis?
by Roderic Page 16 Nov '05

16 Nov '05

Two quick comments: On 16 Nov 2005, at 12:04, Richard Pyle wrote: > > I would point out that within the "TaxonName" flavor, there may be > "subflavors" like "Basionym", "New Combination", and "Orthographic > Variant" -- just as within the TaxonConcept flavor there are > "Original", > "Revision", "Nominal", etc. subflavors. (Apologies for my Amerikanized > spelling...) > Before we have a flurry of name flavours (yuck), I'd suggest that many of these "flavours" are really relationships between names, e.g. "Physeter catadon" is a misspelling of "Physeter catodon". Hence, I'd argue for having GUIDs for these two name strings, and in the metadata for one name have something like <isMisspellingOf rdf:resource="urn:lsid:authority:namespace:123" /> Hence, I think before we embark on adding complexity, why not have GUIDs for names and then specify relationships between these names? This is what I've been doing with the LSIDs we serve here. We could do with an ontology for these relationships so that, for example, if somebody asks for the synonyms of name "x", and two names are linked by the relationship "isBasionymOf" we recover that relationship (in other words, our tools know that 'isBasionymOf" is a kind of synonym). Again, let's try and keep things simple. This leads to a much more general topic, but I think if we adopt RDF for our metadata we gain a lot of query and inference tools "for free." GUIDs by themselves are boring, it's the metadata that matters. > > My general feeling is that most of the useful information is metadata, > the > only candidates for data (in my mind) being the literal text string > (NameString), a ref pointer to a defined Documentation instance (if > any), > and perhaps position information (e.g. page) within the Documentation > instance. All of these might be intially recorded in error, but could > be > corrected via the LSID revision id (version). I think everything about a name probably is metadata, and doing this opens up the possibility of doing useful things with that metadata (see above). In the LSID stuff we've been doing at Glasgow the only time we provide data is if we are serving images, in which case it makes sense to serve a stream of bytes (e.g., a TIFF image). In one sense, data isn't that interesting (or, put another way in many cases it requires a person to make sense of it, whereas computers can handle metadata). Regards Rod ------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page(a)bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names at http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species at http://ispecies.org

1 0

Re: Basic requirements for a basic GUID infrastructure
by Kevin Richards 16 Nov '05

16 Nov '05

Ricardo, Sounds good to me - this is pretty much how I saw the solution as well. Kevin >>> ricardo(a)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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Taxon debate synthesis?
by Roger Hyam 16 Nov '05

16 Nov '05

I think Ricardo has hit it the nail on the head in his recent post. Here is a possible solution that might just work! 1. Only one GUID system. 2. For taxon stuff we call these NameUsage GUIDs 3. NameUsage GUIDs come in different 'flavours' - probably identified by the metadata returned. 4. Some flavours may be TaxonName, TaxonConcept and NameOccurrence 5. We have an ontology that defines the types of NameUsage GUID. 6. The ontology can evolve through time catering for different needs. To restate what Ricardo suggest this would entail: 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 decentralized manner, i.e., by independent agents. 5. Ids identify digital objects, not physical ones. 6. more... Questions this raises for me are: 1. Do we have a single managed ontology for all TDWG GUIDs i.e. we have a single ontology to manage different types of specimen GUID and different types of NameUsage GUID. This looks like a central ontology for taxonomic object classes and may take the debate outside the GUID discussions into general architecture. 2. Can you tell by looking at a GUID what it's class is. i.e. do we embed the class name in the LSID namespace. This would be useful for debugging and human readability but is really bad practice as IDs should be opaque (people should not start parsing pointers for purposes other than resolving them). 3. If we use LSIDs what do we include in the 'data' returned and what in the metadata returned? I believe the metadata can change but data can't so we may want to put our metadata as the LSID data (I don't think an object class should change - I may be wrong) There are probably other questions. This may be a fruitful way forward. Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: GUID opacity
by Richard Pyle 16 Nov '05

16 Nov '05

Hi Ricardo, > For example, when you say we should have a NameUsage GUID, for example, > would you hardcode that in the namespace of an LSID, like the > following one? > > urn:lsid:some_authority.org:NameUsage:id1234 Only if TDWG followed your suggestion of breaking opacity and set forth an equivalent standard for other "domains" of GUID; e.g.: urn:lsid:some_authority.org:Specimen:id4321 urn:lsid:some_authority.org:Documentation:id9876 urn:lsid:some_authority.org:Agent:id5678 The main reason I am somewhat uncomfortable with LSIDs is that I don't think they are opaque enough (or, as you described, offer too much temptation to break opacity), in the sense that they embed human-intelligible information within the GUID itself. > LSIDs and other GUID technologies require that their ids must be opaque. > However, due to the syntax of LSIDs, users might tend to circumvent that > requirement and use parts of the LSID (the namespace) for other purposes. I believe this should be avoided. > In my opinion, breaking opacity might offer simple implementation path > to hardcode some semantics directly into the GUIDs without requiring any > other service layer. However, that might not be very extensible in the > sense that it doesn’t allow for new classifications of GUIDs that have > been already issued. Again, my gut feeling is that this would lead to long-term headaches for future data managers. I would rather see some attribute (something like "Class" -- though this word is over-used!) be part of any TDWG LSID standard such that each LSID includes a metadata element from among a shared ontology (e.g., "Specimen" or "NameUsage" or "Documentation"). LSID issuers may well use the namespace for this purpose, but I think it wise to at least *try* to render the namespace semantically opaque, by embedding this sort of distinction as a standard metadata attribute of any TDWG-compliant LSID. > But again, that > could be done in a more extensible manner via a shared ontology and > separate metadata services. I would prefer that approach. > Again, if decide to use the shared ontology idea (which we haven’t > discussed enough, but we should), we can keep our system flexible and > extensible, and we can leave our GUIDs semantically opaque. Agreed! Aloha, Rich Richard L. Pyle, PhD Database Coordinator for Natural Sciences and Associate Zoologist in Ichthyology Department of Natural Sciences, Bishop Museum 1525 Bernice St., Honolulu, HI 96817 Ph: (808)848-4115, Fax: (808)847-8252 email: deepreef(a)bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html

1 0

Re: Taxon debate synthesis?
by Richard Pyle 16 Nov '05

16 Nov '05

> Before we have a flurry of name flavours (yuck), I'd suggest that many > of these "flavours" are really relationships between names, Absolutely! -- I was using "flavours" in the sense that they would be defined in terms of relationships, not in terms of the data objects themselves. Sorry if it seemed I meant it that way. Perhaps there is value in establishing a metadata attribute for "IsBasionym" or something like that, but I think these things should really be defined by relationships among GUID-represented data objects, rather than as attributes of the data objects themselves. > Hence, I think before we embark on adding complexity, why not have > GUIDs for names and then specify relationships between these names? > This is what I've been doing with the LSIDs we serve here. Why not have GUIDs for NameUsages, and then specify relationships between these NameUsages? (simply because "names" are much more difficult to define than "NameUsages") > We could do with an ontology for these relationships so that, for > example, if somebody asks for the synonyms of name "x", and two names > are linked by the relationship "isBasionymOf" we recover that > relationship (in other words, our tools know that 'isBasionymOf" is a > kind of synonym). Sounds good to me! > Again, let's try and keep things simple. Agreed! And simple not so much for the sake of simplicity, but more for the sake of flexibility. > This leads to a much more general topic, but I think if we adopt RDF > for our metadata we gain a lot of query and inference tools "for free." > GUIDs by themselves are boring, it's the metadata that matters. Agreed! > > My general feeling is that most of the useful information is metadata, > > the > > only candidates for data (in my mind) being the literal text string > > (NameString), a ref pointer to a defined Documentation instance (if > > any), > > and perhaps position information (e.g. page) within the Documentation > > instance. All of these might be intially recorded in error, but could > > be > > corrected via the LSID revision id (version). > > I think everything about a name probably is metadata, and doing this > opens up the possibility of doing useful things with that metadata (see > above). In the LSID stuff we've been doing at Glasgow the only time we > provide data is if we are serving images, in which case it makes sense > to serve a stream of bytes (e.g., a TIFF image). In one sense, data > isn't that interesting (or, put another way in many cases it requires a > person to make sense of it, whereas computers can handle metadata). After having just spent the past couple hours brushing up my LSID "geek-speak", I agree completely with Rod on this. Aloha, Rich

1 0

GUID opacity
by Ricardo Scachetti Pereira 16 Nov '05

16 Nov '05

Rich and all, I think Roger raised an interesting issue: GUID opacity. Reading between the lines of the previous discussions regarding the many “types of GUIDs” we should have, I suspect that some of us are assuming that GUIDs should not be completely opaque. For example, when you say we should have a NameUsage GUID, for example, would you hardcode that in the namespace of an LSID, like the following one? urn:lsid:some_authority.org:NameUsage:id1234 LSIDs and other GUID technologies require that their ids must be opaque. However, due to the syntax of LSIDs, users might tend to circumvent that requirement and use parts of the LSID (the namespace) for other purposes. In my opinion, breaking opacity might offer simple implementation path to hardcode some semantics directly into the GUIDs without requiring any other service layer. However, that might not be very extensible in the sense that it doesn’t allow for new classifications of GUIDs that have been already issued. I think some of the specimen folks also tend to use this shortcut when they offer to use same GUIDs for the same physical object. What is attempted in that case is to hardcode known relationships between specimens and to simplify identification of duplicates. But again, that could be done in a more extensible manner via a shared ontology and separate metadata services. Again, if decide to use the shared ontology idea (which we haven’t discussed enough, but we should), we can keep our system flexible and extensible, and we can leave our GUIDs semantically opaque. What are your thoughts on that matter? Cheers, Ricardo _______________________________________________________ Yahoo! Acesso Grátis: Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

1 0

Re: Taxon debate synthesis?
by Richard Pyle 15 Nov '05

15 Nov '05

Hi Roger, > Here is a possible solution that might just work! > > 1. Only one GUID system. > 2. For taxon stuff we call these NameUsage GUIDs > 3. NameUsage GUIDs come in different 'flavours' - probably identified by the metadata returned. > 4. Some flavours may be TaxonName, TaxonConcept and NameOccurrence > 5. We have an ontology that defines the types of NameUsage GUID. > 6. The ontology can evolve through time catering for different needs. This is *EXACTLY* what I have been trying to describe!! Thank you, Ricardo and Roger, for communicating in one short post what I have evidently failed to communicate in many long, ranting posts! :-) I really should become more fluent in the "object/class/ontology/identity" geek-speak...but my brain is already full with taxonomy & database geek-speak (not to mention technical diving geek-speak). I would point out that within the "TaxonName" flavor, there may be "subflavors" like "Basionym", "New Combination", and "Orthographic Variant" -- just as within the TaxonConcept flavor there are "Original", "Revision", "Nominal", etc. subflavors. (Apologies for my Amerikanized spelling...) > Questions this raises for me are: > > 1. Do we have a single managed ontology for all TDWG GUIDs i.e. > we have a single ontology to manage different types of specimen > GUID and different types of NameUsage GUID. This looks like a central > ontology for taxonomic object classes and may take the debate outside > the GUID discussions into general architecture. I think this is an important issue that needs to be discussed, but is probably beyond the scope of this GUID discussion forum. > 2. Can you tell by looking at a GUID what it's class is. i.e. do > we embed the class name in the LSID namespace. I would say "definitely no". For many reasons...one of which is that the same GUID might be returned with different metadata depending on what "flavor" is requested/delivered (e.g. GUID 1234 might apply to a NameUsage instance that represents both a Basionym Creation [TaxonName flavor], and a TaxonConcept of type "Original"). I think this is something that should be handled by the resolution service, via the established ontology. > 3. If we use LSIDs what do we include in the 'data' returned and what > in the metadata returned? I believe the metadata can change but data > can't so we may want to put our metadata as the LSID data (I don't > think an object class should change - I may be wrong) For me to understand the question, I'll need you to elaborate on what you mean by "object class". I can think of at least two possible meanings of this term in this context, and my answer would depend on which meaning you intended. My general feeling is that most of the useful information is metadata, the only candidates for data (in my mind) being the literal text string (NameString), a ref pointer to a defined Documentation instance (if any), and perhaps position information (e.g. page) within the Documentation instance. All of these might be intially recorded in error, but could be corrected via the LSID revision id (version). But I have neither sharp insight nor strong opinions regarding such matters, so I'll leave that level of technical debate to more capable individuals. > There are probably other questions. I have several, but I think they mostly lie outside the scope of this discussion forum, and are perhaps best addressed down the road (e.g., at the February workshop). > This may be a fruitful way forward. Yes, I hope so. Aloha, Rich

1 0

Basic requirements for a basic GUID infrastructure
by Ricardo Scachetti Pereira 15 Nov '05

15 Nov '05

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/

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Kennedy, Jessie 15 Nov '05

15 Nov '05

Hi All Following up on Rich and Roger's discussion..... > Really?? Which two? I assume you mean "one kind of GUID" for taxon > objects, vs. "two kinds of GUIDs". But earlier Rod Page had proposed > three > different "levels", with GUIDs for all three. Others seemed to like to > three-level approach, but some slightly re-defined what the three levels > ought to be. I pointed out at least 8 different "units" of a name, not > all > of which could be unambiguously pidgeonholed into either a "TaxonName" > object or a "TaxonConcept" object. You advocate two kinds (levels? types? > domains?) of GUID for taxon objects (i.e., Name & Concept). Personally, I > think the ultimate goal should be as you describe: separate GUID > domains/kinds/types for TaxonNames vs. TaxonConcepts. But Rod Page and > others contributing to this thread have convinced me that this might be > reaching for too much at this stage of the game. Thus, I am comfortable > with the idea of establishing one domain/kind/type of GUID within the > taxonomy realm, that is the most flexible and unambiguous of them all, and > which can serve as a "stepping-stone" and/or surrogate to a future > informatics world where we have an unambiguous distinction between a > "TaxonName" object and a "TaxonConcept" object. Importantly, establishing > GUIDs for usage instances now does not carry the risk that they will be > rendered useless in the future, because I think there will always be value > in identifying unique NameUsage instances. > > > Perhaps what we should do is each put together a page on the > > wiki expounding either of the approaches. It will be easier > > for some one coming along later to get up to speed on > > the arguments and add to them. We then have both cases clearly > > stated and we can see which one a consensus builds around. > > I agree with this, and took a hasty first stab at it with "Scenario 5" on > the page you created: > > http://wiki.gbif.org/guidwiki/wikka.php?wakka=SeparateNamesAndConcepts > > If I can find time, I'd be happy to expand it on a dedicated page, using a > real-world example (maybe a PDF excerpt of a representative documentation > instance). I'd be happy to provide the PDF example, if you wish. > I find this all very interesting.... What Rich is proposing here is what the TCS originally proposed to the TDWG community in terms of a model for Taxon concepts and names. However as Rich pointed out I was of the view that if this were to be implemented then we should focus on "original concepts" i.e. the first usage of the name as a result of some taxonomic work and "revision concepts" where a name was redefined as a result of some taxonomic work. What I was doing was to try and restrict the number of "potential concepts" that we had to deal with. As everyone on this list is probably aware as soon as we talk about concepts there are those who will take us into the realm of every time a concept is thought of in someone's minds we have another potential concept which is clearly not practical for our purposes. So using intent to define new concepts limited the number of concepts to be managed (and IMHO would link the taxon concept work to better science). My argument for dealing only with original concepts and revision concepts and not names was that the nomenclators were really capturing information on original concepts (but without explicitly storing all the definitional information in their databases). So couldn't we somehow leverage this to get progress on names and concepts. Where the original TCS approach differs from name usage was that I didn't want just any usage of the name to be confused with well defined taxon concepts or at least (as Roger explained) concepts where there was an intent to define a concept rather than say identify an instance to some existing taxon concept or even just refer to one in a text. General name usage might be useful in the long run but in terms of helping us decide what people have recorded information about out there, but to use them as a basis for, say, data integration issues and resolution then I'm not so sure it'll help us at first anyway. However this idea was rejected by the community - people didn't want to confuse names with concepts as much as I tried to convince them otherwise - and one of my reasons was as Rich points out you would have a single GUID "type". So we changed TCS so that we could have TaxonNames and TaxonConcepts as separate top level elements (implying separate GUIDs). I think one of the main reasons for this was that people seemed to think that we could sort the names problem more easily and then we could use this "agreed" list of names as the basis on which to build all other systems including taxon concepts. I was of the view that if this was what was needed to progress things then I was happy to separate them out (knowing in my mind that we would need now at least 2 GUIDS for what came from the same publication in the case of original concepts - we would have the name details denoting the publishing of the name for the first time and then we would have the concept as defined in the same publication - probably same page etc. and possibly a nominal concept so that I could identify something as this "name" but using a taxon concept GUID). So now we were at two "types" of GUIDS. Then Rod suggested a 3 level approach - the two just mentioned and name strings. The discussion between Rod and Rich on why give a name string a GUID was interesting. I could see Rich's point that the GUID is a name string so what's the difference really, you could match on name strings just as easily as GUIDs (maybe). Of course what came out of that was that Rod's name strings weren't simply name strings as Rich (and I and maybe others) had originally thought but that they were name usages, hence I guess Rich's renewed support for the name usage approach (still not clear if name usages here are any name usages or for intended taxon concepts as Rich suggested in a previous email on the topic). So it seems we've come full circle again and a re still asking the same questions. Do we want a list of name strings without any attribution? What good would this be. I guess as an index into other sources as others have saidpossibly to help with spelling mistakes etc which could be mapped to possible names or concepts, but at that point I'd see them turning into name usages because people would want to know where it was used so they could get a better idea of what was meant. Trouble is as soon as we start attributing names to publications or any other source we get this enormous explosion of name usages and then we need to deal with the equivalences between them. Which is really the taxon concept problem but multiplied to the power ? So I vote for 2 GUID systems for the time being with the proviso that TaxonName GUIDs not be allowed to refer to concepts i.e. not for identifying things or describing things, TaxonConcept GUIDs should be used here. But if this was to happen what would a name usage be - would it refer to TaxonName GUIDs or TaxonConcept GUIDs (possibly Nominal)or to neither? I guess it could be either of the first two but probably will be the last, until it becomes practice to refer to TaxonNames and TaxonConcepts using their GUIDs. I think we really need to support different groups sorting out the problem in different taxonomic groups. I guess in a way much like the Catalogue of Life has been doing. However I'd still see IPNI doing plants, Index Fungorum doing fungi and zoobank doing animal TaxonNames etc and then whomever is working in TaxonConcepts i.e. producing descriptions or definitions for things we really think are out there to publish TaxonConcepts with GUIDs from their perspective while referring to IPNI or zoobank TaxonNames. Slowly the TaxonConcepts will become more self referencing but in the meantime what we'll need is the aggregators to start relating all the TaxonConcepts which have been defined for resolution services. Currently I see the Catalogue of Life as a group producing concepts but which aren't maybe always well tied down to a clear definition or description but which could easily be addressed. So they give a view of the concepts in the world and could act as a good starting point for linking other concepts to. Jessie This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

1 0