I strongly suggest to add ISO style locale as an attribute of NameSimple which can cover not only common names but also Codes. See also Locales for common names -- JamesYtow

I don't have (the money to buy) the ISO standards... What are these locales - the 4-digit number locales, or the language+culture locales used in xml (= en-us/en-uk but also de-de or de-ch)? I would prefer language since this is well integrated into the xml tools already. -- Gregor Hagedorn, 12. August 2004

I meant the latter. API Documentation of Java provides good summary of locale with links to codes: see http://java.sun.com/j2se/1.4.2/docs/api/java/util/Locale.html . It is a combination of language, region and variant (optional), e.g. latin, worldwide, ICZN. -- James Ytow, 12 Aug. 2004 (UTC)

A locale covers language and country. So what does it give us in the context of a name? We don't need it to display the name correctly (UNICODE takes care of that). We can determine where this particular name is being used - but can we really? For historcial data the country borders are not as they are now so it is not meaningful. We can distinguish between names that are identical but mean different things in different countries/languages? Is this something that happens? Does historical (or even current) data have locale information or is it tagged on by somebody? Who has the authority to do so? At the moment I can't see any gain in having this obscure bit of info, but I am willing to be convinced of its uses. -- RobertKukla 12/8/04

The same name string can be used for different taxa depending on locale. It is not display issue but data issue. Even a name string for scientific name can be used for different taxon concept depending on region; e.g. taxon concept difference between Japan/Korea/Taiwan. The same scientific name spelling can be used validly to mean different taxon concepts under different Codes also. -- James Ytow 12 Aug. 2004 (UTC)

In my understanding a concept is a person's view (AccordingTo) or in the more relaxed sense (nomenclatural concept) everything that has been called by a specific name. In the first case your argument doesn't make sense to me, as I can't envision how someboday would publish a single article about two concepts with the same name that differ in locale? So I take it you want a way to capture a nomenclatural concept as something that has been called by a name in a specific country in a specific language? I am not a taxonomist and if people identify the need for it, I will put it in, but I find it hard to justify. --RobertKukla 16/08/04

The FishBase contains examples of single name string designating multiple concepts depending on locales. By extending locale to Codes, similar publication can exist which pointing out the situation itself. -- James Ytow 17 Aug. 2004

Which is why names are terrible identifiers for concepts. If 'Cod' means different things to different people it is a pretty poor identifier for a concept. If good quality, well-defined concepts are available for the species named Gadus morhua, G. macrocephalus, G. ogac etc. sec. whoever, poor concepts, with the names Cod (US), Cod (Australia), Cod (Canadian British Columbia) can be created, and a relationship(s) with the high quality concept expressed as part of the definition of the poor concept. i.e Concept 1 (with the name: Cod (US)) 'is vernacular of' Concepts x, y, z. This will be greatly facilitated if and when concepts are given GUIDs. TrevorPaterson 18 Aug.

It comes from your assumption that a name literal for a concpet can be an identifiler just like a proper naun can designate the target individual. A name (not a name literal; a name is a relationship between a name literal and its target object inlcuding concept) can work as circumscriber in the context where the name used. For this reason I do not expect too much to TaxonConcept's GUID; it requires someone who declare that these two entories should have the same GUID, but isn't it yet another taxon cocnept? It is fundamental difficulty of the TCS for me that the XML elemnt is called as TaxonConcept even though it looks like a NameUsage. It might be a forbidden quetion requiring a separete page... -- JamesYtow, 18 Aug. 2004

We are most definitely not proposing or supporting using names as identifiers. One concept with one name has one GUID - a new name is a new concept with a different GUID. This second concept might only contain a name and a relationship to the first one recording 'vernacular name of' TrevorPaterson 18 Aug

GUID is a kind of name as Dave Thau clearly stated in his talk at EdinburghMeeting. I have no doubt in that we can give GUID to each data entry, but not confident to taxon concept (see also notes of the meeting). GUID is, however, not part of TCS itself in my understanding so it is unncessary to discusss on GUID here. Is it right understanding? -- JamesYtow 18 Aug. 2004

Each 'data entry' IS a new concept in our model (and will be given a GUID) - it is not possible to modify or update or ammend concepts (because people will have already used the previous version) (of course minor database errors such as typos should be correctable) - if there is a new name - there is a new concept - concepts do not exist in some separate space divorced from names. - It is relevant/helpful to consider GUIDs because each unique concept will have a GUID, names will not have GUIDs - they are simply a component of a concept. This obviously differs from how you perceive Taxon concepts, and you see our version of Taxon Concept to be more akin to 'Name Usage' - but that is ok - TCS is just a common schema for representing and exchanging information, it does not control the semantics that individual users and providers put on the information. TrevorPaterson 19 Aug

The common schema requires someone to map the schema to their own schema to work, and hence we'd better to use less-misleading namings. As a fact, we have multiple names in multiple name scopes/spaces (or context, in term of Formal Concept Analysis ) designating to the same concept. If a name (or name literal, which do you mean?) is a component of a concept, then TaxonConcept should be able to have multiple Name element to handle this situation. I don't think it is good design, so I think the principal element shouldn't be TaxonConcpet but NameUsage (or Name, if it is agreed to distinguish name from name literal). -- JamesYtow, 19 Aug. 2004

The following really belongs to the element one level above NameSimple and NameDetailed, but I did not want to create a new topic: The attribute TaxonConcept/Name/@type has an enumeration scientific/non-scientific. I propose to replace type with an attribute scientificname of type xs:boolean to reduce the numbers of enumerations that have to be implemented. -- Gregor Hagedorn - 12. Aug. 2004

Good suggestion. Unless someone identifes the urgent need to have an additional type of name I will aggree. -- RobertKukla 12/8/04

Slight change of heart here. The type attribute is consistently used throughout the schema when there are different kinds of an element. I am not sure how much can be gained by sacrificing that. --RobertKukla 18/8/04

James Ytow has pointed out one implication of the current schema. Each concept can have one and only one name associated with it. I am in general very happy to treat each name as a different concept (even if many of them are then marked as being entirely congruent). However there is one special case which may require special handling. This is the situation in which the same name may validly be represented by different orthographic or script variants. I am here considering only vernacular names. In the case of Japanese the same name may be represented in the Kanji script (ideographic) or in either the Hiragana or Katakana scripts (syllabic). There is no mechanical transformation between Kanji and Hiragana/Katakana but all three will represent the same uttered name. Unicode provides no help here. These are simply different text strings which represent the same name. To avoid opening up various kinds of abuse that might arise if concepts can be assigned different NameSimple elements, would it be possible to include an extra element like AlternativeRepresentation with a cardinality of 0..n? This could cover situations like this or representations of non-Latin character-set names in Latin character sets. -- DonaldHobern 19/11/2004