[tcs-lc] You don't need embedded names to do concepts

[Roger Hyam]

Kennedy, Jessie wrote:

>Hi Roger
>
>You didn't really think you'd get a simple agree or disagree on that question did you ;-)
>  
>
Well maybe not from you and I suspect Rich will have more than a single 
word reply.

>>The question is whether we embed names in TaxonConcepts or whether we 
>>have separate top level element called 'Nomenclature' or similar which 
>>contains name objects and just have a pointer to them from 
>>TaxonConcepts. Briefly this is "NamesAsObjects" vs 
>>"NamesEmbedded" debate.
>>    
>>
>
>is this "Nomenclature object" all the details of names including the publication, author, relationships to other names etc?
>
>  
>
Yes or pointers to those publications, specimens etc.

>>Imagine I want to pass a TaxonConcept from my system to your system. I 
>>have the circumscription here in my field guide. I have been using it 
>>during my survey of Wonderland.
>>    
>>
>
>ok so you've been using the concepts to identify things in Wonderland - just like our Ecologist friends in SEEK....
>  
>
>>Under the current TCS NamesEmbedded model I either:
>>
>>a) Pass the complete name details, i.e. the canonical name the 
>>unstructured name the canonical author string, the micro ref, the 
>>pointer to the reference etc. embedded in the TaxonConcept.
>>
>>OR
>>
>>b) I pass a pointer to the 'Original' TaxonConcept the name 
>>was used by 
>>(I can't point to the name itself). You can then retrieve the Original 
>>TaxonConcept and ignore any circumscription details that come 
>>with that 
>>object because they are irrelevant.
>>    
>>
>
>but why did you miss the point where I said we would anticipate that people would not only pass the pointer i.e. the GUID of the original concept but to help with human readability as Sally also mentioned - we would pass the equivalent of the fields that act as the primary key - i.e. (at most simplest) the name simple plus the AccordingTo simple these should uniquely identify a concept but in a human readable form while the GUID (if one existed) could be used to inspect your concept in more details if someone wanted to. If the GUID didn't exist then you could register your concept and get a GUID which would then make it available for others to use if they were using concepts from the same field guide as you had.
>
>So to me this allows you to pass the name info that you want, and for anyone wanting more info be it nomenclatural or concept they could inspect the GUID and request that subset of the schema they were interested in.
>
>  
>
>>Clearly I don't want to pass the full name details every time I pass a 
>>concept but I would like to give  you the ability to expand on the 
>>details I do send so it is most sensible to do b.
>>    
>>
>yes but by including a human readable key with the GUID (or pointer) you get what you need.
>
>  
>
Yes provided you know what I want in my human readable form. Do I want 
the date? Do I want authors in full or an abbreviation? If I am going to 
use this to attempt some reasoning about Names with another system 
(perhaps some literature I have scanned) then I may need more than just 
a useful bit of linking text but we can't specify ahead of times what 
that is.

There really is no reason why you can't pass me any string you like and 
I just treat it as a human readable form of a GUID. I have set up 
another subversive thread on this called 'Lets not bother with the codes'.

>>Making you retrieve the Original concept circumscription 
>>(which neither 
>>of us may be interested in at all) and then discard it is a little 
>>contrived to put it mildly. So what I would do as an implementer is 
>>provide a SOAP or digger call, getScientificName(), that just returns 
>>the name 
>>

>> of the original concept. I'll put together an XML Schema 
>>to express this and hey presto we have a Name as an object - which is 
>>what we are trying to avoid with having names embedded.
>>    
>>
>
>yes that's fine but the GUID should go along with the name to prevent loss less joins later. Passing the GUID with the name is hardly expensive but removes any ambiguities.
>
>  
>
But the GUID is to a concept isn't. No GUIDs to names. So I can use that 
GUID to  retrieve a TaxonConcept with the text of the publication 
perhaps and other stuff embedded in it - including a name.

>>Exactly the same process occurs for retrieving basionym data.
>>
>>Since this straw broke my camel's back some other straws have 
>>come to my 
>>notice such as where you link to type specimens that aren't 
>>part of you 
>>taxon circumscription - but I won't go into them just now.
>>    
>>
>
>can't see this as a problem either - but if you want to expand on it feel free.....
>
>  
>
>>I think what I am saying is that it is very useful 
>>
Not just in this thread - tis big enough.

>>to pass 
>>names around 
>>as objects and people will do it whether we want them to or not.
>>    
>>
>
>yes they will but if you give them the correct information and they choose to ignore it that's one thing if you don't give them the correct information then I think that's your (our) responsibility.
>
>  
>
>>Within our community there is general support for the notion of 
>>TaxonConcepts and agreement that it would be a good thing if 
>>people used 
>>them more but there is much division and lots of discussion on how we 
>>handle names if we _force_ the use of _only_ TaxonConcepts. 
>>The level of 
>>discussion on this nearly equals the level of spam I get!
>>    
>>
>
>how are we expected to come to any agreement without discussing the issues - I guess we could just sit back and take whatever is implemented....but then there may be several implementations to choose from - which one should I use - oh maybe I'll just do my own....sounds familiar - think we're there just now ;-)
>  
>
My point was that if the debate does not appear to move on then we 
should perhaps reverse up and try another route.

