- tdwg-content - lists.tdwg.org

Re: Report; correction
by Robert A. (Bob) Morris 27 Nov '00

27 Nov '00

Although I am the perpetrator of the mistake, UDDI does not stand for Universial Data Description Interface, but rather Universial Description, Discovery and Integration. See www.uddi.org. UDDI is not about describing data, but about how you can find out where and how to invoke services, e.g. databases, on the web. Designed originally for Business-to-Business service discovery, we are looking at it as a registry facility for biodiversity data sources. Bob

1 0

Report, please
by Kevin Thiele 21 Nov '00

21 Nov '00

Will someone who went to Frankfurt please report on the meeting and discussions re the SDD - Bob or Jim? - at your leisure

1 0

Re: Report, please
by Gregor Hagedorn 21 Nov '00

21 Nov '00

Hi Kevin, sorry, I am preparing a report, I will try to post it soon! Gregor > Will someone who went to Frankfurt please report on the meeting and > discussions re the SDD - Bob or Jim? - at your leisure > ---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn(a)bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 Often wrong but never in doubt!

1 0

Re: Delta-like descriptions for Thiele 0.3 draft
by Kevin Thiele 07 Nov '00

07 Nov '00

----- Original Message ----- From: Robert A. (Bob) Morris <ram(a)CS.UMB.EDU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Tuesday, November 07, 2000 5:15 AM Subject: Delta-like descriptions for Thiele 0.3 draft | Ah, Jun Wan reminds me that uniqueness of ID attribute values is | imposed by XML itself. So in the Delta-like descriptions, the choices | I see are to generate unique ID's that encode the context or to use a | different attribute than ID, perhaps something like TDWGID. In the | former case one might have something like: | ID="F.1" to mean that this is an id for feature 1 | ID="F.V.1.2" to mean that this is value 2 for feature 1 | In XSLT, these are parseable with the XPath string functions, so that | nothing more than XSLT is needed to associate an IDREF with the object | having the associated ID. This is a nuisance. TDWGID I think is not a likely candidate. Using your first option, one could use simply: ID="1" (id for feature 1) ID="1.2" (id for value 2 of feature 1) This may then perhaps even be handy. Then again, by constraining like this it would quickly become a nightmare to add or re-arrange features or values. Is this the first case where we're being imposed upon by XML and we start to wear the cost of its advantages? Are there any other ways out? Cheers - k

1 0

Re: Delta-like descriptions for Thiele 0.3 draft
by Kevin Thiele 07 Nov '00

07 Nov '00

Bob, | We think that Kevin's example 9 the <DESCRIPTION> is really meant to be | | <DESCRIPTION ID = "1"> | <FEATURE IDREF="1"> <VALUE IDREF="3"> | <FEATURE IDREF="2"> <VALUE IDREF="1"> | </DESCRIPTION> | | rather than | | <DESCRIPTION ID = "1"> | <FEATURE ID="1"> <VALUE ID="3"> | <FEATURE ID="2"> <VALUE ID="1"> | </DESCRIPTION> It should probably be: <DESCRIPTION IDREF = "1"> <FEATURE IDREF="1"> <VALUE IDREF="3"> <FEATURE IDREF="2"> <VALUE IDREF="1"> </DESCRIPTION> Since the description is also referring to a defined taxon ID. | II. Global feature values (This may be a Delta question). | | In 0.3's Examples 8 and 9 there do not seem to be any global feature | values. Instead, all possible values are completely local to | features. For example, can there be a list of feature values | containing both "present" and "absent" to which any feature can refer, | whether or not those values are in that feature's local list of | values? Or rather, must every feature that wishes to allow those | values name them in its list of possible values> I think all values should be specifically named. It would be silly to have a global "present", then have a feature "Flower colour" that allows this feature value. Cheers - k

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by unknown＠example.com 07 Nov '00

07 Nov '00

