[tcs-lc] Names as Objects

[Kennedy, Jessie]

Rich wrote:
>
>Just to be absolutely clear (one more time) -- I am not 
>advocating that we
>actually pull "name objects" out from TaxonConcepts and 
>establish them as a
>root element to themselves (although James may support this 
>approach).  I'm
>just asking the hypothetical question, "If this was done, how 
>would it break
>or otherwise adversely affect the main function of TCS?"  The 
>point was to
>see what the effects would be of unambiguously treating name objects as
>distinct from concept objects. Again, I am *NOT* proposing an 
>actual schema
>change of this sort.  I had earlier couched similar sentiments 
>with "yet" --
>but I have removed such qualifiers now, because I have 
>pretty-much decided
>that I would *never* actually propose or advocate such a 
>change myself.  Not
>so much for the reasons Jessie has been arguing, nor even 
>because of your
>concerns, Sally. But because I now believe that the "Nominal" 
>concept idea
>can be used to resolve a lot of the conflict between LC and TCS.
>
>
>Gregor wrote:
>
>> PS: biology in the form of nomenclature has a large number of
>> rules that a
>> computer scientists would call definitions of "canonical form" to
>> abstract from
>> the variation of name-strings-with-author to a name-identity. The
>> LC wiki has
>> worked out a number of these rules, and there may be more. I
>> therefore believe
>> that an ID should be given to these nomenclatural objects. Each
>> such object
>> could have multiple name strings, some of which are unique, some
>> shared with
>> other objects (homonyms). Circumscriptions concepts then could
>> refer to these.
>>
>> I believe that this is what Rich put up for discussion, which I
>> fully endorse.--
>
>Yes!  That captures the essence of (one of) the points I've 
>been trying to
>make -- that relationships among Code-regulated names 
>(indpendent of concept
>circumscriptions) are robust enough, and important enough, and 
>different
>enough from relationships among concept circumscriptions, that it is
>preferable to disentangle the representation of those 
>relationships within
>the standard schema.

Given that you don't want to pull out the names as top level objects - how can you separate out the relationships. We don't actually model the different types of concepts in the schema as there is so much optionality built in that you can represent any kind of concept with the schema. Therefore there is one TaxonConcept modelled for which there is a list of possible relationships - still to be tuned but currently includes nomenclatural and concept relationships.

>However, I think there is a solution that is glaringly obvious 
>to me, which
>is to equate "Nominal" concepts of TCS with Name objects.
>
would need to redefine Nominal concepts and think about how they would relate to Original and revised and how other biologists would use them.

>> To me most importantly, this solves my problem with SDD, that
>> people may want
>> to use SDD (and closely related, online monograph standards 
>like TaXMLit,
>> TaxonX) to CREATE taxon circumscription concepts, rather than
>> referring to them. They need, however, refer to a taxon name (and the
>nomenclatural
>> information about publication and status) choosen for the 
>new concept.
>
>Why can't they achieve this by creating a new concept 
>instance, and from
>within that instance refer back to a Nominal concept instance 
>to represent
>the name data?
>
Why can't they refer to a nominal concept as defined by TCS which is a scientific name AccordingTO NULL?

>> I fully see that all such activities could possibly become
>> embedded in TCS, but
>> I think this is not the correct level of modularity. I believe
>> even if you
>> think you should not neven link legacy data for which only the
>> name object can
>> be identified, but the circumscription concept remains 
>unknown to a name,
>> having the name as an object does not hurt. It lets the
>> scientific "market
>> forces" sort out which is the better solution.
>
>Again, I think the idea of a "Nominal" concept instance serves 
>this need
>extremely well (or at least it can -- depending on how it is ultimately
>defined).

I guess I think it can hurt - If we have names as objects and therefore have GUIDs for them, we can't create TaxonConcepts until we have sorted out the names as we would need the names to create a Concept so we would be discouraging anyone from marking up their data with concepts - even it they are of unknown meaning. 
If we let people mark up their data with names -  we need to have Name GUIDs and then Concept GUIDs and these will be different things that software and users will need to know about and will need to select and interpret accordingly. If we treat names as concepts we have one GUID space. As we create names we are creating concepts for people to use and things could progress more swiftly.

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.