head 1.9; access; symbols; locks; comment @# @; 1.9 date 2007.03.06.17.30.00; author TWikiGuest; state Exp; branches; next 1.8; 1.8 date 2006.05.04.11.26.30; author GregorHagedorn; state Exp; branches; next 1.7; 1.7 date 2004.06.21.11.30.01; author GregorHagedorn; state Exp; branches; next 1.6; 1.6 date 2004.05.28.17.09.00; author GregorHagedorn; state Exp; branches; next 1.5; 1.5 date 2003.11.24.10.55.07; author GregorHagedorn; state Exp; branches; next 1.4; 1.4 date 2003.09.26.11.32.29; author BobMorris; state Exp; branches; next 1.3; 1.3 date 2003.09.26.05.03.00; author BobMorris; state Exp; branches; next 1.2; 1.2 date 2003.09.25.20.11.59; author KevinThiele; state Exp; branches; next 1.1; 1.1 date 2003.09.25.18.19.51; author BobMorris; state Exp; branches; next ; desc @none @ 1.9 log @Added topic name via script @ text @---+!! %TOPIC% %META:TOPICINFO{author="GregorHagedorn" date="1146741990" format="1.0" version="1.8"}% %META:TOPICPARENT{name="ClosedTopicSchemaDiscussionSDD09"}% Main.KevinThiele 25 Sep 2003: we currently have: Viola hederacea Labill Viola someothercea Labill What's meant by FreeFormDescription? We need to split the epithet and author in the name e.g. Viola hederacea Labill. ....etc is better? --- Main.BobMorris - 26 Sep 2003: Ah, this arises from our desire to recognize that (a)Resources of all kinds may often have external definitions (e.g. for a TaxonName, it might be a URI designating an authority for the name) and (b)when elments have a lot of commonality, they should be required to be declared as being of a named datatype. In this case the draft Schema calls for TaxonName, Specimen, Publication, and maybe others TBD, to be of type ResourceConnectorType, which is a datatype that provides for two kinds of external reference (details irrelevant for this discussion) and a bit of text meant mainly to be passed on to humans. That's the text enclosed in the tag FreeFormText. The tag name is chosen to be mnemonic I think. However, your point is that a TaxonName deserves more structure--and maybe even should make the FreeFormText either optional or prohibited, requiring instead more structure to the name. This can be done pretty easily by making a type derived from ResourceConnectorType in a way that would support your alternative. I'll modify my guerrilla-action Schema to do that and edit this page when done. As you observed below, it remains for bioligists to discuss---perhaps after the Lisbon Taxonomic Names session---exactly what should be the structure of a TaxonomicName. --- Main.KevinThiele 25 Sep 2003: We will need to conform with TDWG Taxon Names eventually, but they will surely have something like this. I've used <Taxa> and <Taxon> rather than <TaxonNames> and <TaxonName> because surely we will later add further resources to the taxa, and name is only one part. Having <Taxon> as a child of <Resources> and <Taxon> also as a child of <Descriptions> won't cause problems, will it? --- Main.BobMorris - 26 Sep 2003: No it won't. _But_ the idea here is that a _TaxonName_ is a resource to be used elsewhere---perhaps in many places---whereas a Taxon is one of the things that can be described. So while it won't make any difference to a parser examining an instance document, it could confuse any discussion that omits the context. This is a general ProblemOfResolvingIdentifiers which in my opinion is best sidestepped by using two different identifiers in this case. BTW, I doubt we do (can?) enforce in the Descrptions section, that there is at most one Taxon referring to any given TaxonName (i.e. loosely, only one description of any given Taxon). If that's right, we need a specification of which one counts or discuss whether it's OK. --- Main.KevinThiele 25 Sep 2003: Also, is it sensible for the taxon list to be part of <Resources> but the characters list to be part of <Terminology>. It seems to me that they are pretty equivalent things. Maybe we should have 4 base elements * - the character list * - the taxon list * -the descriptions * - associated resources e.g. images, references etc. That way, <Resources> can be optional but <Taxa> required - clearly, it's important to be able to query a project for its taxon list. --- Main.BobMorris - 26 Sep 2003: Well, that might be OK if Taxa were the only things ever described. But we intend others, such as Specimens. Now, aside from the "minor" elements like ProjectDefinition, the current situation is only _three_ things: * - which includes both what you are here calling Features and Taxa * * (Here you mean Taxa you mean TaxonNames ...) But Terminology includes much more than just TaxonNames. Notably it presently includes ModifierDefinitions and a few other global things involved in the specification of states. --- Main.BobMorris - 26 Sep 2003: Hey wait a minute. Just when I thought that after all these years I'd finally understood the difference between a Taxon and a Taxon name, now you are confusing me again... --- %META:TOPICMOVED{by="GregorHagedorn" date="1085765904" from="SDD.TaxonNamesInResources" to="SDD.ClosedTopicTaxonNamesInResources"}% @ 1.8 log @none @ text @d1 2 @ 1.7 log @none @ text @d1 65 a65 64 %META:TOPICINFO{author="GregorHagedorn" date="1087817401" format="1.0" version="1.7"}% %META:TOPICPARENT{name="SchemaDiscussionSDD09"}% Main.KevinThiele 25 Sep 2003: we currently have: Viola hederacea Labill Viola someothercea Labill What's meant by FreeFormDescription? We need to split the epithet and author in the name e.g. Viola hederacea Labill. ....etc is better? --- Main.BobMorris - 26 Sep 2003: Ah, this arises from our desire to recognize that (a)Resources of all kinds may often have external definitions (e.g. for a TaxonName, it might be a URI designating an authority for the name) and (b)when elments have a lot of commonality, they should be required to be declared as being of a named datatype. In this case the draft Schema calls for TaxonName, Specimen, Publication, and maybe others TBD, to be of type ResourceConnectorType, which is a datatype that provides for two kinds of external reference (details irrelevant for this discussion) and a bit of text meant mainly to be passed on to humans. That's the text enclosed in the tag FreeFormText. The tag name is chosen to be mnemonic I think. However, your point is that a TaxonName deserves more structure--and maybe even should make the FreeFormText either optional or prohibited, requiring instead more structure to the name. This can be done pretty easily by making a type derived from ResourceConnectorType in a way that would support your alternative. I'll modify my guerrilla-action Schema to do that and edit this page when done. As you observed below, it remains for bioligists to discuss---perhaps after the Lisbon Taxonomic Names session---exactly what should be the structure of a TaxonomicName. --- Main.KevinThiele 25 Sep 2003: We will need to conform with TDWG Taxon Names eventually, but they will surely have something like this. I've used <Taxa> and <Taxon> rather than <TaxonNames> and <TaxonName> because surely we will later add further resources to the taxa, and name is only one part. Having <Taxon> as a child of <Resources> and <Taxon> also as a child of <Descriptions> won't cause problems, will it? --- Main.BobMorris - 26 Sep 2003: No it won't. _But_ the idea here is that a _TaxonName_ is a resource to be used elsewhere---perhaps in many places---whereas a Taxon is one of the things that can be described. So while it won't make any difference to a parser examining an instance document, it could confuse any discussion that omits the context. This is a general ProblemOfResolvingIdentifiers which in my opinion is best sidestepped by using two different identifiers in this case. BTW, I doubt we do (can?) enforce in the Descrptions section, that there is at most one Taxon referring to any given TaxonName (i.e. loosely, only one description of any given Taxon). If that's right, we need a specification of which one counts or discuss whether it's OK. --- Main.KevinThiele 25 Sep 2003: Also, is it sensible for the taxon list to be part of <Resources> but the characters list to be part of <Terminology>. It seems to me that they are pretty equivalent things. Maybe we should have 4 base elements * - the character list * - the taxon list * -the descriptions * - associated resources e.g. images, references etc. That way, <Resources> can be optional but <Taxa> required - clearly, it's important to be able to query a project for its taxon list. --- Main.BobMorris - 26 Sep 2003: Well, that might be OK if Taxa were the only things ever described. But we intend others, such as Specimens. Now, aside from the "minor" elements like ProjectDefinition, the current situation is only _three_ things: * - which includes both what you are here calling Features and Taxa * * (Here you mean Taxa you mean TaxonNames ...) But Terminology includes much more than just TaxonNames. Notably it presently includes ModifierDefinitions and a few other global things involved in the specification of states. --- Main.BobMorris - 26 Sep 2003: Hey wait a minute. Just when I thought that after all these years I'd finally understood the difference between a Taxon and a Taxon name, now you are confusing me again... --- @ 1.6 log @none @ text @d1 2 a2 2 %META:TOPICINFO{author="GregorHagedorn" date="1085764140" format="1.0" version="1.6"}% %META:TOPICPARENT{name="SchemaDiscussion"}% @ 1.5 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1069671307" format="1.0" version="1.5"}% d32 1 a32 1 However, your point is that a TaxonName deserves more structure--and maybe even should make the FreeFormText either optional or prohibited, requiring instead more structure to the name. This can be done pretty easily by making a type derived from ResourceConnectorType in a way that would support your alternative. I'll modify my guerrilla-action Schema to do that and edit this page when done. As you observed below, it remains for bioligists to discuss---perhaps after the Lisbon Taxonomic Names session---exactly what should be the structure of a TaxonomicName. Such discussion could take place at WhatIsTheStructureOfATaxonomicName. d65 1 @ 1.4 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="BobMorris" date="1064575949" format="1.0" version="1.4"}% a60 1 So I would rephrase your question as not whether to break out TaxonName, but rather ShouldTaxonNamesBeInTerminologyInsteadOfResources. @ 1.3 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="BobMorris" date="1064552580" format="1.0" version="1.3"}% d39 3 a41 1 Main.BobMorris - 26 Sep 2003: No it won't. _But_ the idea here is that a _TaxonName_ is a resource to be used elsewhere---perhaps in many places---whereas a Taxon is one of the things that can be described. BTW, I doubt we do (can?) enforce in the Descrptions section, that there is at most one Taxon referring to any given TaxonName (i.e. loosely, only one description of any given Taxon). If that's right, we need a specification of which one counts or discuss whether it's OK. d52 11 @ 1.2 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="KevinThiele" date="1064520719" format="1.0" version="1.2"}% d3 1 a3 1 we currently have: d29 6 a34 2 We will need to conform with TDWG Taxon Names eventually, but they will surely have something like this. d38 4 a41 2 Also, is it sensible for the taxon list to be part of <Resources> but the characters list to be part of <Terminology>. It seems to me that they are pretty equivalent things. Maybe we should have 4 base elements d49 2 a50 1 d52 1 a52 1 -- Main.KevinThiele - 25 Sep 2003 @ 1.1 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="BobMorris" date="1064513991" format="1.0" version="1.1"}% d16 1 a16 1 What's meant by FreeFormDescription? We need to split the epithet and author in the name e.g. d31 1 a31 1 I've used and rather than and because surely we will later add further resources to the taxa, and name is only one part. d33 1 a33 1 Having as a child of and also as a child of won't cause problems, will it? d35 1 a35 1 Also, is it sensible for the taxon list to be part of but the characters list to be part of . It seems to me that they are pretty equivalent things. Maybe we should have 4 base elements d37 4 a40 4 - the character list - the taxon list -the descriptions - associated resources e.g. images, references etc. d42 1 a42 1 That way, can be optional but required - clearly, it's important to be able to query a project for its taxon list. @