Thanks for the gentle reminder of where we are ultimately headed. I guess I'm expressing some disappointment relating to the "bicycle vs. space shuttle" problem discussed earlier. The BioLink team have put together quite a nice little bike and are now zoning around town having a great time. The SDD discussion seems to still be lying in a grassy field (or on the railroad tracks?) gazing at the stars and dreaming of space ships. We're not even close to putting together a single data model that works with even a single application, forget about sharing multiple data models across multiple applications. Yes, that will come and I understand the power of it, but let's get a system that can represent DELTA/Intkey and LucID data now, the data we currently hold and the applications we currently use. By all means we should keep dreaming and planning and exploring. And when new applications appear and want to share or extend our data then we share and extend it. It's the classic problem of deciding when to put down the pencil and paper and pick up the hammer and saw. We've been at this for a year now, it's time to get dirty. Thanks, Steve Shattuck P.S. - I'll give the DTD generator a try as soon as the current BioLink XML import finishes.

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by unknown＠example.com 07 Nov '00

07 Nov '00

> > <taxonomy> > > <rank="species" value="alfari"/> > > <rank="genus" value="Azteca"/> > > <author value="Emery"/> >What is referred to as "species" value="alfari"/ is actually the specific >epithet. The "species" value in this instance would actually be "Azteca >alfari" You're probably familiar with this protocol of referring to the >scientific name of an organism which implies citing the genus name & the >specific epithet which together comprise the species names - as per the >Linnean system of binomial nomenclature. Should I have the 'wrong end of the >stick' of the discourse at this stage then please advise me. Well, the above use to be true but not any more. The latest version of the Zoological Code drops all reference to "epithet" and now calls it the "specific name" (Article 5 and Glossary under "Name" - epithet doesn't even appear in the Index). More to the point, to be absolutely proper (under the current ICZN) the above would look like this: <taxonomy> <rank="species" specific_name="alfari"/> <rank="genus" generic_name="Azteca"/> <author value="Emery"/> But this would be a particularly unclever way of doing it. If you wanted to change it I would suggest de-generalising it a bit to: <taxonomy> <specific_name="alfari"/> <generic_name="Azteca"/> <author value="Emery"/> The rank element doesn't really contribute much since you'll need to parse the "value" attribute to figure out what's going. Might as well just get the text of the "specific_name" element directly rather than searching for the "rank" element that equals "species" and then getting the text of its "value" attribute. Yes, this change makes it more specific and less general (and is a bad thing in strict IT terms), but why make life harder than it has to be? This way of doing it might make it harder to develop a Schema definition, but I would argue strongly that the data model should come after we know what we want to do, not before (<soap_box_on> and that's partly why this discussion has drawn out for sooooo long - the BioLink team built a complete XML representation of the BioLink database, some 400 fields in 50 tables, in 3 weeks and are now using it to move data between BioLink databases and between Platypus and BioLink - and, surprise surprise, we don't have a DTD or Schema because you don't actually need one to make this stuff work <soap_box_off/>). If you need to add a subgenus to the name just add a new element: <taxonomy> <specific_name="alfari"/> <subgeneric_name="Alfaridris"/> <generic_name="Azteca"/> <author value="Emery"/> I don't think this would cause any more confusion during processing or parsing than: <taxonomy> <rank="species" value="alfari"/> <rank="subgenus" value="Alfaridris"/> <rank="genus" value="Azteca"/> <author value="Emery"/> If the software can't handle the first then it's unlikely to be able to do much with the second either. Yes, the Schema definition would be broken by the first method and not the second, but this is a secondary consideration to someone who wants to actually process this bit of pseudo-XML. If I don't know how to handle the element called "subgeneric_name" then I won't know how to handle a rank with a value of "subgenus" either. The point is that the application and the data are tightly integrated (more than we would like them to be) and if the two get out of synch things won't go smoothly. Yours in confusion, Steve Shattuck

1 0

Re: Delta-like descriptions for Thiele 0.3 draft
by don kirkup 07 Nov '00