>>The goal of a transfer format is to be as inclusive as possible:
>>    
>>
>
>yes
>  
>
>>* Having names as objects does not prevent people from passing 
>>TaxonConcepts 
>>    
>>
>
>agree
>  
>
>>and so is the most inclusive.
>>    
>>
>big leap there......
>
>  
>
>>* Having names embedded does make passing name data very awkward or 
>>involves creating notions of 'special' concepts of various kinds to 
>>cover up the fact that we are really just trying to pass nomenclatural 
>>data. It is likely to exclude some people who can't see the merit of 
>>doing it this way or cause them to supplement the schema in some way 
>>which may lead to incompatibilities.
>>    
>>
>
>but having names as concepts does allow passing of name information - I didn't see the list of disadvantages given above for creating and using concepts if names are objects.....
>

> Like the fact that people will have to create names, 
>
If by create you mean create a node in an xml tree and populate it then 
they have to do that no matter what.

>give them GUIDs before we create concepts that we need GUIDs for - 2 GUID spaces to deal with,
>
This is only a disadvantage from the point of view of a concept only 
world. People who want to refer to Names want two GUIDs. It is an 
advantage from their perspective. From the point of view of comparing 
the two systems it is therefore neutral at most.

> users and software need to choose which type of GUID they should use. 
>
Yes they do but then under a concept only approach they need to know 
whether they should be referring to a nominal concept (by whoever's 
definition of it) an original concept or a revision concept. At least 
two of these will exist for every Name. Should they be able to tell what 
type of concept they are referring to by the GUID? If so then they we 
have 3 GUID spaces. If not then we need to have a simple system for 
people to be able to make sure they are using a the GUID for Aub bus 
nominal and not accidentally using it for another kind of Aus bus 
concept. Under a names system there are only two GUIDs and it is totally 
explicitly what is being referred to. In summary

    *  NamesEmbedded system choice is between point to Original or
      Nominal or Other concepts. Number options >= 2.
    * NamesAsObjects system choice is between Name GUID or Concept GUID
      (0 or more). Number of options >= 1.

>If we agree people sould use concepts even if they are (in my terms) nominal concepts we need to create the equivalent nominal concepts for every name and the original concepts for every name as well as the revised ones.
>
There may be merit in creating nominal concepts for names then forcing 
people to always refer to a concept(though many would argue we shouldn't 
bother as it is only a pointer to the name object anyway - when nominal 
is implied sensu Rich) . Original TaxonConcepts in the sense of the 
Napier TCS can be created as needed by the taxonomic community. If a 
taxon has been revised then no one other that a monographer has any 
interest in the circumscription of the original taxon - just so long as 
the name was valid and can be used for the modern circumscription.  
Original concept circumscriptions are of no more importance than any 
other circumscription - possibly generally of less importance - other 
than the fact that they create the name and attach it to a type. I can 
think of no scientific reason for going back and filling in all the 
original circumscriptions of taxa  that have subsequently been 
monographed (how many million). I am sure there are people who would 
like to do it though :-) .

> So I think it will put people off ever getting around to concepts for a long.... while....
>
>  
>
Here you have a point and it is the one thing that worries me and I 
would like ideas as to how we encourage people to use concepts but not 
mandate them to do it. I think that is the challenge.

At which point I will stop.

>>Currently I don't think we have a choice but to model 
>>NamesAsObjects. As 
>>always I remain open to be persuasion.
>>    
>>
>
>hope I've done a bit of persuading - but let's see where others fall on this...
>
>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. 
>_______________________________________________
>tcs-lc mailing list
>tcs-lc at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/tcs-lc
>
>  
>

-- 

==============================================
 Roger Hyam
----------------------------------------------
 Biodiversity Informatics
 Independent Web Development 
----------------------------------------------
 http://www.hyam.net  roger at hyam.net
----------------------------------------------
 2 Janefield Rise, Lauder, TD2 6SP, UK.
 T: +44 (0)1578 722782 M: +44 (0)7890 341847
==============================================


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050310/3f13ba9e/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roger.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050310/3f13ba9e/roger.vcf