262 lines
66 KiB
Plaintext
262 lines
66 KiB
Plaintext
---+!! %TOPIC%
|
||
|
||
%META:TOPICINFO{author="GregorHagedorn" date="1147813288" format="1.1" version="1.17"}%
|
||
%META:TOPICPARENT{name="LinneanCoreTCSInteraction"}%
|
||
The TCS team at Napier has posted pages on the [[http://www.soc.napier.ac.uk/tdwg/index.php?pagename=TCSAndTheLinneanCore TCSWIKI]] where we look at the LinneanCore from the TCS perspective, and provide a worked example of how TCS can represent Names and Nomenclatural issues.
|
||
|
||
Rather than duplicate those pages here (especially as this site seems to be under redevelopment) it would be convenient review our commentary and example at the Npier WIKI....and to add comments and further examples if possible (No Registration Necessary!)
|
||
|
||
-- Main.TrevorPaterson - 29 Nov 2004
|
||
|
||
---
|
||
JMS: Could people please make clear distinction between name-string (target of <nop>LinneanCore) and name (a relationship between a name-string and a named-object, would be expressed by TCS) throughout? Otherwise it is too hard to follow (for non-native speakers at least). Name-strings in <nop>LinneanCore domain are affected by combination for bi- or tri- nomen, but it is not conceptual issue just like difference between "I have" and "she has". If 'generic', 'specific', 'infraspecific' are uncomfortable for their relevance to concept, we would say 'first_token', 'second_token' and 'third_token' instead. Or, does the distinction between name-string and name contradict to TCS philosophy? -- 12 Nov 2004.
|
||
|
||
Metaissue by Gregor: I tried to follow the discussion below and failed at places to understand to whom which part belongs. I tried to reformat it using the indentation style for comments - but I may have failed in places. I hope the original authors can rectify this. Thanks!
|
||
---
|
||
|
||
Taken from email from <b>Jessie</b> and initial responses...
|
||
|
||
I think there is some great stuff on nomenclature issues which it is good to see documented, questioned and discussed e.g. <br/>
|
||
LinneanCoreHomoIsonym (issues of homonym isonym, and nomen novum/replacement name)<br/>
|
||
LinneanCoreHybridNothotaxa (issues about hybrid formulae and "notho"taxa [named hybrids])<br/>
|
||
LinneanCoreNameIdentity (How many elements necessary for infrageneric/specific ranks?)<br/>
|
||
LinneanCoreConceptSuffixString (provide a place in atomization for "s. lat." etc.?)<br/>
|
||
LinneanCoreResourceLinks (Links to <nop>BioCode, etc.)<br/>
|
||
LinneanCoreExampleNames (names from different kingdoms, hard cases etc.)<br/>
|
||
|
||
It would be really valuable for me and I guess others if someone could provide for zoology what Sally has for Botany in terms of examples.
|
||
|
||
* <b>Rich:</b> I will try to get some examples up as soon as I can. I am going nuts at the moment with other work, so it's hard to find free time. I will make a point of trying to get some thorny Zoologial name examples up before I disappear to Fiji in a couple of weeks. I hope others on this list will be able to provide Zoological examples as well.
|
||
|
||
There is also some useful material on issues not confined to nomenclature alone which is great e.g. Relevant enumerations:<br/>
|
||
TaxonomicRankEnum (see also formatted html page)<br/>
|
||
NomenclaturalTypeStatusOfSpecimensEnum<br/>
|
||
NomenclaturalStatusEnum? (e.g. Rejected, Conserved, Sanctioned, etc. Unfinished)<br/>
|
||
NomenclaturalCodesEnum (e.g. "Botanical/Zoological" for ICBN, ICZN, etc.)
|
||
|
||
However...
|
||
|
||
Although I was under the impression that at the Taxon Concepts/Names subgroup on the Saturday at TDWG there was general understanding of the goals and rationale for the TCS and how it intended to deal with nomenclature issues in addition to concepts issues within the one framework, I can see from the discussion that either I (and those present at the meeting) was wrong or it no longer seems to be the case amongst those contributing to the Wiki.
|
||
* <b>Rich:</b> I have to say that I don't understand what you mean by this exactly. As far as I can see, the goals are the same as they were in Christchurch, and have not changed in any fundamental way since then. Yes, we have had some lengthy discussions on the Wiki about the line between TCS and LC, and you've alluded to comments by Gregor on this -- but in my many off-Wiki conversations with Gregor it is clear to me that he agrees that there should be no actual "concept" information (i.e., "<nop>AccordingTo" information, or concept mapping) supported the LC schema. I problem, I think, is much more one of communication barriers, than real differences in understanding (at least from my interpretations of the various discussions).
|
||
* Main.JessieKennedy - 12 Nov 2004: I agree - but it is a real problem at times. I too have had many off-line conversations with Gregor and you and others and think we all agree/understand and then hear some comment and realise we don't. (I think this is a general problem for all of us - me included - we try desperately to map what others are saying on to our view of world and while we can we are happy and as soon as we can't do exactly what we want it turns into a big problem and we end up back at square one. Now multiply this across all of the individuals or groups who have or are thinking about how to model this and we have the situation we're in now all trying to get the model to be like theirs - this is why I said we all need to move away from our own model to accomodate everyone's views.
|
||
* Gregor: I agree :-) However, one way to try to understand each other is to express what biologists involved with nomenclature and name usage would like to look "their" schema to look. This is really what LinneanCore is (and it is not felt just by me and Jerry and Anna and Chris...). I will be very happy if everything fits nicely into a concept schema - but in some sense I do not want this discussion to be constrained by TCS too much. I do try to understand TCS though, and I absolutely do *not* want to express concept circumscription or relationships in LC. However, TCS may define concept differently and includes nomenclatural name identity - this needs to be resolved then in a second pass. I do want to be able to express biological usage (nomenclatural and applied) or the linnean name system. If this usage is entirely inadequate, we need to standards anyway for the next decades. -- Also, Richard is pushing us all - me included - to better define what we are talking about. Maybe these three fronts of progress?
|
||
* Main.RichardPyle - 12 Nov 2004: I'm glad we can all recognize that barriers of communication exist not only due to differences in native language, but even within the english language (due to such *hugely* unfortunate words as "Name", "Valid", "Concept", etc. -- which we need to use in different ways at different times within the same conversation). Gregor -- I assume you meant "s<b>n</b>ugly", not "s<b>m</b>ugly"? (Freudian slip? :-) [Gregor: I did'nt have a clue indeed!]). I also agree with the point that we color our interpretations of what others are saying by trying to "squeeze" them into our own views of the world -- and that heps foster miscommunication/misunderstanding. I don't know how to avoid this, except: 1) try to define our words as carefully and unambiguously as possible (LinneanCoreDefinitions); and 2) try not to jump to conclusions about what others are saying.
|
||
|
||
I also see that there is confusion and disagreement amongst those contributing to discussion on the Wiki what the role of Linnean core subgroup is and I see the beginnings of TCS discussions emerging all over again (maybe this is side effect of using Wiki's as any comment can be made thereby making it difficult to know and follow what the relevant discussion points are). During TDWG Linnean core was being pushed by some as a simple way of providing access to lists of valid names.
|
||
|
||
* <b>Rich:</b> I have to interrupt you here and ask what you mean by "valid names". This has at least two VERY different meanings, and the word "valid" when associated with "names" has caused tremendous volumes of misunderstanding. The two main meanings of "valid" in this context are:
|
||
1. Names that were "validly" created in accordance with a relevant code of scientific nomenclature, and are available for use as such by those codes, with absolutely *NO* indication of whether the names are/should be currently treated subjectively as junior or senior synonyms of some other name. This is a (mostly) "objective" meaning of "valid", citing only the rules of the relevant Code of nomenclature, and having NOTHING to do with taxonomic concepts/circumscriptions.
|
||
2. Names that are subjectively treated as "valid" according to some authority, in the sense that other names may be subjectively considered to be junior synonyms of that name. This is a (completely) "subjective" meaning of "valid", citing the opinion of any given taxonomic authority, and having EVERYTHING to do with taxonomic concepts/circumscriptions. [Emphasis added only to highlight points of contrast].
|
||
The nomenclatural community (and LC) is unambiguously focused on the first of these meanings of "valid" names.
|
||
* <b>Brian:</b> "valid".....mmm - sounds familiar here. Too many people seem to make a mess of the term and zoologists and botanists have at least the stem "valid" vs "valid"ly associated with different concepts. Add to that the fact that a prokaryotic name when "validly published" is not 100% the same concept as botanical "validly published" and the confusion is complete. John <nop>McNeill drew up a table of "equivalence of nomenclatural terms" for the <nop>BioCode - see LinneanCoreResourceLinks.
|
||
* <b>Paul:</b> The IUBS Monograph No 9 'A draft Glossry of Terms used in Bionomenclature' should be up on the web this weekend (I'll mail the link) - there are 60 (A5) pages of terms ;-)
|
||
* Main.JessieKennedy - 12 Nov 2004: hmmm clearly slipped in a very contentious word there - I didn't mean anything particular by it to be honest - so thanks for the contribution on the definition of valid name. I did hear valid being used at the LC meeting and discussion on whether or not we were only interested in valid names (whatever that meant), but I also know that LC is being suggested(or hoped) to be used for any name including common names by some people.
|
||
* Main.RichardPyle - 12 Nov 2004: I think the point is that we should try to avoid using the word "valid" without qualifying it in some way (just like we try to avoiding using the word "name" in an unqualified way). I think we can avoid "valid" altogether by using a term like "Code-compliant" to refer to my first-case use of "valid" (i.e., names "validly" created in compliance with a Code of nomenclature, with no implied subjective "validity" in a synonym sense). The other use of the word "valid" (as distinguished from junior subjective synonym) doesn't really belong in this discussion at all (but does belong in TCS-specific discussions). But in any case, I think the LC group agreed that the domain of LC was limited to only those names governed by one of the Codes of scientific nomenclature (Zoology, Botany, Bacterial, Viral, and Cultivar; possibly also <nop>TradeNames). I don't know wh within LC is thinking about using it for common names -- it wouldn't make sense, because these have nothing to do with Linneaus.
|
||
* Main.JessieKennedy - 12 Nov 2004 (cont.): Name in TCS can potentially be any kind of name - we don't dictate and cannot enforce what people will put in an XML document. However, many users or systems will choose to provide or accept names in your category 1 while others both categories and others even more definitions of name - that you don't consider valid. Problem is a schema cannot enforce validity of the content of strings so we do rely on the system generating the XML documents to generate valid data according to their view of what is valid. It's then up to other users who receive documents to decide whether or not they want to accept the data generated by that provider.
|
||
* Main.RichardPyle - 12 Nov 2004: I think there still needs to be "NameSimple" in the "Name" element of TCS -- but I think it should be defined slightly differently (e.g., "NameVerbatim") -- this could then be used to record the "name-literal" as appears in the "AccordingTo" publication -- which means it could accomodate common names, mis-spellings, and other anomalies that I think fall outside of LC.
|
||
---
|
||
|
||
With <nop>DarwinCore being used as an analogy i.e. it would be a simple list of fields. That was basically what the name components from ABCD which were incorporated into TCS were and what I was informed was being discussed and re-considered by the Linnean core group to ensure the requirements of the nomenclator community were being addressed (and I was and am grateful that this work is being done).
|
||
* <b>Rich:</b> I'm not sure exactly what you mean by "simple list of fields". If, by reference to <nop>DarwinCore, you mean a completely flat structure, then I disagree completely. Nomenclatural information is not flat, and a "most-useful" schema to deal with purely nomenclatural information would not be flat. That the ABCD structure is flat is one of the reasons why it fails to meet the data exchange needs of nomenclators (many of us also feel that the separation of Kingdoms [=Codes of nomenclature] is a suboptimal approach to representing nomenclatural information). However, it is unambiguous in my mind, and I *think* in the minds of most/all other members of this CC list, that the fundamental "unit" of a LC instance (all of the fields of which can be distilled down to the "Label" element of LC 0.1.4 -- which I believe should effectively map 1:1 with the TCS "NameSimple" element) is a "name" object, and most definitely NOT a concept object.
|
||
* Main.JessieKennedy - 12 Nov 2004: This gets closer to the point I was trying to make about the relationship between the TCS model and the LC model. there are so many entities and attributes in common when designing a model for taxonomic names and a model for taxonomic concepts that one (or I did) starts to question what the actual differences really are and wouldn't it be sensible to have one schema that could do both. So if LC becomes more that a flat structure - then it seems to defeat the request from Donald to have a simple structure that can be implemented first as simple records and then deal with the more complex document based structures later. Now I'm not actually in favour of that route - I think you can extract simple data from complex but don't think you can EASILY generate the more complex data nomenclators or taxonomists want from the simple data. So what I was hoping for was a set of fields that would allow us, using the appropriate combination, to represent any name (valid or not). To do this we do need to know how names may be formatted and to help understand what we're receiving it is useful to classify the different type of names. But what I was hoping to argue was that we could use the one schema to represent both user community requriements - now clearly I haven't convinced you of that yet and maybe we can't - but I'd like to try if possible to find a single solution rather than go for two complex and potentially very similar schemas - referencing each other to solve the problem. I'll try and discuss this further in a separate page.
|
||
* Main.RichardPyle - 12 Nov 2004: I don't think there is any real disagreement here. When you say "valid or not", I don't know which sense of the word "valid" you are using. But other than that, I think we both agree that LC should not have *truly* redundant elements with TCS, and that LC can fit "snugly" within TCS, so there is no overlap. Where I think the problem is, is that information that might at first *seem* to be redundant, really is not. That was my point about the Smith 1949 example. Here we have one publication (Smith 1949) that appears twice -- once to represent the fact that this publication serves as the Code-compliant origination of a name object, and a second time as an "AccordingTo" to imply a completely separate object (a concept object) -- which is the circumscription of organisms that Smith 1949 would have included under her name "Aus bus". So the two pointers to Smith 1949, although they seem redundant, really represent two different kinds of informational linkage.
|
||
* Gregor - 12. Nov. 2004: I agree with Richard's points. And I really like Sally's KIFF = Keep it fairly flat (on LCNameAuthorshipConventions)! That is what I search for the "level 2" object abstractions / data interfaces.
|
||
|
||
However I am disappointed that much of the confusion and requests for changes to Linnean core/ABCD and hence TCS is coming from Gregor (sorry Gregor, I am impressed by your drive and enthusiasm to have your say in all these discussions but find some of your comments unconstructive). There was invitation to all interested in TCS (names and concepts) to attend the relevant working group meetings during TDWG, so I find it unreasonable that Gregor is saying that he doesn't understand TCS when I went to lengths to explain it's rationale and design philosophy and gave people a chance to raise any questions or issues and to address any misunderstandings. Gregor however didn't give a presentation on his ideas at the meeting even though he submitted an abstract suggesting he would nor did he attend the subgroup session on Saturday nor the Linnean group session on the Sunday. I wasn't even aware that Gregor was a nomenclator but perhaps I<>m wrong or I misunderstood the reasons for re-considering the ABCD section. However, I would<6C>ve thought that Gregor had enough on his plate trying to finalise possibly the most complicated of all the TDWG standards (SDD in addition to UBIF) and that it would have been reasonable for him to accept that other groups can consider and reason about the conflicting requirements of all potential users of the standard on coming to a design decision.
|
||
* Gregor - 12. Nov. 2004: I try to be constructive and reasonable. But:
|
||
1. I had no chance to attend the Names subgroup meeting because on the weekend the SDD group convened in parallel to the names session (both Sa and Sunday all day).
|
||
2. I did apologize for dropping the names talk. I was simply unable to cope with the demands at the meeting: I had to give 2 other talks and chair a plenary session on the afternoon (after 2 other talks in the SDD session on the previous day). Donald said he would like to say more than he had time, and I had more talks than I was able to cope with, so I gave him my time.
|
||
3. Furthermore, the main issue of my talk was to show that the name type adopted from ABCD could be better structured. My talk essentially showed a mapping of the ABCD type choices to somethings similar to LC 0.1.4 Proposal 2 (which, however, is improved over my Christchurch attempt due to the input of others, esp. Sally's first draft!). At the time I dropped the talk, Jessie had already signaled me that she did not have a special interest in the ABCD names type, and that any alternative stemming from the LC discussion and would suit her if it finds greater acceptance. So a large part of the talk was already pointless.
|
||
4. I explained my criticism of TCS as clear as I possibly could in more than a dozen very long emails to Robert and Jessie, and saw little value in repeating this during TDWG - I think the time was better spent by others.
|
||
5. Why working on LC although dealing with SDD? Two issues are vital for SDD: 1. The SDD / TCS relation is problematic. TCS could include SDD in the form of circumscription. Descriptions are one way to define a taxon concept (sensu concept circumscription). SDD descriptions are a way to create a circumscription. To say what you are describing you either need a name (atomized or not) or a nomenclator-GUID defining the name-object. If that is only expressible in TCS, you could never be able to express any description outside TCS - and I think this is not practical. I would prefer both referring to a common base. 2. To achieve this (and the same for specimens, which can also be described), SDD (together with ABCD) tries to develop a foundation of abstract interfaces to other knowledge domains (class names, class hierarchies, specimen/units, publications, geographical locations, agents) in UBIF. This is almost the priority item in getting SDD out. Without getting some simple name standard into UBIF <nop>ClassNames, SDD will not work. -- I hope that in LC we will get some of these foundations. That is one place were LC differs from TCS: I very much hope that TCS and UBIF/SDD can use a _common_ scientific organism name (LC) and literature citation (AC) schema!
|
||
* Main.JessieKennedy - 15 Nov 2004: TCS does include a placeholder for SDD as part of its potential definition - you do realise that don't you? What you're describing (unless it is a specimen - which could be identified to a concept by you) is a name according to someone - probably you if it's a new concept. What is there to stop SDD referring to a specimen identifier or a concept identifier? The work we did on Prometheus specifically says you are describing a specimen or a taxon concept - but I'd still say it is the specimen or the concept that has the description - not the other way around - although if that's the way you want to look at it I don't see what the problem is. This was one of the points I made at TDWG where we could have a "superschema" composed of all of the TDWG schemas (which would mean redundancy in terms of the schema) so imagine TCS refers to SDD and SDD refers to TCS - it starts to look recursive. But for anyone's use they would take a valid subset of the schema representing things the way they see it...
|
||
* Gregor: Yes, TCS has a container to contain descriptive circumscription data. At the moment, however, it is very difficult to put any SDD there. This is no fault of TCS but a result of the design of SDD as a document format that has relations to other parts of the document. We are aware of this problem, but so far exchanging complete datasets (terminology togehter with descriptions) had priority. We discussed how to solve that in Berlin - decoupling terminology and using GUIDs to refer to terminology. However, no clear solution emerged and I still hope so see some light in the proxy / identifier issue (see also ObjectIdentifierPattern) and hope that as soon as possible this gives a foundation that SDD can alternatively used in a validating context and non-validating out of context like when embedded in TCS. --- However, although I am quite happy if SDD should be embedded inside in TCS, and although I hope to offer means to refer to TCS concept, I also believe that some decoupling is needed. As you say, an SDD description is one way to create a circumscription concept - but that means that I need a way to refer to a nomenclature record. I am not happy with including _only_ a TCS-based resolvable concept identifier. That would mean that any reporting of a SDD description, or running and identification key requires the referred service online. So I need some local ("proxy") structures - and I am looking to the LC name types developed here for this purpose. And just as it is difficult to embed SDD in TCS, it is impossible to do the reverse, because as I understand it TCS is a document format that has relations to other parts of the document... I could have used the ABCD style name type, but I find this not very desirable. It is fine for collections usually organized by taxon group (so any provider needs to deal only with a quarter of the structures), but not really if your software intends to deal with all of biology (not to mention Bob's restaurant guide, for which the scientific name structure is pretty useless...)
|
||
6. To sum this up: I try to stay away from concepts discussion (sometimes unsuccessful) and am glad if nomenclator's needs and TCS go hand-in-hand. I need some basic stuff for SDD, just like Anna and Chris need names stuff for <nop>TaxMLit. But foremost, I, Jerry, Anna, Chris, Paul Kirk, Dave Remsen and others are members of GBIF ECAT SSC and have a responsibility there. We did needed a LC-like standard already last year and it still is not available. At TDWG 2003 it was said that TCS would deal with both concept and names questions for the purposes of ECAT. It is, however, _not_ Jessies fault that she was asked to do work GBIF ECAT depends upon without being asked to participate in the ECAT discussions, and actually with (almost?) no overlap between the ECAT SSC and her working group participants.
|
||
-- Main.JessieKennedy - 15 Nov 2004: At TDWG 2003 it was never said to me that I was to deal with concepts/names for the purpose of GBIF ECAT. GBIF were one of the potential users to consult - and with whom I did - if those named shoud've been consulted then I'm sorry but this was not made clear to me by anyone - even though I did ask whether or not I should attend the GBIF meeting in May this year.
|
||
|
||
---
|
||
|
||
I have the following reservations based on some of the discussion on the Wiki:
|
||
|
||
It is unfortunate that following years of work by the ABCD group that there doesn't appear to be an ABCD representative contributing to the discussion <20> are you sure that you aren<65>t overturning well reasoned and argued decisions on why things were designed the way they were?
|
||
* <b>Rich:</b> I don't know who is, or is not (would, or would not be) considered as an "ABCD representative". Certainly any/all input from anyone directly involved with ABCD would be most welcome. However, as far as I can tell from reviewing ABCD v1.49, taxonomic elements exist only in the context of identifications of specimens, not as "name objects" with all of the associated information relevant to nomenclators (almost all of which is non-concept information).
|
||
* Main.JessieKennedy - 12 Nov 2004: Yes - agree they aren't name objects an did didn't want them to be - see above. I was hoping the nomenclators could see their names as equivalent to original concepts i.e. from their perspective the first usage of a name to some definition - even if all we have recorded of the definition is the type specimen - see below..
|
||
|
||
ALL agreed at the meeting that specimens or observations should be labelled with concepts_names (or concept GUIDs) not scientific names (e.g. binomial plus original author) therefore I don't understand why is this even being given wiki space unless you<6F>re starting the modelling process from scratch again.
|
||
* <b>Rich:</b> This touches on what I see as the *only* real *potential* point of contention between the LC camp and the TCS camp. I use the word "real" here meaning not simply an artifact of miscommunication and/or misunderstanding; and the word "potential" because I do not think that it necessarily must be a point of contention. That is, how to deal with the designation of type specimens (particularly primary type specimens). What makes this particular topic unique is that it represents the only true intersection/overlap between "name" information and "concept" information. From one perspective, Primary type specimens are an attribute of a name object in the form of a Code-regulated typification event. From the other perspective, a taxonomic name is an attribute of a primary type specimen object (and therefore a matter relating to concepts) in the form of an identification/determination event. This topic will undoubtedly need substantial further discussion.
|
||
* Main.JessieKennedy - 12 Nov 2004: Almost agree. However, nomenclature never come before classification. So your first perspective is a perspective only - we can model things in many ways but it is in reality a secondary perspective. Because what really happened was that a taxonomic concept was defined (even if not well described and documented) and then because a specimen from the circumscription was selected to be the type specimen and we applied a name according to the appropriate rules of nomenclature to the concept, you can then say the type specimen is an attribute of name - but this is secondary and doesn't only need to be seen like that. So I say that names ALWAYS have SOME KIND OF relationship to a concept and are either integral to the creation of the concept (original concepts) or are related to another concept (revised concepts). Even nomenclature changes due to changes in gender, always link back to a name integral to the taxonomic concept it was assigned to. So yes you can say "I'm a nomenclator" (if that's really the correct word) and I don't see it like that and don't want to see it like that but with a little cooperation we might have a model that allows nomenclators to do what they want but also deals with other perspectives too... I'm not coming from any one perspective. I was coming from the taxonomists perspective as I learned during the Prometheus project. But now being involved with SEEK I have to see things from an ecologists perspective and from the perspective of all the taxonomic data providers out there including nomenclators. Now, I'm not saying I've got it 100% but am trying to keep shifting perspectives to see if we can accommodate all in one (transfer only - not implementation) model.
|
||
* *Gregor:* (*Danger zone* - I invent new terminology here in an attempt to reach an understanding!) There is no question that a name is created for the purpose of defining a concept. And biology would really like to have circumscriptions concepts, but because of limitations of what is doable, defines only *points in the biodiversity space* - the type specimen. From then on, the name is fixed to this *point-concept* (and reverse, based on priority), and multiple people try to define *circumscription-concepts* on top of it. These must keep their relation to the point-concept. Also, because the Linnean system entangles hierarchy and name-identity, rules exist how the name-string-with-authors has to change, *without changing* the point-concept nor the circumscription concepts. I believe, intuitively most biologist accept that there is a "name-object" or whatever to call it, that has multiple strings, a type specimen, and publication. Once created, this thing is there. It is such a fundamentally different kind of concept than the circumscription concept, that I and I believe most biologists do not sum it up under a generalized "concept". The concept debate I have been reading (esp. Berendsohn's publications) really is mostly about circumscription and name usage. -- I believe this split would make it easier for biologists like me to understand (I have no statistic on how many these are, it depends on your _concept_ of "like").
|
||
|
||
There seems to be confusion about what a transfer schema should do. To support the community at large it should not dictate how any application should be implemented, nor should it dictate what any database system must or must not contain, nor should it present a view of the world from only one of the community<74>s perspective <20> if we want a community standard exchange format everyone must move from their own view/model of the problem/requirements but still be able to map their data to the schema to exchange their data. (Why I explained the different types of users/views of what concepts/names were in my presentation)
|
||
* <b>Rich:</b> I'm not sure I understand why you think that anyone is in disagreement with you on this (in the context of LC). Like Sally, I think it would be helpful if you could point to specific examples of where you think there is confusion on this.
|
||
* Main.JessieKennedy - 12 Nov 2004: Hopefully this will emerge from my answer to specific points above and below - at some point I'll take check and see if it has.
|
||
|
||
Some of the discussion is about what a particular application i.e. a nomenclature tracking system or name resolution system should do and requires <20> I don<6F>t believe this should be encoded in the schema - it should be documented in the mapping from that database onto the schema or in the specification of the software design. This is still important and the work may still to be done....but not as part of a schema design.
|
||
* <b>Rich:</b> Again, I guess I would need to know specifically what provoked this concern of yours. There has certainly been discussion about how the information would be used and by whom -- which I think is absolutely fundamental to a schema design discussion. In many cases, it is possible to represent the same information in different ways. Both may be equally elegant solutions to the information structure problem, but one may have advantages over the other if you have a sense for how the information will most often/most likely be used.
|
||
* Main.JessieKennedy - 12 Nov 2004: I haven't gone back to particular places in the Wiki yet but I guess I was thinking about rules for things - these can't be captured in the schema and generally are about how the software is developed and deals with the data. Rules applicable to nomenclators might be very different to that by GBIF or SEEK or whomever.
|
||
* Main.SallyHinchcliffe - 12 Nov 2004: I think that the only place we've mentioned rules so far (correct me if I've missed a bit, I too have a day job!) is in the rules for forming a name, e.g. you shouldn't have an infraspecific hanging off another infraspecific, it should always hang off a species. We deliberately excluded the possibility of that in the LinneanCoreCanonicalName structure, precisely <strong>because</strong> hanging an infraspecific off another infraspecific is a taxonomic decision, and so it belonged in TCS <strong>not</strong> LC. Are you saying that we should allow constructs like <i>Aus bus subsp. cus f. dus</i> in LC? It's easy enough for someone to generate the trinomial from the quadrinomial (as you say, its easy to generate simpler data from more complex data, and not v.v.) so if people like SEEK or whoever have quadrinomials they should be able to still form valid LC structures from them.
|
||
|
||
Although the process of nomenclature is separate from the process of classification (and yes I<>m co-author on a paper in Taxon arguing this), as soon as one considers the use of names <20> either by taxonomists or other biologists or even nomenclature specialists I haven<65>t seen a convincing discussion or proposal that actually keeps names separate from concepts and I am even more convinced of this having talked to a wide range of potential users this past year. So let me re-iterate: people can<61>t refer to concepts without names nor does a name exist without some kind of relationship to a concept.
|
||
* <b>Rich:</b> I agree with you on the first part of your last sentence quoted above, but not on the second part. And I think this may well be the source of a lot of the confusion and misunderstanding. The only biological material that is necessary for a taxonomic name to exist is the implication that a primary type specimen-individual (or syntype series-individuals) existed at one time. That is, the only "concept" that must exist in order for a name to exist is a single individual organism. To me, this is not a meaningful "taxonomic concept" -- by anyone's definition. In other words, a circumcription of one specimen is so unbelievely useless a concept, that it really shouldn't be thought of as a concept at all. "Aus bus Smith, 1949" refers to a name object -- which means that Smith, in her 1949 publication, complied with the relevant Code of nomenclature to make the name "Aus bus" available according to the Code. It is linked to the real world of biology only through the primary type specimen(s).
|
||
* Main.JessieKennedy - 12 Nov 2004: ok - if we were talking about how things should be done I would agree with you but I'm always being told we're not only talking about how things should be done (Prometheus view) because we have to deal with legacy data. So we need to deal with how things were done and here I would disagree with you - just because all we have recorded about the first usage of a name is a type specimen - it doesn't mean that there wasn't a concept - I would say there clearly was one in the mind of Smith.
|
||
|
||
* <b>Rich:</b> This is an altogether different object from what is implied by "Aus bus Smith, 1949 sensu Smith 1949". This is a concept object, and it's definition has little to do with Codes of nomenclature, and everything to do with the information that Smith 1949 included in her publication to identify the full scope of organisms (over & above the primary type specimens) that exist/have existed/will exist in the real world that are encompased by the *taxonomic concept* that Smith, 1949 had in mind.
|
||
* Main.JessieKennedy - 12 Nov 2004: ahh...now you've changed the argument so we do have more of a definition of Aus bus Smith, 1949 ;-) Because this is an original concept the same publication does act as the citation for the first usage of the name and the definition of the concept so they are only different in the sense that given a complex object the taxonomic concept - the name is a projection view on that object - only the elements the LC people are interested in.
|
||
* Main.RichardPyle -- 12 Nov 2004: Actually no -- it's the same argument that I have been trying to make: That "Aus bus Smith, 1949 sensu Smith 1949" implies two different things: the name object ("Aus bus Smith, 1949") that has no concept associated with it (other than the primary type specimens), and the TCS/Concept object ("Aus bus Smith, 1949 sensu Smith 1949"), that represents the entire scope of organisms that Smith (1949) would have applied the name "Aus bus" to (well beyond the primary type specimen). The fact that both the name object and the concept object are both anchored to the same publication (Smith, 1949) is really just coincidence. The point is, the Name-object and the Concept object in this case are every bit as separate as they are for "Aus bus Smith, 1949 sensu Jones 1990".
|
||
* Main.JessieKennedy - 15 Nov 2004: I don't believe it is coincidence!! Why or how can you publish a new concpet wihtout naming it? And would anyone ever accept a publication for a new name without a meaning associated with it? - even if that meaning is the meaning for a name previously published??? I think the "name object" is an artifact... the name string is real but always associated with a meaning in my mind and those who use it - even if they don't know exaclty what it means (and therefore is potentially a different concept ;-) although unintended).
|
||
* Main.RichardPyle -- 15 Nov 2004: O.K., "coincidence" was a poor choice of words on my part! What I meant to emphasize was that "Aus bus Smith 1949 SEC. Smith 1949" has (and *needs*) two separate pointers to "Smith 1949". One of them (the first) points to "Smith 1949" as the Code-defined authorship of the name-object. The other (second) pointer to "Smith 1949" represents the "AccordingTo" publication that serves as the source for the concept-object. You *need* both pointers separately, so you can distinguish the concept-less "Aus bus Smith 1949" (which I undertand the TCS "Nominal Concept" to be intended to represent), from the "Original Concept" of "Aus bus Smith 1949 SEC. Smith 1949" that was created "coincidentally" within the same publication. My only point is to explain why LC does (and should) have publication pointers within it, separate from the publication pointers in the "AccordingTo" part of TCS. Just as "Aus bus Smith 1949 SEC. Jones 2001" needs pointers to two separate publications (one as the source of the name, and the other as the source of the concept), so too does "Aus bus Smith 1949 SEC. Smith 1949".
|
||
|
||
* <b>Rich:</b> These two different object units -- the name object, and the concept object -- need to be handled separately. LC needs to include the publication details of the "Smith 1949" publication, because there are of *nomenclatural* importance in identifying the nomenclatural act that established the name "Aus bus". TCS needs to *separately* include the publication details of the "Smith 1949" publication, to place within the "AccordingTo" structure, to show that we mean the name "Aus bus Smith 1949" according to the usage of Smith 1949.
|
||
* Main.JessieKennedy - 12 Nov 2004: So they do need to be treated differently - names (generally speaking) will be project views over original concepts.
|
||
|
||
I know you know all of this, but my point is that what may *appear* to be overlap between LC and TCS (e.g., both needing to point to the publication details of SMith, 1949), are in fact quite different pieces of information, and do not represent overlap at all.
|
||
* <b>Sally:</b> Am I right or wrong in thinking that TCS needs the author and publication fields in its schema to document the author and publication details of the _concept_. LC needs the author and publication fields in _its_ schema to document the author and publication details of the _name_ (s.l.). When the TCS is transferring data about original concepts (Aus bus Smith sensu Smith) then that data ('Smith', Journal of Good Housekeeping or whatever) will be duplicated. When the TCS is transferring data about a new concept (Aus bus Smith sensu Brown) then the data (Smith, Brown, Journal of Good Housekeeping, Goatbreeders monthly) will be different.
|
||
* Main.JessieKennedy -12 Nov 2004: This is correct Sally...and yes does look a bit strange to think we duplicated it but this was one of the design decisions for right or wrong but good use of IDs would save too much duplication.
|
||
|
||
Or is Jessie's point that the LC should not be passing the author and publication information at all just some fields ('Aus', 'bus')? In which case, in the second example, where does the 'Smith' bit go?
|
||
|
||
Or are we arguing about something different & I've missed the point about where LC and TCS are starting to overlap?
|
||
|
||
examples needed ...
|
||
* Main.JessieKennedy -12 Nov 2004: We want the name element in TCS to include the original author and date or whatever fields are necessary to format a "valid" name. Now in the original concept, Smith 1949 will have an according to - which is the publication where it was defined and hence the publication where the name was first used. In the revised concept, we would have an appropriate nomenclatural relationship (has basionym or something) to the original concept (where if you wanted you could get the publication of Smith 1949) but this would also have an according to which would be the Brown publication. so the according to has to deal with the sec. part of the name. Now one question I have is that sometimes we have "names with sec. or sensu" but not always - I believe these are not part of the code for "valid" names but could be completely wrong here - so wondering if LC people thing se. and sensu types names are in their remit?
|
||
|
||
Perhaps those of you who are expert in and only interested in names for their own sake think you can and if that<61>s so I accept that as I do the many ways that people define concepts which to me may personally seem strange, however the vast majority of biologist and users of names can<61>t and don<6F>t. So regardless of the fact that some people say a concept can have many names <20> how I interpret this is that they mean that the definition part of the concept can be the same in different taxonomic concepts with different names <20> this is how we have modelled it, explained it and require it to be understood to engage in a meaningful discussion about how for example Linnean core fits into TCS or how any particular issue or data problem can be represented in TCS. I tried to emphasise this at TDWG and thought I had succeeded but now am wondering if I did.
|
||
* JMS: I have difficulty to fill the leap between agreed "no name without a concept, no concept witout a name" and TCS's "name and concpet mapping must be unique, even though definition of the concept is shared by cocnepts with different name-string". Your interpretation, "the definition part of the concept can be the same in different concepts with different names" (I omitted 'taxonomic' to make my point clearer), says "the concept" implying that there is a single concpet. What will make you unhappy if <nop>TaxonConcept has multiple Name elemnts? I understand it cna be also represented by mapping between <nop>TaxonCocnepts having different Name element shairing definition, but I'd like to konw rationale (or benefit) preferring to single-Name-single-TC. (Of course, <nop>TaxonCocnept must have at least one Name element, and conceptual equivalence must be separated; these Name elements in a single <nop>TaxonConcept must come from a single <nop>AccordingTo ... oops, it is TCS issue, not LC). TCS defines as concept = name + definition, while I would say each name is a relationship between a name-string and a concept (it does not mean we can manage concept without name). If we distinguish name (remaining as an element of <nop>TaxonConcept) and name-string (meaningless itself, only a string, it need a <nop>TaxonConcept to be a name), how <nop>LinneanCore only minding scientific-name-like string can be trouble? Even with <nop>LinneanCore outside of TCS, <nop>TaxonConcept still retains name-string as Name element. If other standars, such as SDD (or even ABCD?), need concept, then they'll use TCS. If only name-string (not name!), then they may use <nop>LinneanCore. I don't see problem here. -- 13 Nov 2004
|
||
|
||
Based on these points it seems to me that the discussion on the Wiki is introducing concept issues into the requirements even though some people are trying hard to keep it concept free. If this continues what in my mind will eventually happen (even if you try your hardest to ignore information that is unequivocally only about concepts) is that you will still come up with an abstract model that needs to deal with everything that the TCS already does, e.g. names will have: specimens, relationships between them of different types (whether you choose to model this as relationships or embed them in the data type), citations, authors, (descriptions?), other people<6C>s opinions on the relationships someone else asserted about a name etc... So we will have two schemas to handle taxonomic names and concepts <20> does the community really need this?
|
||
* <b>Rich:</b> No, the community does not need two schemas for handling concepts -- but I am a bit of a loss for why you feel that the LC group is heading in this direction. Again, I guess I will rely on you for providing specific examples that illustrate your concerns. I already explained in "Part 1" of this long-winded response why I believe that a name-object needs to point to publication instances, separately from why a concept-object needs to point to publication instances -- and in some cases there will seem to be duplicated information (when technically, there is not).
|
||
* Main.JessieKennedy - 12 Nov 2004: hmmm but I disagree with this - this is where it gets difficult to follow the arguments I guess - so I won't respond to the material below here but try and come up with some JKExamples to explain what we think it is - but not today - sorry..
|
||
|
||
----------------------
|
||
*Rich:*
|
||
|
||
Following up on my previous example of "Aus bus Smith, 1949 sensu Smith 1949". Based on my understanding of TCS, I can imagine two TCS records that look (in abridged form, with some ad-hoc modifications to the current LC schema) something like this (I hope I've rendered the XML properly):
|
||
<verbatim>
|
||
<DataSet>
|
||
<Publications>
|
||
<Publication id="9876" type="Article">
|
||
<PublicationSimple>
|
||
Smith, J.D. 1949. Aus bus, a new species of Cidae from the Hawaiian Islands. Journal of the Linnean Core. 1(1):15-20
|
||
<PublicationSimple>
|
||
<PublicationDetailed>
|
||
[Insert full "AlexandriaCore" schema instance here for publication details of Smith, 1949]
|
||
</PublicationDetailed>
|
||
</Publication>
|
||
</Publications>
|
||
<TaxonConcepts>
|
||
<TaxonConcept type="Nominal" id="1234">
|
||
<Name id="1234">
|
||
<NameSimple>Aus bus</NameSimple>
|
||
<NameDetailed>
|
||
<Label>Aus bus Smith, 1949</Label>
|
||
<CanonicalName>
|
||
<Text>Aus bus</Text>
|
||
<Genus>Aus</Genus>
|
||
<SpecificEpithet>bus</SpecificEpithet>
|
||
</CanonicalName>
|
||
<CanonicalAuthorship>
|
||
<Text>Smith, 1949</Text>
|
||
<ProtonymCitation id="9876" />
|
||
</CanonicalAuthorship>
|
||
<Rank code="sp" text="species" />
|
||
<AuthorsTaxonOrthograpy>Aus bus</AuthorsTaxonOrthograpy>
|
||
</NameDetailed>
|
||
</Name>
|
||
</TaxonConcept>
|
||
<TaxonConcept type="Original" id="5678">
|
||
<Name id="1234">
|
||
<NameSimple>Aus bus</NameSimple>
|
||
<NameDetailed>
|
||
<Label>Aus bus Smith, 1949</Label>
|
||
<CanonicalName>
|
||
<Text>Aus bus</Text>
|
||
<Genus>Aus</Genus>
|
||
<SpecificEpithet>bus</SpecificEpithet>
|
||
</CanonicalName>
|
||
<CanonicalAuthorship>
|
||
<Text>Smith, 1949</Text>
|
||
<ProtonymCitation id="9876" />
|
||
</CanonicalAuthorship>
|
||
<Rank code="sp" text="species" />
|
||
<AuthorsTaxonOrthograpy>Aus bus</AuthorsTaxonOrthograpy>
|
||
</NameDetailed>
|
||
</Name>
|
||
<AccordingTo>
|
||
<AccordingToSimple>Smith</AccordingToSimple>
|
||
<AccordingToDetailed>
|
||
<AuthorTeam>Smith</AuthorTeam>
|
||
<Date>1949</Date>
|
||
<PublishedIn ref="9876" />
|
||
</AccordingToDetailed>
|
||
</AccordingTo>
|
||
</TaxonConcept>
|
||
</TaxonConcepts>
|
||
</Dataset>
|
||
</verbatim>
|
||
|
||
The first thing to notice is that the Publication details ("Alexandria Core") have been moved out of LC <nop>ProtonymCitation, and instead referenced via the TCS method (Jessie -- correct me if I interpret TCS correctly here). It has the GUID "9876".
|
||
|
||
The other thing to notice is that there are two <nop>TaxonConcept instances represented here: one is "Nominal" type and the other is "Original" type. The "Nominal" type contains only LC elements -- it is an "empty", name-only concept (no "AccordingTo", etc.). This is what I imagine a basic concept-less LC instance would look like (i.e., enclosed within a TCS wrapper). Notice that both <nop>TaxonConcept id="1234", *and* Name id="1234". This is my attempt to illustrate how the same GUID series used for TCS instances could be inherited by the LC schema where <nop>TaxonConcept type="Nominal".
|
||
|
||
The second <nop>TaxonConcept instance is of "Original" type -- which, as I understand it, implies that a concept is created at the same time that its name is created (correct, Jessie?) This TCS instance *is* intended to represent a specific taxon concept -- the concept asserted by Smith in the original publication that created the name. Note that <nop>TaxonConcept id is different ("5678"), but Name id is the same ("1234").
|
||
|
||
My main point here is that there are separate "name-only" and "concept-bearing" TCS instances represented by the idea of "Aus bus Smith, 1949 sensu Smith 1949".
|
||
|
||
If I have totally misunderstood either TCS or LC, now would be a VERY good time to clue me in.
|
||
* Main.JessieKennedy - 12 Nov 2004: hhmmmmmmm - some things a bit confused... original concepts are names concepts but with some additional information that the nomenclator needs to ignore. So there would only be one concept here but different users nomenclators and taxonomists would be interested in a different subset of the schema. - wait for examples to see more. Nominal concepts were there really to deal with users of concepts who want ot mark up their specimens or observations or descriptions without referring to an actual concept. So they might want to use the name Aus bus Smith 1949 to label something - we ALL agreed this wasn't useful and we should wrap it in a TCS concept that had that name with nothing but the name fields filled in and a set of relationships to all concepts that have that name. so every time an original concept (first usage of a name) is created we could (explicitly or implicitly) create a "nominal" concept that allows users to label things with "names", thereby allowing the person to say "I know that I have something with this name but the reader needs to interpret themselves what I mean by it - I don't necessarily mean the original concept and certainly don't wean tot be forced to be interpreted like that, nor do I want to tie it down to any other specific concept with that name, nor do I want to define my own concept with that name but you may be interested in the fact I think it's related to the concepts that have been given that name" wow.... This requirement came from discussion with Gregor when he explained he wanted to label things with names without specifying the actual meaning he meant. So I don't really think that nominal concepts are what the nomenclators want - but we need to explore that further.....
|
||
|
||
Will this be finalised any quicker than TCS? Concern has been raised about waiting for TCS to be finalised... so what<61>s actually holding up finalisation of TCS - is it because of a "it doesn<73>t represent things the way I do it" phenomenon? I believe that TCS is almost finalised or could be very soon and I hoped that the Linnean core would help that by getting agreement on the fields necessary to detail a name applied to a concept - currently the according to element and the name element (ABCD name) in TCS.
|
||
* <b>Rich:</b> The LC group is not concerned with the <nop>AccordingTo element in TCS. There are no <nop>AccordingTo's for names (unless you count "According to the IC_N Code of Nomenclature"). We are really only concerned with what falls within the <Name> element of TCS.
|
||
* Main.JessieKennedy - 12 Nov 2004: well there are if you treat original concepts as dealing with first usage of names and thereby publications... If you are only interested in what falls with the name element, I don't see any relationship information in the <Name> element...
|
||
|
||
The only other things we are waiting on is an agreed interface to the other schemas being developed, i.e. the elements we have marked with placeholders.
|
||
* <b>Rich:</b> I think the point is that you should insert such a placeholder within the <Name> element of TCS, and help the LC group fully develop the schema that will be inserted there.
|
||
* Main.JessieKennedy - 12 Nov 2004: I didn't insert a placeholder as I didn't see it as a schema more a simpler datatype - as LC could use concepts to model names - see above.
|
||
|
||
However we don<6F>t need to wait for all the other schemas to be completed to move on - for those desperate to move on they can use a proposed schema knowing that they will have to transform their data or software to deal with the agreed schemas in due course (this is not a problem confined only to TCS). The placeholders include publication, specimen vouchers for which TCS would suggest a GUID attribute plus a set of fields which can uniquely identify the object being represented by the other schema in the absence of GUIDs and which also act as a human readable version of those elements.
|
||
|
||
I guess I could continue but I<>m sure that it will be counter-productive at the moment. I could and in fact would like to try and explain things again if anyone doesn<73>t get the idea we<77>re presenting. I would like to ensure that we have understood and taken into account all of the requirements of nomenclators <20> much of the information on the Linnean core Wiki will contribute to that understanding, and am sure we can find a good solution. I only ask you to be careful that you don<6F>t end up re-doing what we did last year but with a narrower group of users unless you really intend to, in which case we should be clear about the fact that that<61>s what Linnean core is doing.
|
||
|
||
Having read this far I hope you don<6F>t think I<>ve made these comments because the Linnean core Wiki is suggesting changes to our proposal and I simply don<6F>t like it. I<>m very happy to have good suggestions which improve the schema but if the suggestions fundamentally change it then I'm reluctant to start modelling TCS over again. If they are suggestions because of misunderstandings then it<69>s a waste of time arguing back and forth until we explain TCS more clearly. So I am happy to reply to specific questions about the relationship between Linnean core and TCS but unless the philosophy of TCS is understood the discussion may become a bit pointless.
|
||
|
||
|
||
-- Main.JessieKennedy - 11 Nov 2004
|
||
---
|
||
|
||
<b>Sally:</b> I think that the most helpful thing would be if you could point out exactly where Concept stuff is creeping into Linnean Core and what bits you'd want to cut out and have (just) in TCS.
|
||
|
||
Also what might be really helpful would be some examples of TCS data especially now you think it's getting towards completion. - with LC slotted in to the names gap we can see clearly where the overlaps are & have a real discussion on what should go where. For me, that would make the division of labour between LC and TCS a lot clearer than any number of philosophical discussions. Maybe that's just me?
|
||
* Main.JessieKennedy - 12 Nov 2004: hopefully I'm starting to do that for you....
|
||
|
||
---
|
||
<b>Rich:</b> Thanks, Jessie. I guess my two requests to you would be:
|
||
1. Tell us specifically where you think that LC is encroaching on TCS (i.e., overlapping concept information), so we can address your concerns in a more specific way;
|
||
2. Please explain to us (or point us to a document that explains) the detailed definitions of the different <nop>TaxonConcept types ("Nominal" [was "nomenclatural"], ["Original"], etc.) in TCS, and what they were intended to represent.
|
||
* Main.JessieKennedy - 12 Nov 2004: Have started explaining above but will create a separate document that explains this more clearly and that stands alone so is more understandable - next week.....
|
||
|
||
The primary issues that I think we need to discuss in terms of developing LC as a seamless plug-in to TCS <Name> elements are:
|
||
1. Vocabulary (i.e., we should try as much as possible to follow similar or identical element naming conventions).
|
||
* Main.JessieKennedy - 12 Nov 2004 agree
|
||
2. Publications: looking at TCS (if I understand it correctly) I am now leaning towards removing the "Publication" element of LC 0.1.4 from within "ProtonymCitation" (under "CanonicalAuthorship_Proposal2"), and instead adding a "ref" attribute to <nop>ProtonymCitation that points to a Publication record stored in the TCS "wrapper" of an LC instance.
|
||
3. Perhaps eliminate "Kingdom" element of TCS, and either replace with "NomenCode" (or similar);
|
||
* Main.JessieKennedy - 12 Nov 2004: would be happy with this or move this element to within the "Name" element (in the domain of LC.
|
||
* Main.JessieKennedy - 12 Nov 2004: not so happy - when taxonomists do a classification they need to say which rank they are working at before the appropriate name can be applied so I believe it first belongs in concept and then secondarily is associated to name - don't really think it needs to be in name if we accept that original concepts are really names with some extra info - so to get a name take a project view on the concept. Don't ask me yet to answer specific examples - we'll get there...
|
||
4. Make sure we understand the respective roles of "Rank" in TCS and LC, make sure they need to be separate (or decide how to combine them), and if maintained as separate, make sure they are cross-consistent.
|
||
* Main.JessieKennedy - 12 Nov 2004: agree
|
||
5. Resolve the Primary type specimen issue I discussed in the previous message (e.g., move type specimen elements from LC to <nop>SpecimenCircumscription, or prehaps create some sort of "TypeSpecimenCircumscription" element somewhere -- I don't know. As I said before, I see this as the only real potential point of contention.
|
||
* Main.JessieKennedy - 12 Nov 2004: agree but think that it is really just a perspective if you are a nomenclators then you see it as primarily as something to do with names, if you are a taxonomist you see it as a representative of the circumscription of the taxonomic concept, if you are a museum curator you probably see them in some other way altogether and we need to choose one that works for every one.
|
||
* Main.SallyHinchcliffe - 12 Nov 2004: on Rich's point 5 above, I have no problem with the type specimen information should remaining solely in the TCS, as the <nop>SpecimenCircumscription. We hadn't really got down to that bit of the schema yet - I think it's still in there from Jerry's original version of the LC. You could argue that it's part of the name, philosophically, but it's not needed for transmitting the name. I can't think of any case where we'd want to transmit some TCS data with one set of specimen circumscription data in it, wrapped around a LC element with another set of (type) specimens included in that.
|
||
|
||
---
|
||
|
||
Gregor - 12. Nov. 2004: Clearly the relation between TCS and LC should be discussed, and Richard's 5 points above are important. However, I believe the question what LC exactly is and whether it should fit completely into TCS or not is besides the point. Jerry did draw up a scope of LC and many - me included - responded with: "this looks like something I am looking for". Ultimately most points from Jerry's draft will end up _somewhere_. That includes stuff we already agreed to exclude from current LC discussion (e. g. Biostatus, Vernacular names)! Now, is it important to discuss exactly where they end up, and whether this should be called LC? We have started to develop types for <nop>CanonicalName and <nop>CanonicalAuthorship (and separating these I now, although initially against it, consider good progress!), we are trying to make progress on rank, and someone (which is not me in this case!) urgently needs to deal with those stupid hybrid and multihybrid and and named hybrid cases (please contribute to LinneanCoreHybridNothotaxa). We have not finished these steps - and I believe in relation to TCS they are uncontentious. We should *work* on this.
|
||
|
||
The next step is probably some structure to express nomenclatural scrutiny: Is a name illegitimate under ICBN, was it valididly published under ICBN, or whatever under ICZN, is it a nomen nudum, etc. I think TCS has not dealt with this at all so far. Then I personally am fervently in favor of being able to express nomenclatural relations like basionym or replaced-synonym separately from circumscription-concept relations (I try to avoid the overloaded term "concept" here - Jessie uses a different definition than I and what so far I thought Richard and Sally). From my perspective it appears to me important to "type" these relations and therefore prevent nonsense relationships like a derived circumscription concept becomes the basionym of a botanical name, which as far as I understand is quite possible under the generalized TCS "concept"-concept). Jessie will probably argue against that. However, I propose to view it like this: maybe LC trying to do it helps to "sort" (as Jessie requested help) the list of 40 TCS relations, some of which are homotypic, some heterotypic singular-point (type specimen) and some circumscription-related. This list is the core why for me TCS does not _seem_ work - simply because this list is mixed and the semantics and the syntax (which relation is applicable to which of the 5 concept-types on start and on end-point) are missing. _So let us get it sorted!_ If we sort it in LC and create some element names, maybe these names end up as heading or supertypes in the TCS relationship list. It would not bother me too much! -- Another way to express it: If some of us are unable to help TCS under the TCS definitions of what a "concept" and "nomenclature" is in TCS, perhaps by drawing up a schema that expresses our knowledge in terminology which some of us can easier relate to, we are able to express knowledge that TCS could then peruse (whatever that means in English :-) ).
|
||
|
||
Finally, at the moment I would like to have some way to express knowledge about type specimens - but indeed perhaps that works well in TCS after all. I cannot see into the future - I would need TCS examples under a revised TCS to get an opinion about this. Either it does work well in TCS or someone will extend LC (or any schema inheriting from LC!) to make it work in a different way. And the same applies to SDD. Simple. -- Gregor - 12. Nov. 2004 -- PS compare LinneanCoreTCSRelationshipTypes. - 19. Nov.
|
||
|
||
* Main.JessieKennedy - 15 Nov 2004: Thanks Gregor - it will be useful to look at the relationships more closely. Yes I will argue with you ;-) but not on the example you gave. Even if you had name objects with relationships between them there is nothing to stop someone putting the "is basionym of" relationship to the wrong name object -or if it was encoded as an attribute - to have the wrong attribute value in the data. I guess the only issue is that potentially there are more objects so a greater possibility to link to the wrong object. BUT, this is a transfer schema - if a nomenclator only has "concepts" which they consider to be names - then it is no different. Anyway who's going to re design their database - no-one I expect or not in a hurry. What people need to do is map their database to the transfer schema - so any relationships they have in their database will be representable in TCS.
|
||
|
||
* Main.RichardPyle -- 15 Nov 2004: I, for one, intend to make modifications to my database to accomodate whatever transfer schema is ratified. My only (very sincere) hope is that the "Name" element of TCS includes a much more robust set of elements for tracking name information (as a subset of concept information) than the draft presented at TDWG Christchurch does. Working on LC 0.1.5 now....
|
||
* Gregor: I am thinking about why I am so adverse to have so little guidance through typing of different concepts and relationship roles. As Jessie mentioned above, indeed I am not a nomenclator data provider - I am a consumer that wants to profit from (and share work with) the worthy nomenclator people. I want to accept automatic changes by a trusted source in a certain domain, but not every opinion this provider may issue. It is like a filter: trust these things automatically, consider those manually, ignore those. This is why I come to start analyzing the TCS relations and which knowledge they express. I run into problem with current TCS here. From my perspective having a few basic nomenclatural relations moved into LC would help me enourmously in analyzing this - but I am serious that perhaps the result may be just a better understanding of the relations and better documentation of the semantics of the relation codes. -- 17 Nov 2004 -- PS: As an example of confusion about relations: I don't understand how lecto/neotypification works in TCS if it is expressed as a relation between concepts. What does the name of the typification TCS-concept signify? Must there be "sensu" typification author attached to it, and is it this GUID that should from then on be used? If the original concept has been combined into a different Genus, and separately a typicification issued for it, is there also a relation between the new combination concept and the typification concept? Which one? These are consumer questions which I have to figure out, to be able to decide which TCS-GUID has to be added to my data. If I separate "type concepts" (= nomenclatural concept) and character circumscription concepts as different kind of concepts, they seem to disappear for me.
|