335 lines
26 KiB
Plaintext
335 lines
26 KiB
Plaintext
|
head 1.14;
|
||
|
|
access;
|
||
|
|
symbols;
|
||
|
|
locks; strict;
|
||
|
|
comment @# @;
|
||
|
|
|
||
|
|
|
||
|
|
1.14
|
||
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.13;
|
||
|
|
|
||
|
|
1.13
|
||
|
|
date 2004.11.29.14.08.45; author TrevorPaterson; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.12;
|
||
|
|
|
||
|
|
1.12
|
||
|
|
date 2004.11.12.20.31.07; author NozomiJamesYtow; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.11;
|
||
|
|
|
||
|
|
1.11
|
||
|
|
date 2004.11.12.17.21.53; author JessieKennedy; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.10;
|
||
|
|
|
||
|
|
1.10
|
||
|
|
date 2004.11.12.11.21.22; author JessieKennedy; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.9;
|
||
|
|
|
||
|
|
1.9
|
||
|
|
date 2004.11.08.17.53.00; author GregorHagedorn; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.8;
|
||
|
|
|
||
|
|
1.8
|
||
|
|
date 2004.11.08.16.52.27; author RichardPyle; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.7;
|
||
|
|
|
||
|
|
1.7
|
||
|
|
date 2004.11.02.10.37.45; author GregorHagedorn; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.6;
|
||
|
|
|
||
|
|
1.6
|
||
|
|
date 2004.11.02.07.59.57; author RichardPyle; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.5;
|
||
|
|
|
||
|
|
1.5
|
||
|
|
date 2004.11.01.15.04.42; author NozomiJamesYtow; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.4;
|
||
|
|
|
||
|
|
1.4
|
||
|
|
date 2004.11.01.09.21.55; author GregorHagedorn; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.3;
|
||
|
|
|
||
|
|
1.3
|
||
|
|
date 2004.11.01.07.51.15; author RichardPyle; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.2;
|
||
|
|
|
||
|
|
1.2
|
||
|
|
date 2004.10.31.20.23.20; author GregorHagedorn; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.1;
|
||
|
|
|
||
|
|
1.1
|
||
|
|
date 2004.10.31.07.18.00; author RichardPyle; state Exp;
|
||
|
|
branches;
|
||
|
|
next ;
|
||
|
|
|
||
|
|
|
||
|
|
desc
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.14
|
||
|
|
log
|
||
|
|
@Added topic name via script
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@---+!! %TOPIC%
|
||
|
|
|
||
|
|
%META:TOPICINFO{author="TrevorPaterson" date="1101737325" format="1.0" version="1.13"}%
|
||
|
|
%META:TOPICPARENT{name="LinneanCore"}%
|
||
|
|
This page is for discussions of LC as a sub-set of TCS.
|
||
|
|
---
|
||
|
|
|
||
|
|
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
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3>LinneanCoreTCSDiscussion initiated by Jessie</h3>
|
||
|
|
<h3>Is LC separate from TCS?</h3>
|
||
|
|
The draft TCS schema includes a "Nomenclatural" (="Nominal") type of concept that has no <nop>AccordingTo publication, and is intended as an "empty" Concept wrapper around a Name. Basically, this allows there to be a name-only TCS instance that does not imply any concept. The question is, should electronic transactions of Name-only data *always* be contained within a TCS "Nominal"-type Concept wrapper -- or should LC exist as a stand-alone schema that can be used outside the scope of a TCS wrapper?
|
||
|
|
* Gregor: Just a comment to express my confusion with TCS: Although the TCS concept type is called "Nomenclatural", as defined in the TCS documentation nomenclators providing nomenclatoral information can *not* use this type, since the type does not support the kind of information they normally intend to provide (or if they use the type, the consumer would not get the nomenclatural information, like original publication reference, basionym, type information, etc.). -- 31 Oct 2004
|
||
|
|
* Richard: Two points -- 1) I believe Jessie agreed that the term "Nomenclatural" to refer to this type of TCS instance was confusing, and I *think* they had planned to change it to "Nominal"; 2) After having a fairly clear and detailed conversation with Jessie at Christchurch, I came away with the strong impression that TCS instances of "Nominal"-type have a 1:1 relationship with whatever this group (LC) decides is it's instance unit. In other words, one and only one TCS "Nominal"-type instance will be created for each and every LC instance. Because LC is (will be) embedded within TCS, presenting each LC record as a TCS record involves nothing more than embedding it in a skeletal/minimal TCS wrapper -- with *NO* implied concept. I would assume that "Nominal" TCS records would be special-case records -- not attributed to any "AccordingTo" (sensu) publication, and never mapped to any other TCS concept record. -- 01 Nov 2004
|
||
|
|
* Gregor: "Nominal" is much better. I still think (I may be misreading TCS!) that further the restrictions on this "nominal" type to prevent it from expressing the information a nomenclator would want to serve (publication, basionym, type specimen information) would also have to be lifted. If so, my worries about wrapping LC in TCS go away. My concern is not wrapping, but forcing concept-logic and terminology on data providers. I see no problems though, if the concept logic is there, but well packaged and digestible. -- 01 Nov 2004
|
||
|
|
* Richard: There are no TCS restrictions for expressing information on publication, basionym, type specimen information, etc., as long as these elements are all defined within LC. LC would be included in its entirety within TCS (under the <nop>NamesDetail element of TCS, which now just has ABCD embedded). One of the goals of LC is to replace the ABCD "include" of TCS. So, put another way, whatever we definie within the context of LC will, presumably by definition, be available to every single TCS record (including the "Nominal"-type records). As I understand it, the "Nominal"-type TCS records would contain only LC elements, plus a skeleton wrapper.
|
||
|
|
* Gregor: No problems then - this implies a strong redesign of TCS though. I believe currently to express nomenclatural relations to basionym, homotypic type, lecto/neotype each part has to be encapsulated into a concept. -- 01 Nov 2004
|
||
|
|
* Richard: Do you mean "strong redesign of TCS" outside of its "Name" element? Or by "strong redesign of TCS" do you simply mean replacing the ABCD elements of "NameDetailed" with an LC structure? If the latter, I don't think there will be much argument from the TCS comminutiy -- as long as LC meets their basic needs (to the extent that ABCD names structure does), and as long as we are careful to keep concept information (that is replicated elsewhere in TCS) out of LC. -- 08 Nov 2004
|
||
|
|
* Gregor: If I go through the list nomenclatural relations that are treated as concept relations in TCS, my feeling is, it is the first. But we will see. -- 01 Nov 2004
|
||
|
|
* Jessie: ok some confusion I think... I believe LC should be included in TCS - not stand alone. The confusion as I see it is that LC will not be able to deal with all of the nomenclator's requirements i.e. whatever this group intends to replace the <Name> element in TCS with. Now I guess you could say "oh yes it will" - because you'll design it like that - but if you do and it can stand alone then TCS will need a complete re-design as we'll have missed the point of TCS. In New Zealand I spent time trying to show you how to represent names as concepts - nominal concepts. These were intended to allow people who want to identify specimens etc with a name but don't want to or are unable to say which concept it is - the problem we're told exists with lots of legacy data. Now the definition of concept in TCS as mentioned elsewhere in the wiki is the definition (i.e. circumscription in the widest sense of the meaning: character, specimen, relationship whatever it might comprise) plus the name - they are not separable. So a nomenclator would actually use concepts when talking about names(shock horror!!!), some of these - the original concepts - would have a definition as defined in the original publication so to treat it as a name the way they want to they would ignore some of the information. Others - such as a name changed because of gender or whatever might not have a definition but would relate to other concepts with nomenclatural relationships. I need some data to make some good examples here sorry.... hopefully our examples page will explain better when we get around to it... --Main.JessieKennedy - 12 Nov 2004 :
|
||
|
|
|
||
|
|
|
||
|
|
<h3>Shared Nomenclators</h3>
|
||
|
|
(from LinneanCoreDisentangle:) "Multiple concept synonymies can share a common nomenclator. I believe this is not possible with the proposed TCS. (Gregor)"
|
||
|
|
* Richard: I'm not sure what you mean by "not possible with the proposed TCS" -- what is not possible? One of the fundamental points this group needs to decided (and soon!) is whether LC exists only as a set of sub-elements within TCS, or whether it MUST stand separately. We all agree that there are many use cases where only names data (sans concept baggage) need to be passed around, but the question is, should those names data always be represented as "empty" (="nominal", = "nomenclatural") TCS concepts? I vote "yes" (for a number of reasons, which I will elaborate on later). - 29 Oct 2004
|
||
|
|
* Jessie: I agree with Richard (mostly ;-) ) If we agree on GUIDs etc. Then it is possible to pass around projection views on a concept and still treat them as the same - so you don't need to pass around everything..needs more exploration though. -- Main.JessieKennedy - 12 Nov 2004
|
||
|
|
* Gregor: I certainly may be wrong about the ability to solve this with TCS. I have a problem in that I cannot see how I can accept the reliable nomenclatural conclusions of a data set and add my own concept opinion on top of it. I am searching for a way to share the work in a way, that when the nomenclatural assessment by the nomenclator changes, I automatically accept this decision, without invalidating my concept circumscription and relationship opinion data. Can someone advocating TCS explain how to solve this, perhaps as a use case? It is somewhat clear to me that it can theoretically be solved, but the solution seems to be incredibly difficult. There are 40 (partly redundant) relationships (inappropriately called "nomenclatural": some are nomenclatural, some are concept relationships like "is not a synonym of", "is partial synonym of", "is pro parte synonym of", "is ambiregnal of", etc.). Relationships between different concept types have to be analyzed separately. Since the relations are directed, the 5 concept types result in 25 different combination on left/right side of a relationship, resulting in 25 * 40 = 1000 relationships that have to be analyzed! -- 30 Oct 2004
|
||
|
|
* Jessie: We never claimed we had the enumerated list of relationships sorted - we need help on this.... What we did was make a list of all the relationships that we've seen people use - this still needs sorted. Re tour example I can see some possible solutions but they mostly require a name/concept resolution server to solve your problem - not a job that will happen overnight. -- Main.JessieKennedy - 12 Nov 2004
|
||
|
|
* JMS: TCS can manage shared nomenclator theoretically in an indirect way, but inefficient, or, need to restrict semantics such as only original <nop>TaxonConcept allowed to have <nop>NameDetail. See also [[http://www.soc.napier.ac.uk/tdwg/index.php?pagename=RedundancyOfNameElementInTaxonConcept][Redundancy Of Name Element In Taxon Concept]]. -- 01 Nov 2004
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.13
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.12
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="NozomiJamesYtow" date="1100291467" format="1.0" version="1.12"}%
|
||
|
|
d3 34
|
||
|
|
a36 22
|
||
|
|
This page is for discussions of LC as a sub-set of TCS.
|
||
|
|
|
||
|
|
<h3>LinneanCoreTCSDiscussion initiated by Jessie</h3>
|
||
|
|
<h3>Is LC separate from TCS?</h3>
|
||
|
|
The draft TCS schema includes a "Nomenclatural" (="Nominal") type of concept that has no <nop>AccordingTo publication, and is intended as an "empty" Concept wrapper around a Name. Basically, this allows there to be a name-only TCS instance that does not imply any concept. The question is, should electronic transactions of Name-only data *always* be contained within a TCS "Nominal"-type Concept wrapper -- or should LC exist as a stand-alone schema that can be used outside the scope of a TCS wrapper?
|
||
|
|
* Gregor: Just a comment to express my confusion with TCS: Although the TCS concept type is called "Nomenclatural", as defined in the TCS documentation nomenclators providing nomenclatoral information can *not* use this type, since the type does not support the kind of information they normally intend to provide (or if they use the type, the consumer would not get the nomenclatural information, like original publication reference, basionym, type information, etc.). -- 31 Oct 2004
|
||
|
|
* Richard: Two points -- 1) I believe Jessie agreed that the term "Nomenclatural" to refer to this type of TCS instance was confusing, and I *think* they had planned to change it to "Nominal"; 2) After having a fairly clear and detailed conversation with Jessie at Christchurch, I came away with the strong impression that TCS instances of "Nominal"-type have a 1:1 relationship with whatever this group (LC) decides is it's instance unit. In other words, one and only one TCS "Nominal"-type instance will be created for each and every LC instance. Because LC is (will be) embedded within TCS, presenting each LC record as a TCS record involves nothing more than embedding it in a skeletal/minimal TCS wrapper -- with *NO* implied concept. I would assume that "Nominal" TCS records would be special-case records -- not attributed to any "AccordingTo" (sensu) publication, and never mapped to any other TCS concept record. -- 01 Nov 2004
|
||
|
|
* Gregor: "Nominal" is much better. I still think (I may be misreading TCS!) that further the restrictions on this "nominal" type to prevent it from expressing the information a nomenclator would want to serve (publication, basionym, type specimen information) would also have to be lifted. If so, my worries about wrapping LC in TCS go away. My concern is not wrapping, but forcing concept-logic and terminology on data providers. I see no problems though, if the concept logic is there, but well packaged and digestible. -- 01 Nov 2004
|
||
|
|
* Richard: There are no TCS restrictions for expressing information on publication, basionym, type specimen information, etc., as long as these elements are all defined within LC. LC would be included in its entirety within TCS (under the <nop>NamesDetail element of TCS, which now just has ABCD embedded). One of the goals of LC is to replace the ABCD "include" of TCS. So, put another way, whatever we definie within the context of LC will, presumably by definition, be available to every single TCS record (including the "Nominal"-type records). As I understand it, the "Nominal"-type TCS records would contain only LC elements, plus a skeleton wrapper.
|
||
|
|
* Gregor: No problems then - this implies a strong redesign of TCS though. I believe currently to express nomenclatural relations to basionym, homotypic type, lecto/neotype each part has to be encapsulated into a concept. -- 01 Nov 2004
|
||
|
|
* Richard: Do you mean "strong redesign of TCS" outside of its "Name" element? Or by "strong redesign of TCS" do you simply mean replacing the ABCD elements of "NameDetailed" with an LC structure? If the latter, I don't think there will be much argument from the TCS comminutiy -- as long as LC meets their basic needs (to the extent that ABCD names structure does), and as long as we are careful to keep concept information (that is replicated elsewhere in TCS) out of LC. -- 08 Nov 2004
|
||
|
|
* Gregor: If I go through the list nomenclatural relations that are treated as concept relations in TCS, my feeling is, it is the first. But we will see. -- 01 Nov 2004
|
||
|
|
* Jessie: ok some confusion I think... I believe LC should be included in TCS - not stand alone. The confusion as I see it is that LC will not be able to deal with all of the nomenclator's requirements i.e. whatever this group intends to replace the <Name> element in TCS with. Now I guess you could say "oh yes it will" - because you'll design it like that - but if you do and it can stand alone then TCS will need a complete re-design as we'll have missed the point of TCS. In New Zealand I spent time trying to show you how to represent names as concepts - nominal concepts. These were intended to allow people who want to identify specimens etc with a name but don't want to or are unable to say which concept it is - the problem we're told exists with lots of legacy data. Now the definition of concept in TCS as mentioned elsewhere in the wiki is the definition (i.e. circumscription in the widest sense of the meaning: character, specimen, relationship whatever it might comprise) plus the name - they are not separable. So a nomenclator would actually use concepts when talking about names(shock horror!!!), some of these - the original concepts - would have a definition as defined in the original publication so to treat it as a name the way they want to they would ignore some of the information. Others - such as a name changed because of gender or whatever might not have a definition but would relate to other concepts with nomenclatural relationships. I need some data to make some good examples here sorry.... hopefully our examples page will explain better when we get around to it... --Main.JessieKennedy - 12 Nov 2004 :
|
||
|
|
|
||
|
|
|
||
|
|
<h3>Shared Nomenclators</h3>
|
||
|
|
(from LinneanCoreDisentangle:) "Multiple concept synonymies can share a common nomenclator. I believe this is not possible with the proposed TCS. (Gregor)"
|
||
|
|
* Richard: I'm not sure what you mean by "not possible with the proposed TCS" -- what is not possible? One of the fundamental points this group needs to decided (and soon!) is whether LC exists only as a set of sub-elements within TCS, or whether it MUST stand separately. We all agree that there are many use cases where only names data (sans concept baggage) need to be passed around, but the question is, should those names data always be represented as "empty" (="nominal", = "nomenclatural") TCS concepts? I vote "yes" (for a number of reasons, which I will elaborate on later). - 29 Oct 2004
|
||
|
|
* Jessie: I agree with Richard (mostly ;-) ) If we agree on GUIDs etc. Then it is possible to pass around projection views on a concept and still treat them as the same - so you don't need to pass around everything..needs more exploration though. -- Main.JessieKennedy - 12 Nov 2004
|
||
|
|
* Gregor: I certainly may be wrong about the ability to solve this with TCS. I have a problem in that I cannot see how I can accept the reliable nomenclatural conclusions of a data set and add my own concept opinion on top of it. I am searching for a way to share the work in a way, that when the nomenclatural assessment by the nomenclator changes, I automatically accept this decision, without invalidating my concept circumscription and relationship opinion data. Can someone advocating TCS explain how to solve this, perhaps as a use case? It is somewhat clear to me that it can theoretically be solved, but the solution seems to be incredibly difficult. There are 40 (partly redundant) relationships (inappropriately called "nomenclatural": some are nomenclatural, some are concept relationships like "is not a synonym of", "is partial synonym of", "is pro parte synonym of", "is ambiregnal of", etc.). Relationships between different concept types have to be analyzed separately. Since the relations are directed, the 5 concept types result in 25 different combination on left/right side of a relationship, resulting in 25 * 40 = 1000 relationships that have to be analyzed! -- 30 Oct 2004
|
||
|
|
* Jessie: We never claimed we had the enumerated list of relationships sorted - we need help on this.... What we did was make a list of all the relationships that we've seen people use - this still needs sorted. Re tour example I can see some possible solutions but they mostly require a name/concept resolution server to solve your problem - not a job that will happen overnight. -- Main.JessieKennedy - 12 Nov 2004
|
||
|
|
* JMS: TCS can manage shared nomenclator theoretically in an indirect way, but inefficient, or, need to restrict semantics such as only original <nop>TaxonConcept allowed to have <nop>NameDetail. See also [[http://www.soc.napier.ac.uk/tdwg/index.php?pagename=RedundancyOfNameElementInTaxonConcept][Redundancy Of Name Element In Taxon Concept]]. -- 01 Nov 2004
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.11
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="JessieKennedy" date="1100280113" format="1.0" version="1.11"}%
|
||
|
|
d15 1
|
||
|
|
a16 2
|
||
|
|
-- Main.JessieKennedy - 12 Nov 2004 :
|
||
|
|
ok some confusion I think... I believe LC should be included in TCS - not stand alone. The confusion as I see it is that LC will not be able to deal with all of the nomenclator's requirements i.e. whatever this group intends to replace the <Name> element in TCS with. Now I guess you could say "oh yes it will" - because you'll design it like that - but if you do and it can stand alone then TCS will need a complete re-design as we'll have missed the point of TCS. In New Zealand I spent time trying to show you how to represent names as concepts - nominal concepts. These were intended to allow people who want to identify specimens etc with a name but don't want to or are unable to say which concept it is - the problem we're told exists with lots of legacy data. Now the definition of concept in TCS as mentioned elsewhere in the wiki is the definition (i.e. circumscription in the widest sense of the meaning: character, specimen, relationship whatever it might comprise) plus the name - they are not separable. So a nomenclator would actually use concepts when talking about names(shock horror!!!), some of these - the original concepts - would have a definition as defined in the original publication so to treat it as a name the way they want to they would ignore some of the information. Others - such as a name changed because of gender or whatever might not have a definition but would relate to other concepts with nomenclatural relationships. I need some data to make some good examples here sorry.... hopefully our examples page will explain better when we get around to it...
|
||
|
|
d21 1
|
||
|
|
a21 3
|
||
|
|
-- Main.JessieKennedy - 12 Nov 2004
|
||
|
|
I agree with Richard (mostly ;-) ) If we agree on GUIDs etc. Then it is possible to pass around projection views on a concept and still treat them as the same - so you don't need to pass around everything..needs more exploration though.
|
||
|
|
|
||
|
|
d23 1
|
||
|
|
a23 3
|
||
|
|
-- Main.JessieKennedy - 12 Nov 2004
|
||
|
|
We never claimed we had the enumerated list of relationships sorted - we need help on this.... What we did was make a list of all the relationships that we've seen people use - this still needs sorted. Re tour example I can see some possible solutions but they mostly require a name/concept resolution server to solve your problem - not a job that will happen overnight.
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.10
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="JessieKennedy" date="1100258482" format="1.0" version="1.10"}%
|
||
|
|
d16 2
|
||
|
|
d22 3
|
||
|
|
d26 3
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.9
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1099936380" format="1.0" version="1.9"}%
|
||
|
|
d5 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.8
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="RichardPyle" date="1099932747" format="1.0" version="1.8"}%
|
||
|
|
d13 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.7
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1099391865" format="1.0" version="1.7"}%
|
||
|
|
d12 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.6
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="RichardPyle" date="1099382397" format="1.0" version="1.6"}%
|
||
|
|
d11 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.5
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="NozomiJamesYtow" date="1099321482" format="1.0" version="1.5"}%
|
||
|
|
d8 1
|
||
|
|
a8 1
|
||
|
|
* Richard: Two points -- 1) I believe Jessie agreed that the term "Nomenclatural" to refer to this type of TCS instance was confusing, and I *think* they had planned to change it to "Nominal"; 2) After having a fairly clear and detailed conversation with Jessie at Christchurch, I came away with the strong impression that TCS instances of "Nominal"-type have a 1:1 relationship with whatever this group (LC) decides is it's instance unit. In other words, one and only one TCS "Nominal"-type instance will be created for each and every LC instance. Because LC is (will be) embedded within TCS, presenting each LC record as a TCS record involves nothing more that embedding it in a skeletal/minimal TCS wrapper -- with *NO* implied concept. I would assume that "Nominal" TCS records would be special-case records -- not attributed to any "AccordingTo" (sensu) publication, and never mapped to any other TCS concept record. -- 01 Nov 2004
|
||
|
|
d10 1
|
||
|
|
d16 1
|
||
|
|
a16 2
|
||
|
|
* JMS: TCS can manage shared nomenclator theoretically in an indirect way, but inefficient, or, need to restrict semantics such as only original <nop>TaxonConcept allowed to have <nop>NameDetail. See also [[http://www.soc.napier.ac.uk/tdwg/index.php?pagename=RedundancyOfNameElementInTaxonConcept][Redundancy Of Name Element In Taxon Concept]]. -- 01 Nov 2004
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.4
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1099300915" format="1.0" version="1.4"}%
|
||
|
|
d15 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.3
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="RichardPyle" date="1099295475" format="1.0" version="1.3"}%
|
||
|
|
d8 2
|
||
|
|
a9 1
|
||
|
|
* Richard: Two points -- 1) I believe Jessie agreed that the term "Nomenclatural" to refer to this type of TCS instance was confusing, and I *think* they had planned to change it to "Nominal"; 2) After having a fairly clear and detailed conversation with Jessie at Christchurch, I came away with the strong impression that TCS instances of "Nominal"-type have a 1:1 relationship with whatever this group (LC) decides is it's instance unit. In other words, one and only one TCS "Nominal"-type instance will be created for each and every LC instance. Because LC is (will be) embedded within TCS, presenting each LC record as a TCS record involves nothing more that embedding it in a skeletal/minimal TCS wrapper -- with *NO* implied concept. I would assume that "Nominal" TCS records would be special-case records -- not attributed to any "AccordingTo" (sensu) publication, and never mapped to any other TCS concept record. -- 01 Nov 2004
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.2
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1099254200" format="1.0" version="1.2"}%
|
||
|
|
d8 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.1
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="RichardPyle" date="1099207080" format="1.0" version="1.1"}%
|
||
|
|
d7 1
|
||
|
|
d10 1
|
||
|
|
a10 2
|
||
|
|
(from LinneanCoreDisentangle)
|
||
|
|
Multiple concept synonymies can share a common nomenclator. I believe this is not possible with the proposed TCS. (Gregor)
|
||
|
|
d12 1
|
||
|
|
a12 1
|
||
|
|
* Gregor: I certainly may be wrong about the ability to solve this with TCS. I have a problem in that I cannot see how I can reliably (and without doing an analysis of dozens of concept relations multiplied by the different concept types either side of the relation may have) accept the reliable nomenclatural conclusions of a data set and add my own concept opinion on top of it. I am searching for a way to share the work in a way, that when the nomenclatural assessment by the nomenclator changes, I automatically accept this decision, without invalidating my concept circumscription and relationship opinion data. Can someone advocating TCS explain how to solve this, perhaps as a use case? - 30 Oct 2004
|
||
|
|
@
|