07 Nov '00

from Kevin Thiele; > | Ah, Jun Wan reminds me that uniqueness of ID attribute values is > | imposed by XML itself. So in the Delta-like descriptions, the choices > | I see are to generate unique ID's that encode the context or to use a > | different attribute than ID, perhaps something like TDWGID. In the > | former case one might have something like: > | ID="F.1" to mean that this is an id for feature 1 > | ID="F.V.1.2" to mean that this is value 2 for feature 1 > | In XSLT, these are parseable with the XPath string functions, so that > | nothing more than XSLT is needed to associate an IDREF with the object > | having the associated ID. > > This is a nuisance. TDWGID I think is not a likely candidate. > > Using your first option, one could use simply: > ID="1" (id for feature 1) > ID="1.2" (id for value 2 of feature 1) > > This may then perhaps even be handy. Then again, by constraining like this > it would quickly become a nightmare to add or re-arrange features > or values. > > Is this the first case where we're being imposed upon by XML and > we start to > wear the cost of its advantages? Are there any other ways out? Rather than inserting 'ID' type elements within the XML, you could instead define <xsl:key> elements in a xsl stylesheet and then use the XPATH key() function to access the values. The key() function works in pretty much identical way as the XPATH id() function, but a key (unlike an id) doesn't need to be unique. don

1 0

Re: Delta-like descriptions for Thiele 0.3 draft
by Robert A. (Bob) Morris 07 Nov '00

07 Nov '00

Kevin Thiele writes: > Date: Tue, 7 Nov 2000 22:14:33 +1100 > Bob Morris wrote: > > | II. Global feature values (This may be a Delta question). > | > | In 0.3's Examples 8 and 9 there do not seem to be any global feature > | values. Instead, all possible values are completely local to > | features. For example, can there be a list of feature values > | containing both "present" and "absent" to which any feature can refer, > | whether or not those values are in that feature's local list of > | values? Or rather, must every feature that wishes to allow those > | values name them in its list of possible values> > Kevin replied > I think all values should be specifically named. It would be silly to have a > global "present", then have a feature "Flower colour" that allows this > feature value. > Bob writes: Having global named values doesn't imply that an application *must* use them, only that it *may* use them. Also, this is one of those places where having a schema (= DTD or X Schema) can help because it is possible to define the schema in such a way that 'Flower colour present' would be prohibited. In this case a validating XML parser would signal exactly where the "error" lies, in case you care. But even better, an application that was built to the schema but did not enforce the schema would just ignore the silly statement.

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by Jim Croft 07 Nov '00

07 Nov '00

Leszeck wrote: >What is referred to as "species" value="alfari"/ is actually the specific >epithet. The "species" value in this instance would actually be "Azteca >alfari" You're probably familiar with this protocol of referring to the >scientific name of an organism which implies citing the genus name & the >specific epithet which together comprise the species names - as per the >Linnean system of binomial nomenclature. Should I have the 'wrong end of the >stick' of the discourse at this stage then please advise me. Isn't this merely a matter of how we look at things and the insoluble legacy of the Linnean system? Conceptually one of way of dealing dealing with things is to consider we are dealing with taxa, <taxon>, and that each taxon has a <name/>, <rank/> and a context or parentage <parent/> which happens to be another <taxon> at a higher <rank>. Computers do not have any trouble with such a model and can build wonderful and tidy tree-like hierarchies. However, to make the thing humanly intelligible for the purposes of communication, Names below the genus have to be specified with their context because the same name are allowed in different genera. Conceptually the species can be thought of as the thing - the taxon at the rank of species. it handle if the combination of its name and its context: genus name plus species epithet, as you describe. We could always use an name in connection and sometimes do, e.g. Blechnaceae: Woodwardia, or Woodwardia (Blechnaceae), but mostly above the level of genus we do not bother, maybe because people can remember where a smaller number of things fit. But there are undoubtedly equally valid ways of modelling species and their names... jim

1 0