[tcs-lc] Names as Objects

[Kennedy, Jessie]

>> The reason names have been treated as concepts is because they
>> become concepts because people are encouraged to use "correct"
>> names
>
>I think that what really happens is that they become "Nominal" 
>concepts as
>you folks have definied it (and, if I understand the 
>definition correctly,
>it is an extremely valuable way of linking name-only data to 
>concepts).
no - as you understand later -  they become original concepts (but all original concepts have an equivalent nominal concept According To NULL)
the name correction would still be according to someone surely.....
The nominal concept is there so that someone identifying something later, without saying what meaning they meant, can use the nominal version.

>  As
>for "correct" -- there are two kinds of corrections -- those 
>related to name
>objects, and those related to concept circumscriptions.  The former are
>about "name" corrections as governed by Codes, and the latter are about
>corrections in order to adhere to more modern concept definitions.
>

yes but they both result in a biologist having to use a name when they mean something i.e. a concept, so treating both as original concepts albeit one without a good definition.

>> so they inherit a meaning therefore we want them to be
>> concepts even if in the original publication of that name there
>> is no concept described as such there will be reference to the
>> original concept (in your terms the original name embedded in the
>> original concept) that this is a correction for.
>
>That's where we disagree, I think.  If I read you correctly, 
>you suggest
>that a name without an elaborated concept should default to 
>the "Original"
>concept.  I say it should default to the corresponding 
>"Nominal" concept.
>That's why I think the "Nominal" concept is such a powerful 
>tool -- it says
>"we don't know what concept was asserted, but we know that it 
>likely falls
>within the set of possible concepts for which this name has 
>been assigned".

yes that's why we introduced nominal concepts but your nominal concept does have an according to - to the person who made the name change in the publication that name change was proposed.

>That's exactly the sort of "concept" we want name-only data to 
>default to.
>
yes I agree that name only data used in identification should default to nominal concepts i.e. scientific name AccordingTo NULL rather than just scientific name.

but your nominal concepts would not be simple scientific names according to we don't whom they would have other information about them that the biologist using a name probably had no knowledge of or intention of referring to.
 
>> The Relationships within a Taxonomic concept have one target,
>> that pointed to from the current taxonomic concept being defined,
>> and it is implied that these relationships were by the person in
>> the AcccordingTo and in the Publication where the concept was
>> defined. The RelationshipAssertions allows us to relate 2
>> concepts both of which have to be specified by a different Author
>> in a different publication. (can also be used to make a statement
>> about 1 concept)
>
>Yes, but you agree that the schema *structure* of 
>RelationshipAssertions
>could be used for both purposes -- right?  I mean, the elements are all
>there -- right?  You could put the "AccordingTo" of the TaxonConcept
>instance in the "AccordingTo" of RelationshipAssertions, and 
>you could put a
>pointer to the defined TaxonConcept instance in the 
>"FromTaxonConcept" of
>RelationshipAssertions.  You could even distinguish 
>RelationshipAssertions
>that form part of the definition from RelationshipAssertions that are
>secondary interpretations by simply testing whether the
>/RelationshipAssertion/AccordingTo equaled the 
>/TaxonConcept/AccordingTo for
>the TaxonConcept instance indicated in
>/RelationshipAssertion/AccordingTo/FromTaxonConcept.  Doing it this way
>would allow you to dump the /TaxonConcept/Relationships 
>elements altogether.
>
yes, but if I wanted to know how a taxonomist had defined his taxon then I would need to find and package the relationships with the same AccordingTo up with the rest of the TaxonConcept. So I would be modelling TaxonConcept as if the relationships weren't part of the definition. We were told by taxonomists that that's how some of them define their taxa so it seemed fundamental to capturing the semantics of a TaxonConcept.

>My point is, there is structural "elegance" in separating the 
>"definition"
>relationships from the "interpreted" relationships -- which is 
>why I do NOT
>think you should combine them both under 
>RelationshipAssertions (i.e., leave
>them as they are now).

good

>>
>> only if that unique string of characters was published in a
>> taxonomic publication such as a monograph or as a result of a
>> name change to satisfy one of the codes and therefore to be
>> intended to be used by people in the future - not just any name
>> string - I thought I made that quite clear.....
>
>O.K., then let me ask this:  If someone defines a new concept 
>in a way that
>doesn't conform to the taxonomic publication/monograph/etc. as 
>you scope it
>in the quoted text above, and uses a name-string that is not 
>identical to
>the corresponding name (i.e., a misspelling), then where in 
>TCS is the "Name
>as spelled in this concept definition"? 
sorry about this but to be clear - do you mean someone creating a new concept in a publication and they published the name wrong (mis-spelled it) or do you mean someone entering someone else's concpet (already described in a publication) into a database and therefore mis-entering the data
these are two different problems to me.......

>
>> can't really see the benefits.....or difference from having a
>> name objects separated out ....
>
>These are some of the benefits I see:
>
>- Nomenclaturalists have an unambiguous way to package the information
>they're interested in (i.e., Nominal concepts)
the we can't use Nominal concepts for what we meant them to be in the first place - which was to allow biologist who use scientific names in labelling things without saying what meaning they meant. i.e. Aus bus AccordingTo NULL
because your nominal concepts would have an AccordingTo surely? - the name of the person who proposed the change - doesn't the Nomenclaturalists want to record/track that?
>- The same set of Name elements can be re-used and referenced 
>by more than
>one concept object, and hence, smaller data package size for datasets
>involving multiple concepts attached to the same name

could be ok as long as names are never changed - if we want to maintain a true record of concepts as defined or indeed any data referencing one of these names.
 
>- Structurally-enforced consistency of name-data elements
possibly - but need to think through 
>- Minimal impact to overall TCS schema (relative to more radical,
>hither-to-fore hypothetical, alternative approaches).
I agree it's more in-line with TCS thinking except for the points I made about the difference between original and nominal concepts. 
>
>As I tried to explain in earlier email, I think there are 
>unambiguous cases
>of relationships that involve two names (e.g., "Is basionym 
>of", "Is type
>species of", etc.), which are distinct from relationships that 
>involve two
>concepts (e.g., "Includes", "Is Congruent", etc.)  And I think it is a
>mistake to blend these two kinds of relationships together in 
>the same data
>structure.

I'm not sure you could enumerate these relationships for the different types of concept in XML - but I think some of this might be application rules. 

Anyway it would be easy to interpret them as such. If I have two concepts with a name-based relationship between them I clearly know it's talking about the name parts of the 2 concepts.

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.