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

[Kennedy, Jessie]

Hi Roger

You didn't really think you'd get a simple agree or disagree on that question did you ;-)

>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?

>
>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.

>
>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 part 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.

>
>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 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 ;-)
>
>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, give them GUIDs before we create concepts that we need GUIDs for - 2 GUID spaces to deal with, users and software need to choose which type of GUID they should use. If we agree people should 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. So I think it will put people off ever getting around to concepts for a long.... while....

>
>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.