head 1.16; access; symbols; locks; strict; comment @# @; 1.16 date 2007.03.06.17.30.00; author TWikiGuest; state Exp; branches; next 1.15; 1.15 date 2004.11.04.10.41.15; author GregorHagedorn; state Exp; branches; next 1.14; 1.14 date 2004.11.04.08.05.06; author RichardPyle; state Exp; branches; next 1.13; 1.13 date 2004.11.02.12.45.00; author GregorHagedorn; state Exp; branches; next 1.12; 1.12 date 2004.11.02.06.40.00; author RichardPyle; state Exp; branches; next 1.11; 1.11 date 2004.11.01.14.57.27; author NozomiJamesYtow; state Exp; branches; next 1.10; 1.10 date 2004.11.01.09.50.00; author GregorHagedorn; state Exp; branches; next 1.9; 1.9 date 2004.10.31.21.42.13; author NozomiJamesYtow; state Exp; branches; next 1.8; 1.8 date 2004.10.31.20.25.00; author RichardPyle; state Exp; branches; next 1.7; 1.7 date 2004.10.31.18.35.55; author RichardPyle; state Exp; branches; next 1.6; 1.6 date 2004.10.31.09.19.00; author GregorHagedorn; state Exp; branches; next 1.5; 1.5 date 2004.10.31.05.55.00; author RichardPyle; state Exp; branches; next 1.4; 1.4 date 2004.10.31.03.45.25; author NozomiJamesYtow; state Exp; branches; next 1.3; 1.3 date 2004.10.31.02.07.00; author RichardPyle; state Exp; branches; next 1.2; 1.2 date 2004.10.31.01.22.00; author NozomiJamesYtow; state Exp; branches; next 1.1; 1.1 date 2004.10.30.22.55.00; author NozomiJamesYtow; state Exp; branches; next ; desc @none @ 1.16 log @Added topic name via script @ text @---+!! %TOPIC% %META:TOPICINFO{author="GregorHagedorn" date="1099564874" format="1.0" version="1.15"}% %META:TOPICPARENT{name="LinneanCoreDefinitions"}% Discussion on [[LinneanCoreDefinitions#NameStringDefinition][Name-string]] Note Gregor: I summarized the first part of the discussion to refocus; please go back on the wiki to version 1.14 to see the full original discussion: * James and Rich discuss whether to distinguish between printed on paper (glyph) and its digital representation in a character coding scheme. The resolution was to limit string to character coding schemes (due to xml from the unicode family) and introduce [[LinneanCoreDefinitions#NameLiteralDefinition][Name-literal]] as an abstraction layer between Unicode string and name in general (including digital/electronic representations like a name on a JPEG of a label). * Some discussion about the use of "context" in the definition; the phrase in the definition is now replaced with "name within the scope of LinneanCore's domain". Rich: "Perhaps we need a different definition for "Code-compliant name-string" to accomodate the machine-generated "corrected" (= canonicalized, Gregor) strings? The Machine-generated instance might be considered as a [[LinneanCoreDefinitions#NameUsageDefinition][Name-usage]], and therefore its corrected nomenclatural representation could be considered as a *Name-string*. * Rich and Gregor discussed name comparability and identity, from which a discussion resulted whether Name-string should be limited to scientific-name-without-authors, or should be a super term for all kind of scientific names, with or without author. There seems to be a feeling that many botanists in a name usage context consider the "natural" name to include authors, even though the ICBN defines the name object as without authors. Gregor proposed to have name-string, and introduce two new definitions: * Nomenclatural-disambiguation: part of a name-string that disambiguates nomenclatural homonyms. This may include authors, publication year, or reference title. * Conceptual-disambiguation: part of a name-string that disambiguates concept usage. This may include fuzzy concept suffixes like "s. str.", "sensu lat.", "non author", and exact like "sensu/secundum publication reference". End of summary --- Richard: For clarity, please complete the following table (using a zoological name, with botanical authorship conventions to transcend Code issues):
# String    Terms: Richard Gregor James LC Discussions
1 Pseudanthias ventralis
subsp. hawaiiensis (Randall) Hoover sensu Pyle 2003		 Concept-string Linnean Name-string
(with nomenclatural and concept disambiguation)		 human readable representation of a name usage from unknown source because w/o auct. or sec. -
2 Pseudanthias ventralis
subsp. hawaiiensis s. latissimo		 Concept string
(ambiguous "AccordingTo")		 Linnean Name-string
(with (fuzzy) concept disambiguation)		 human readable representation of a name usage from unknown source because w/o auct. or sec. -
3 Pseudanthias ventralis
subsp. hawaiiensis (Randall) Hoover 		Name-string with authorship Linnean Name-string
(with nomenclatural disambiguation)		 Linnean name literal -
4 Pseudanthias
ventralis (1999)		 Name-string with year Linnean Name-string
(with nomenclatural disambiguation)		 human readable representation of a name usage from unknown source because w/o auct. or sec. -
5 Pseudanthias ventralis
subsp. hawaiiensis		 Name-string Linnean Name-string
(without authors/disambiguation)		 Linnean name literal -
6 Pseudanthias Name-unit (genus) Name part:
Genus name		 name token (genus) -
7 ventralis Name-unit (species) Name part:
species epithet		 name token (specific epithet) -
8 hawaiiensis Name-unit (subspecies) Name part:
infraspecific epithet		 name token (infraspecific epithet) -
9 sensu Pyle 2003 Concept Authorship Name part:
concept suffix (or concept disambiguation)		 human readable representation of pointer to another name usage -
10 Pyle 2003 Citation Citation citation summary -
11 (Randall) Hoover [Name] Authorship Name part: nomenclatural authorship authorship summary -
12 Randall Agent Surname Canonical1 Author Name
role under ICBN: basionym author		 surname -
13 Hoover Agent Surname Canonical1 Author Name
role under ICBN: combining author		 surname -
14 Pyle Agent Surname Canonical1 Author Name
role: concept citation		 surname -
14 s. lato - concept suffix (ambiguous) - -
Footnotes: 1: Canonical Author name = this may be an abbreviation like "L.", an standardized inherited name ("family name, surname, father's name, depending on culture), or "given + inherited name". -- Gregor Richard: Thanks to Gregor & James for adding their terms. If others wish to contribute, please insert your own column. I've re-named the last column "LC Discussions", with the intention of populating this column with selected terms that we can all agree to use in future discussions. I think we will have reason to discuss several of the items in the table above at one point or another, so it would be good if we could agree on a short (1-3 words) term for each of the most important items in the "String Term" column. At this point, I honestly don't care what the terms are -- but it would be helpful I think if we could come up with clear terms for each, so we don't need to embed too many qualifications to terms in the course of our discussions. -- 2 Nov 2004 %META:TOPICMOVED{by="GregorHagedorn" date="1099215570" from="UBIF.NameString" to="UBIF.LCNameStringDiscussion"}% @ 1.15 log @none @ text @d1 2 @ 1.14 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RichardPyle" date="1099555506" format="1.0" version="1.14"}% d5 10 a14 28 * JMS: It would be better to use "Linnean name-string" for LinneanCore specific *Name-string*. Do we need to restrict to ASCII/Unicode? Do you have distinguish what printed on paper (glyph) and its electronic representation? What do you mean by "context" here? Nomenclatural correction can be made without correcting publication. Do you include such machine-generated one as a [[LinneanCoreDefinitions#NameUsageDefinition][NameUsage]]? -- 30 Oct 2004 * Richard Pyle: My intention was for these definitions to exist only within the context of LinneanCore discussions, so "Linnean Name-string" seems redundant. But if you want these definitions to have broader scope, then I suppose you could qualify it that way....but how would the definition of a "Vernacular Name-string" (or other qualified *Name-string*) differ from this definition? * JMS: I'd like to keep broder if possible, because we would need to say "such such is out of scope of LinneanCore; should be treated separetely (parhaps by TCS)" etc. We'd better separate definition part, and LinneanCore specific part, e.g. " ...printed on paper or represented in an electronic document to designate a named object. It is a scientific name within the scope of LinneanCore's domain." -- Oct 30 2004 * (RP, cont.) I guess there is no need to specify "printed on paper or represented in an electronic document" -- I only added that bit to emphasize that the *Name-string* exists only in the context of a [[LinneanCoreDefinitions#NameUsageDefinition][Name-usage]]. I mentioned "ASCII/Unicode" because I wanted to emphasize that the *Name-string* is the electronic representation of the *Name-string* (I've modified the definition to reflect this). Are there other ways to electronically represent text strings besides ASCII/Unicode? The reason for the restriction to electronic representation is that I assumed that LC data would always be represented electronically (at least at some point in its life). The transliteration of printed scientific names into Unicode *Name-strings* is not perfect (even more problematic with ASCII), so the LC *Name-string* is specifically intended to mean the electronic version. * JMS: Again I prefer to broader defintion with restriction to LinneanCore. TDWG-ish XML schema treates texts as UTF-8 generally, but it does not exclude to have *Name-strings* on specimen label in a JPEG file. How about " A literal string of text characters printed on paper or represented in an electronic document to desiganate a named-object. It is a scientific name represented in UTF-8 within the scope of LinneanCore's domain." -- Oct 30 2004 * Richard Pyle: I'm inclined to agree with all of your points, and change the definition accordingly. However, I just want to establish clarity on one point. In my mind, the word "string" in this context refers *specifically* to a sequence of electronically-rendered (ASCII/Unicode) characters. I do not think of a JPEG or bitmap rendering of a series of printed characters as a "string" composed of characters -- I think of these as images composed of pixels. Thus, to me the "string* implies a standard computer-text (ASCII/Unicode) sequence of characters. I think of the *Name-string* specifically as a schema element in LC (or TCS) that can be searched using text-comparison computer filter procedures. So to me, the *Name-string* is not really a "name object", but an ASCII/Unicode (or UTF-8, if you prefer) representation of a name object. In the case of electronic [[LinneanCoreDefinitions#ReferenceDefinition][Reference]], they are the same. In the case of paper-printed [[LinneanCoreDefinitions#ReferenceDefinition][Reference]], there is an implied transliteration. *HOWEVER*, I am willing to change my views on this and define a *Name-string* as a name object (as you suggest), and qualify that within the context of LC it implies a UTF-8 character string -- if you (or others) feel strongly about this. -- 30 Oct 2004 * JMS: I introduced [[LinneanCoreDefinitions#NameLiteralDefinition][Name-literal]] as an abstraction layer between UTF-8 string and name in general. It also covers variants. -- 31 Oct 2004 * (RP, cont.) By "context", I was specifically trying to distinguish the *Name-string* as the literal text string represented in a taxonomic [[LinneanCoreDefinitions#ReferenceDefinition][Reference]], and *not* some sort of "corrected" nomenclatural representation that exists only within LC. Perhaps we need a different definition for "Code-compliant name-string" to accomodate the machine-generated "corrected" strings? The Machine-generated instance might be considered as a [[LinneanCoreDefinitions#NameUsageDefinition][Name-usage]], and therefore its corrected nomenclatural representation could be considered as a *Name-string*. But the point is, it would be considered a *Name-string* only in the context of the machine-generated [[LinneanCoreDefinitions#NameUsageDefinition][Name-usage]]; not in the context of the [[LinneanCoreDefinitions#NameUsage][Name-usage]] of the source [[LinneanCoreDefinitions#ReferenceDefinition][Reference]] Upon which the Machine name instance is based. -- 30 Oct 2004 * Gregor: What do you mean by " *Name-string* exists only in the context of a [[LinneanCoreDefinitions#NameUsageDefinition][Name-usage]]"? What does exist mean? * Richard: I meant that concatenations of [[LinneanCoreDefinitions#NameUnitsDefinition][Name-units]] outside the context of a traditional "usage" (e. g., concatenations created by LC logic or some sort of portal logic or algorithm) should not be thought of as *Name-strings* in the sense that I had intended that term to be used. I also meant that the *Name-string* has a tangible representation (rather than a conceptual entity, like James' "name object"). However, I see now that the distinction can be fuzzy -- so perhaps the definitions should not make reference to "exists" -- I'm happy to strip all of those sentences out of the definitions, because they probably cause more confusion than clarity. -- 30 Oct 2004 * (Gregor, cont.) The primary issue with names for me is their comparability. I want to know who else said something about the pathogen I believe I have. Thus I need to define equality rules for name-strings across name usage. In some respect this is what you do when you enter a name in Google etc. What is that string of unicode characters entered in Google that represents a scientific organism name? This is to me the essential item I would call a name string. No problem having another term for it - but give one. Name-string to me seems the obvious choice, rather than constraining name-string to string in name-usage context. -- 30. Oct. 2004 * Richard: I'm not sure I understand how we differ on this. If you want to know something about a pathogen using that pathogen's name, then you are searching for *usages* of that name as applied to the pathogen (now we're drifting into TCS realm). All I really wanted to pin down was a term that applies to a string of Unicode characters that has been used as a name within the LC domain. I wanted this to be at the "usage" resolution (i.e., include all variants, etc.). I wanted this to be separate from a Name string embellished with authorship information. -- 30 Oct 2004 * Gregor: 1. I agree that I search for usages of the string, but to do that I use something that has to exist and be comparable across usages, which I think is why the name string exists outside of usages. Perhaps, given your above comment, it may be better to state: "A name-string is an identifier only for itself. Concepts can be derived only within a name usage context." James should look at this as well, but to me this would be clearer. * Richard: Can you elaborate on what you mean by "something that has to exist and be comparable across usages"? That might help me understand what you are getting at here. Note that in the definitions, I eliminated the reference to "exists in the context of a usage". -- 31 Oct 2004 * Gregor: 2. Again, I think authorship has nothing to do with it. I think it would be smart in the case of known homonyms, to add author name in Google! * Richard: Authorship of what? Protonym? Name-string? Usage? We certainly agree that what I think of as "Name-string with authorship" is an important element of the schema (e.g., for Google searches). -- 31 Oct 2004 * Gregor: 3, PS: you use the term "name" :-) * Richard: My bad! Sorry!!! -- 31 Oct 2004 * Gregor: I am rather confused why you limit Name-String to NOT include authors. In my practice I have no use for this term. A *Name-string* without authors is an ambiguous, incomplete namestring. If I want to make conclusions based on name strings in printed or digital publications, I can use name-string with authors, or have to guess about the authors from geographical or historical context. To me the the Name-string-without-authors seems to be the special case. Is this botany against zoology? Or just Gregor :-) ? -- 30. Oct. 2004 * Richard: Just to be clear, we are not defining LC entities here, we are defining *terms* to use in our discussion. We need a *term* to refer to a *Name-string* without authorship information, separate from a *term* to refer to a *Name-string* that is fully qualified with authorship information. The importance of establishing unambiguous terms for these things, is that when we start arguing about how to populate LC elements such as "VerbatimName" (or whatever that element ends up being called), we don't have to deal with semantic ambiguity as an additional impediment to communication. Now, in my mind, the "default" (normal) encapsulation of a *Name-string* excludes authorship information. Maybe this is a Zoological bias, but I see it more logically as " *Name-string* vs. [[LinneanCoreDefinitions#NameStringWithAuthorshipDefinition][Name-string with authorship]]"; rather than " *Name-string* vs. Name-string sans authorship" -- 30 Oct 2004 * Gregor: I did not misunderstand the aim of definitions. I just want to make clear, that while for you the "normal thing" is a name without authors, to me and I believe most botanists the "normal thing" is a name-string with author. How do you deal with the in some groups hugely frequently homonyms? I believe in some fungal genera a quarter of names have homonyms! So I think the definition is odd, but I see that this seems to be zoology against botany. * Richard: I don't think the issue is one of Botany vs. Zoology (Zoology probably has as many homonyms as Botany). The issue to me is more of semantics. If we break up the text string, "Pseudanthias ventralis hawaiiensis (Randall) Hoover" into individual units delimited by spaces, three of those units unambiguously apply to a scientific name as applied to a class of organisms; and two of those units unambiguously apply to proper names of individual Agent instances. The word "Name" has many interpretations within the LC context, but as far as I know, all of them at least imply classes of organisms. Within an AgentCore ("EveCore"?) context, "Name" might imply instances of Agents. So, it seems semantically proper to me that a "Name-string" should consist of a string of "Names" in the LC context, and that Authorship units would represent a different sort of information (a mark-up, if you will). Hence, I approach it as basic element ("Name-string"), and embellished/annotated/qualified/enriched element (Name-string with authorship). * Gregor (cont.): Therefore more relevantly and perhaps the solution: I see no need to define these separately! Can you check whether any of your usages of name-string is relevant as to whether you mean with/without nomenclatural author? Since I always read your name-string usuage as with author and it makes sense to me, perhaps there is not. My proposal is therefore to define Name-string as string with or without author. Simple the string used in the name-usage context. Then clarify that subclasses of namestring exist. I believe there is more than author/non-author. * Richard: So if I understand you correctly, you view "Name-string" as a superclass of all character strings that can be/have been used to refer to a taxon (sometimes with embedded authorship units; sometimes without), and then define more qualified terms to specifically indicate whether a string of characters containing scientific Name-units either does, or does not, include Authorship information? -- 31 Oct 2004 * Gregor (cont.): I propose to define: * Nomenclatural-disambiguation: part of a name-string that disambiguates nomenclatural homonyms. This may include authors, publication year, or reference title. * Conceptual-disambiguation: part of a name-string that disambiguates concept usage. This may include fuzzy concept suffixes like "s. str.", "sensu lat.", "non author", and exact like "sensu/secundum publication reference". -- 30 Oct 2004 * Richard: For clarity, please complete the following table: d27 1 a27 1 subsp. hawaiiensis Randall (Hoover) sensu Pyle 2003 d48 1 a48 1 subsp. hawaiiensis Randall (Hoover) d131 2 a132 2 (canonical) Agent Name
(= abbrev., inherited name,
given + inherited name) d140 2 a141 2 (canonical) Agent Name
role: concept citation d149 1 a149 1 (canonical) Agent Name
d154 8 a162 3 -- 31 Oct 2004 Richard: Thanks to Gregor & James for adding their terms. If others wish to contribute, please insert your own column. I've re-named the last column "LC Discussions", with the intention of populating this column with selected terms that we can all agree to use in future discussions. I think we will have reason to discuss several of the items in the table above at one point or another, so it would be good if we could agree on a short (1-3 words) term for each of the most important items in the "String Term" column. At this point, I honestly don't care what the terms are -- but it would be helpful I think if we could come up with clear terms for each, so we don't need to embed too many qualifications to terms in the course of our discussions. -- 2 Nov 2004 d164 1 a164 1 Gregor: side question: I assume by listing Randall and Hoover separately, you also implicitly wanted to ask for role names of these agents. However, I am not clear what "Randall (Hoover)" is in zoology. In botany it would not exist. In botany, "(Hoover) Randall", "(Hoover)" would be basionym author citation, and Randall combining author citation. -- 2 Nov 2004 d166 1 a166 1 Richard: Oops! My bad! I meant "(Randall) Hoover" in the botanical sense. I deliberately used botanical authorship style with a zoological Name-string to transcend Code issues. My original intent for listing Randall and Hoover separately was to see if anyone had different terms for the different authorships. -- 04 Nov 2004 @ 1.13 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1099399500" format="1.0" version="1.13"}% d139 1 a139 1 Randall (Hoover) d178 3 @ 1.12 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RichardPyle" date="1099377600" format="1.0" version="1.12"}% d141 1 a141 1 Name part: Authorship d149 2 a150 1 Agent Name d158 2 a159 1 Agent Name d167 2 a168 1 Agent Name d177 1 @ 1.11 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="NozomiJamesYtow" date="1099321047" format="1.0" version="1.11"}% d35 1 d40 1 a40 1 [Others please add columns] d43 1 d53 1 d56 2 a57 1 - d64 1 d74 1 d77 1 a77 1 - d84 1 d94 1 d96 1 a96 1 Name-unit d103 1 d105 1 a105 1 Name-unit d112 1 d114 1 a114 1 Name-unit d121 1 d130 1 d138 1 d146 1 d148 1 a148 1 Agent Name d154 1 d156 1 a156 1 Agent Name d162 1 d164 1 a164 1 Agent Name d172 2 @ 1.10 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1099302600" format="1.0" version="1.10"}% d47 1 a47 1 human readable representation of a name usage d56 1 a56 1 - d74 1 a74 1 - d91 1 a91 1 name token d99 1 a99 1 name token d107 1 a107 1 name token @ 1.9 log @none @ text @d1 2 a2 2 %META:TOPICINFO{author="NozomiJamesYtow" date="1099258933" format="1.0" version="1.9"}% %META:TOPICPARENT{name="LinneanCoreDefinitionsDiscussion"}% d34 5 a38 5 String Richard Term Gregor Term James Term d41 35 a75 13 Pseudanthias ventralis subsp. hawaiiensis Randall (Hoover) sensu Pyle 2003 Concept-string - human readable representation of a name usage - Pseudanthias ventralis subsp. hawaiiensis Randall (Hoover) Name-string with authorship - Linnean name literal - d77 3 a79 2 Pseudanthias ventralis subsp. hawaiiensis d81 2 a82 1 - d86 1 a86 1 d89 2 a90 1 - d94 1 a94 1 d97 2 a98 1 - d102 1 a102 1 d105 2 a106 1 - d110 1 a110 1 d113 2 a114 1 - d118 1 a118 1 d121 1 a121 1 - d125 1 a125 1 d128 1 a128 1 - d132 1 a132 1 d135 1 a135 1 - d139 1 a139 1 d142 1 a142 1 - d146 1 a146 1 d149 1 a149 1 - @ 1.8 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RichardPyle" date="1099254300" format="1.0" version="1.8"}% d45 1 a45 1 - d52 1 a52 1 - d59 1 a59 1 - d66 1 a66 1 - d73 1 a73 1 - d80 1 a80 1 - d87 1 a87 1 - d94 1 a94 1 - d101 1 a101 1 - d108 1 a108 1 - d115 1 a115 1 - d122 1 a122 1 - @ 1.7 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RichardPyle" date="1099247755" format="1.0" version="1.7"}% d26 4 a29 2 * Richard: I don't think the issue is one of Botany vs. Zoology (more to follow...) * Gregor (cont): Therefore more relevantly and perhaps the solution: I see no need to define these separately! Can you check whether any of your usages of name-string is relevant as to whether you mean with/without nomenclatural author? Since I always read your name-string usuage as with author and it makes sense to me, perhaps there is not. My proposal is therefore to define Name-string as string with or without author. Simple the string used in the name-usage context. Then clarify that subclasses of namestring exist. I believe there is more than author/non-author. I propose to define: d32 95 @ 1.6 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1099214340" format="1.0" version="1.6"}% d17 6 a22 1 * Gregor: 1. I agree that I search for usages of the string, but to do that I use something that has to exist and be comparable across usages, which I think is why the name string exists outside of usages. Perhaps, given your above comment, it may be better to state: "A name-string is an identifier only for itself. Concepts can be derived only within a name usage context." James should look at this as well, but to me this would be clearer. 2. Again, I think authorship has nothing to do with it. I think it would be smart in the case of known homonyms, to add author name in Google! 3, PS: you use the term "name" :-) d25 3 a27 1 * Gregor: I did not misunderstand the aim of definitions. I just want to make clear, that while for you the "normal thing" is a name without authors, to me and I believe most botanists the "normal thing" is a name-string with author. How do you deal with the in some groups hugely frequently homonyms? I believe in some fungal genera a quarter of names have homonyms! So I think the definition is odd, but I see that this seems to be zoology against botany. Therefore more relevantly and perhaps the solution: I see no need to define these separately! Can you check whether any of your usages of name-string is relevant as to whether you mean with/without nomenclatural author? Since I always read your name-string usuage as with author and it makes sense to me, perhaps there is not. My proposal is therefore to define Name-string as string with or without author. Simple the string used in the name-usage context. Then clarify that subclasses of namestring exist. I believe there is more than author/non-author. I propose to define: d29 2 a30 2 * Conceptual-disambiguation: part of a name-string that disambiguates concept usage. This may include fuzzy concept suffixes like "s. str.", "sensu lat.", "non author", and exact like "sensu/secundum publication reference". -- 30 Oct 2004 @ 1.5 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RichardPyle" date="1099202100" format="1.0" version="1.5"}% d3 1 a3 1 Discussion on [[LinneanCoreDefinitions#NameString][Name-string]] d5 1 a5 1 * JMS: It would be better to use "Linnean name-string" for LinneanCore specific *Name-string*. Do we need to restrict to ASCII/Unicode? Do you have distinguish what printed on paper (glyph) and its electronic representation? What do you mean by "context" here? Nomenclatural correction can be made without correcting publication. Do you include such machine-generated one as a [[LinneanCoreDefinitions#NameUsage][NameUsage]]? -- 30 Oct 2004 d8 1 a8 1 * (RP, cont.) I guess there is no need to specify "printed on paper or represented in an electronic document" -- I only added that bit to emphasize that the *Name-string* exists only in the context of a [[LinneanCoreDefinitions#NameUsage][Name-usage]]. I mentioned "ASCII/Unicode" because I wanted to emphasize that the *Name-string* is the electronic representation of the *Name-string* (I've modified the definition to reflect this). Are there other ways to electronically represent text strings besides ASCII/Unicode? The reason for the restriction to electronic representation is that I assumed that LC data would always be represented electronically (at least at some point in its life). The transliteration of printed scientific names into Unicode *Name-strings* is not perfect (even more problematic with ASCII), so the LC *Name-string* is specifically intended to mean the electronic version. d11 4 a14 4 * JMS: I introduced [[LinneanCoreDefinitions#NameLiteral][Name-literal]] as an abstraction layer between UTF-8 string and name in general. It also covers variants. -- 31 Oct 2004 * (RP, cont.) By "context", I was specifically trying to distinguish the *Name-string* as the literal text string represented in a taxonomic [[LinneanCoreDefinitions#ReferenceDefinition][Reference]], and *not* some sort of "corrected" nomenclatural representation that exists only within LC. Perhaps we need a different definition for "Code-compliant name-string" to accomodate the machine-generated "corrected" strings? The Machine-generated instance might be considered as a [[LinneanCoreDefinitions#NameUsage][Name-usage]], and therefore its corrected nomenclatural representation could be considered as a *Name-string*. But the point is, it would be considered a *Name-string* only in the context of the machine-generated [[LinneanCoreDefinitions#NameUsage][Name-usage]]; not in the context of the [[LinneanCoreDefinitions#NameUsage][Name-usage]] of the source [[LinneanCoreDefinitions#ReferenceDefinition][Reference]] Upon which the Machine name instance is based. -- 30 Oct 2004 * Gregor: What do you mean by " *Name-string* exists only in the context of a [[LinneanCoreDefinitions#NameUsage][Name-usage]]"? What does exist mean? * Richard: I meant that concatenations of [[LinneanCoreDefinitions#NameUnits][Name-units]] outside the context of a traditional "usage" (e.g., concatenations created by LC logic or some sort of portal logic or algorithm) should not be thought of as *Name-strings* in the sense that I had intended that term to be used. I also meant that the *Name-string* has a tangible representation (rather than a conceptual entity, like James' "name object"). However, I see now that the distinction can be fuzzy -- so perhaps the definitions should not make reference to "exists" -- I'm happy to strip all of those sentences out of the definitions, because they probably cause more confusion than clarity. -- 30 Oct 2004 d17 8 a24 2 * Gregor: I am rather confused why you limit Name-String to NOT include authors. In my practice I have no use for this term. A *Name-string* without authors is an ambiguous in incomplete namestring. If I want to make conclusions based on name strings in printed or digital publications, I can use name-string with authors, or have to guess about the authors from geographical or historical context. To me the the Name-string-without-authors seems to be the special case. Is this botany against zoology? Or just Gregor :-) ? -- 30. Oct. 2004 * Richard: Just to be clear, we are not defining LC entities here, we are defining *terms* to use in our discussion. We need a *term* to refer to a *Name-string* without authorship information, separate from a *term* to refer to a *Name-string* that is fully qualified with authorship information. The importance of establishing unambiguous terms for these things, is that when we start arguing about how to populate LC elements such as "VerbatimName" (or whatever that element ends up being called), we don't have to deal with semantic ambiguity as an additional impediment to communication. Now, in my mind, the "default" (normal) encapsulation of a *Name-string* excludes authorship information. Maybe this is a Zoological bias, but I see it more logically as " *Name-string* vs. [[LinneanCoreDefinitions#NameStringWithAuthorship][Name-string with authorship]]"; rather than " *Name-string* vs. Name-string sans authorship" -- 30 Oct 2004 @ 1.4 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="NozomiJamesYtow" date="1099194325" format="1.0" version="1.4"}% d4 3 a6 3 * JMS: It would be better to use *Linnean name-string* for LinneanCore specific name-string. Do we need to restrict to ASCII/Unicode? Do you have distinguish what printed on paper (glyph) and its electronic representation? What do you mean by "context" here? Nomenclatural correction can be made without correcting publication. Do you include such machine-generated one as a *Name-usage*? -- 30 Oct 2004 * Richard Pyle: My intention was for these definitions to exist only within the context of LinneanCore discussions, so "Linnean name-string" seems redundant. But if you want these definitions to have broader scope, then I suppose you could qualify it that way....but how would the definition of a "*Vernacular name-string*" (or other qualified name-string) differ from this definition? d8 3 a10 3 * (RP, cont.) I guess there is no need to specify "printed on paper or represented in an electronic document" -- I only added that bit to emphasize that the *Name-string* exists only in the context of a *Name-usage*. I mentioned "ASCII/Unicode" because I wanted to emphasize that the *Name-string* is the electronic representation of the *Name-string* (I've modified the definition to reflect this). Are there other ways to electronically represent text strings besides ASCII/Unicode? The reason for the restriction to electronic representation is that I assumed that LC data would always be represented electronically (at least at some point in its life). The transliteration of printed scientific names into Unicode *Name-strings* is not perfect (even more problematic with ASCII), so the LC *Name-string* is specifically intended to mean the electronic version. * JMS: Again I prefer to broader defintion with restriction to LinneanCore. TDWG-ish XML schema treates texts as UTF-8 generally, but it does not exclude to have name-strings on specimen label in a JPEG file. How about " A literal string of text characters printed on paper or represented in an electronic document to desiganate a named-object. It is a scientific name represented in UTF-8 within the scope of LinneanCore's domain." -- Oct 30 2004 * Richard Pyle: I'm inclined to agree with all of your points, and change the definition accordingly. However, I just want to establish clarity on one point. In my mind, the word "string" in this context refers *specifically* to a sequence of electronically-rendered (ASCII/Unicode) characters. I do not think of a JPEG or bitmap rendering of a series of printed characters as a "string" composed of characters -- I think of these as images composed of pixels. Thus, to me the "string* implies a standard computer-text (ASCII/Unicode) sequence of characters. I think of the *Name-string* specifically as a schema element in LC (or TCS) that can be searched using text-comparison computer filter procedures. So to me, the *Name-string* is not really a "name object", but an ASCII/Unicode (or UTF-8, if you prefer) representation of a name object. In the case of electronic *References*, they are the same. In the case of paper-printed *References*, there is an implied transliteration. *HOWEVER*, I am willing to change my views on this and define a "Name-string" as a name object (as you suggest), and qualify that within the context of LC it implies a UTF-8 character string -- if you (or others) feel strongly about this. -- 30 Oct 2004 d12 3 a14 3 * (RP, cont.) By "context", I was specifically trying to distinguish the *Name-string* as the literal text string represented in a taxonomic *Reference*, and *not* some sort of "corrected" nomenclatural representation that exists only within LC. Perhaps we need a different definition for "*Code-compliant name-string*" to accomodate the machine-generated "corrected" strings? The Machine-generated instance might be considered as a *Name-usage*, and therefore its corrected nomenclatural representation could be considered as a *Name-string*. But the point is, it would be considered a *Name-string* only in the context of the machine-generated *Name-usage*; not in the context of the *Name-usage* of the source *Reference* Upon which the Machine name instance is based. -- 30 Oct 2004 * Gregor: What do you mean by "Name-string exists only in the context of a Name-usage"? What does exist mean? * Richard: I meant that concatenations of *Name-units* outside the context of a traditional "usage" (e.g., concatenations created by LC logic or some sort of portal logic or algorithm) should not be thought of as *Name-strings* in the sense that I had intended that term to be used. I also meant that the *Name-sting* has a tangible representation (rather than a conceptual entity, like James' "name object"). However, I see now that the distinction can be fuzzy -- so perhaps the definitions should not make reference to "exists" -- I'm happy to strip all of those sentences out of the definitions, because they probably cause more confusion than clarity. -- 30 Oct 2004 d17 2 a18 2 * Gregor: I am rather confused why you limit Name-String to NOT include authors. In my practice I have no use for this term. A name-string without authors is an ambiguous in incomplete namestring. If I want to make conclusions based on name strings in printed or digital publications, I can use name-string with authors, or have to guess about the authors from geographical or historical context. To me the the Name-string-without-authors seems to be the special case. Is this botany against zoology? Or just Gregor :-) ? -- 30. Oct. 2004 * Just to be clear, we are not defining LC entities here, we are defining *terms* to use in our discussion. We need a *term* to refer to a *Name-string* without authorship information, separate from a *term* to refer to a *Name-string* that is fully qualified with authorship information. The importance of establishing unambiguous terms for these things, is that when we start arguing about how to populate LC elements such as "VerbatimName" (or whatever that element ends up being called), we don't have to deal with semantic ambiguity as an additional impediment to communication. Now, in my mind, the "default" (normal) encapsulation of a *Name-string* excludes authorship information. Maybe this is a Zoological bias, but I see it more logically as "*Name-string* vs. *Name-string plus authorship*"; rather than "*Name-string* vs. *Name-string sans authorship*" -- 30 Oct 2004 @ 1.3 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RichardPyle" date="1099188420" format="1.0" version="1.3"}% d11 1 d18 1 a18 1 * Just to be clear, we are not defining LC entities here, we are defining *terms* to use in our discussion. We need a *term* to refer to a *Name-string* without authorship information, separate from a *term* to refer to a *Name-string* that is fully qualified with authorship information. The importance of establishing unambiguous terms for these things, is that when we start arguing about how to populate LC elements such as "VerbatimName" (or whatever that element ends up being called), we don't have to deal with semantic ambiguity as an additional impediment to communication. Now, in my mind, the "default" (normal) encapsulation of a *Name-string* excludes authorship information. Maybe this is a Zoological bias, but I see it more logically as "*Name-string* vs. *Name-string plus authorship*"; rather than "*Name-string* vs. *Name-string sans authorship*" -- 20 Oct 2004 @ 1.2 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="NozomiJamesYtow" date="1099185720" format="1.0" version="1.2"}% d12 4 a15 1 * Gregor: What do you mean by "Name-string exists only in the context of a Name-usage"? What does exist mean? The primary issue with names for me is their comparability. I want to know who else said something about the pathogen I believe I have. Thus I need to define equality rules for name-strings across name usage. In some respect this is what you do when you enter a name in Google etc. What is that string of unicode characters entered in Google that represents a scientific organism name? This is to me the essential item I would call a name string. No problem having another term for it - but give one. Name-string to me seems the obvious choice, rather than constraining name-string to string in name-usage context. -- 30. Oct. 2004 d17 1 @ 1.1 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="NozomiJamesYtow" date="1099176900" format="1.0" version="1.1"}% d3 1 a3 1 Discussion on Name-string d8 1 a8 1 * (RP, cont.) I guess there is no need to specify "printed on paper or represented in an electronic document" -- I only added that bit to emphasize that the *Name-string* exists only in the context of a *Name-usage*. I mentioned "ASCII/Unicode" because I wanted to emphasize that the *Name-string* is the electronic representation of the *Name-string* (I've modified the definition to reflect this). Are there other ways to electronically represent text strings besides ASCII/Unicode? The reason for the restriction to electronic representation is that I assumed that LC data would always be represented electronically (at least at some point in its life). The transliteration of printed scientific names into Unicode *Name-strings* is not perfect (even more problematic with ASCII), so the LC *Name-string* is specifically intended to mean the electronic version. @