wiki-archive/twiki/data/tmp/SDD/ClosedTopicTaxonNamesInResources.txt,v

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:
 <verbatim>
 <Resources>
  <TaxonNames>
	<TaxonName key="Viola_hederacea">
	 <FreeFormDescription>Viola hederacea Labill</FreeFormDescription>
	</TaxonName>
	<TaxonName key="Viola_someothercea">
	 <FreeFormDescription>Viola someothercea Labill</FreeFormDescription>
	</TaxonName>
  </TaxonNames>
 </Resources>
 </verbatim>
What's meant by <nop>FreeFormDescription? We need to split the epithet and author in the name e.g.
 <verbatim>
<Resources>
 <Taxa>
  <Taxon key="Viola_hederacea">
	<TaxonName>Viola hederacea</Name>
	<TaxonAuthor>Labill.</TaxonAuthor>
  </Taxon>
  ....etc
 </Taxa>
</Resources>
 </verbatim>
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 <nop>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 <nop>TaxonName, Specimen, Publication, and maybe others TBD, to be of type <nop>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 <nop>FreeFormText. The tag name is chosen to be mnemonic I think.

However, your point is that a <nop>TaxonName deserves more structure--and maybe even should make the <nop>FreeFormText either optional or prohibited, requiring instead more structure to the name. This can be done pretty easily by making a type derived from <nop>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 <nop>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 &lt;Taxa&gt; and &lt;Taxon&gt; rather than &lt;TaxonNames&gt; and &lt;TaxonName&gt; because surely we will later add further resources to the taxa, and name is only one part.
 
Having &lt;Taxon&gt; as a child of &lt;Resources&gt; and &lt;Taxon&gt; also as a child of &lt;Descriptions&gt; won't cause problems, will it?
---
Main.BobMorris - 26 Sep 2003: No it won't. _But_ the idea here is that a _<nop>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 <nop>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 &lt;Resources&gt; but the characters list to be part of &lt;Terminology&gt;. It seems to me that they are pretty equivalent things. Maybe we should have 4 base elements
<verbatim>
	* <Features> - the character list
	* <Taxa> - the taxon list
	* <Descriptions> -the descriptions
	* <Resources> - associated resources e.g. images, references etc.
</verbatim>
That way, &lt;Resources&gt; can be optional but &lt;Taxa&gt; 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 <nop>ProjectDefinition, the current situation is only _three_ things:
<verbatim>
	* <Terminology> - which includes both what you are here calling Features and Taxa
	* <Descriptions>
	* <Resources>
</verbatim>
(Here you mean Taxa you mean <nop>TaxonNames ...)
But Terminology includes much more than just <nop>TaxonNames. Notably it presently includes <nop>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:
 <verbatim>
 <Resources>
  <TaxonNames>
	<TaxonName key="Viola_hederacea">
	 <FreeFormDescription>Viola hederacea Labill</FreeFormDescription>
	</TaxonName>
	<TaxonName key="Viola_someothercea">
	 <FreeFormDescription>Viola someothercea Labill</FreeFormDescription>
	</TaxonName>
  </TaxonNames>
 </Resources>
 </verbatim>
What's meant by <nop>FreeFormDescription? We need to split the epithet and author in the name e.g.
 <verbatim>
<Resources>
 <Taxa>
  <Taxon key="Viola_hederacea">
	<TaxonName>Viola hederacea</Name>
	<TaxonAuthor>Labill.</TaxonAuthor>
  </Taxon>
  ....etc
 </Taxa>
</Resources>
 </verbatim>
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 <nop>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 <nop>TaxonName, Specimen, Publication, and maybe others TBD, to be of type <nop>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 <nop>FreeFormText. The tag name is chosen to be mnemonic I think.

However, your point is that a <nop>TaxonName deserves more structure--and maybe even should make the <nop>FreeFormText either optional or prohibited, requiring instead more structure to the name. This can be done pretty easily by making a type derived from <nop>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 <nop>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 &lt;Taxa&gt; and &lt;Taxon&gt; rather than &lt;TaxonNames&gt; and &lt;TaxonName&gt; because surely we will later add further resources to the taxa, and name is only one part.
 
Having &lt;Taxon&gt; as a child of &lt;Resources&gt; and &lt;Taxon&gt; also as a child of &lt;Descriptions&gt; won't cause problems, will it?
---
Main.BobMorris - 26 Sep 2003: No it won't. _But_ the idea here is that a _<nop>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 <nop>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 &lt;Resources&gt; but the characters list to be part of &lt;Terminology&gt;. It seems to me that they are pretty equivalent things. Maybe we should have 4 base elements
<verbatim>
	* <Features> - the character list
	* <Taxa> - the taxon list
	* <Descriptions> -the descriptions
	* <Resources> - associated resources e.g. images, references etc.
</verbatim>
That way, &lt;Resources&gt; can be optional but &lt;Taxa&gt; 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 <nop>ProjectDefinition, the current situation is only _three_ things:
<verbatim>
	* <Terminology> - which includes both what you are here calling Features and Taxa
	* <Descriptions>
	* <Resources>
</verbatim>
(Here you mean Taxa you mean <nop>TaxonNames ...)
But Terminology includes much more than just <nop>TaxonNames. Notably it presently includes <nop>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 <nop>TaxonName deserves more structure--and maybe even should make the <nop>FreeFormText either optional or prohibited, requiring instead more structure to the name. This can be done pretty easily by making a type derived from <nop>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 <nop>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 <nop>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 _<nop>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 <nop>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 &lt;Resources&gt; but the characters list to be part of &lt;Terminology&gt;. 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 <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.
d33 1
a33 1
Having <Taxon> as a child of <Resources> and <Taxon> also as a child of <Descriptions> won't cause problems, will it?
d35 1
a35 1
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
d37 4
a40 4
<Features> - the character list
<Taxa> - the taxon list
<Descriptions> -the descriptions
<Resources> - associated resources e.g. images, references etc.
d42 1
a42 1
That way, <Resources> can be optional but <Taxa> required - clearly, it's important to be able to query a project for its taxon list.
@