August 2000 - tdwg-content

Draft Spec mark 2
by Robert A. (Bob) Morris 31 Aug '00

31 Aug '00

I haven't read the spec or commentary yet, but only looked at your example. It may be that the spec excludes this, but I would rather see a <STATEMENT> be allowed multiple <ELEMENT> elements thus: <STATEMENT> <ITEM> <ITEM_NAME> Gouania exilis </ITEM NAME> </ITEM> <ELEMENT> <ELEMENT_NAME> Flower colour </ELEMENT_NAME> </ELEMENT> <VALUE> green </VALUE> <QUALIFIER> rarely </QUALIFIER> <ELEMENT> <ELEMENT_NAME> Petal shape </ELEMENT_NAME> </ELEMENT> <VALUE> ovate </VALUE> </STATEMENT> Even more readable is the use of attributes <STATEMENT> <ITEM name="Gouania exilis" /> <ELEMENT element_name="Flower colour" value="green" qualifier="rarely" /> <ELEMENT element_name="Petal shape" value="ovate" /> </STATEMENT> In XML the difference between using attributes and using content as you did is usually a matter of style. There are some subtle and one not so subtle differences though: an attribute name must be unique in an XML element. You can't have <ELEMENT element_name="location" value="Costa Rica" value="New Zealand" /> so if you need two locations you have to use content <ELEMENT element_name="location">Costa Rica</ELEMENT> <ELEMENT element_name="location">New Zealand</ELEMENT> or else prescribe a list syntax, e.g. separator based <ELEMENT element_name="locations" value="Costa Rica | New Zealand" /> Yet more readable might be to make the element_name's value be the attribute, at least when the element_name is a traditional character: <STATEMENT> <ITEM name="Gouania exilis" /> <ELEMENT flower_colour="green" qualifier="rarely" /> <ELEMENT petal_shape="ovate" /> <ELEMENT locations="Costa Rica | New Zealand" /> <STATEMENT> This can be somewhat simplified by putting all the characters as attribute on a single ELEMENT where reasonable. Using a list syntax imposes parsing requirements (for the list) on the application beyond those that will be provided by an XML parser and the headache is probably not worth the parsimony obtained. Bob Morris

1 0

Re: Trying it out
by Leigh Dodds 23 Aug '00

23 Aug '00

Hi all, just catching up on the recent list traffic... Thought I'd throw out a few pointers which came to mind. > -----Original Message----- > From: TDWG - Structure of Descriptive Data [mailto:TDWG-SDD@usobi.org]On > Behalf Of Robert A. (Bob) Morris > Sent: 10 August 2000 20:44 > To: TDWG-SDD(a)usobi.org > Subject: Trying it out > [...] > > <CONTRIBUTOR ID>PBH1</CONTRIBUTOR ID> > > <CONTRIBUTOR NAME>P. Bryan Heidorn</CONTRIBUTOR NAME> > > Yech. Separate names into different elements for ease of > transformation, e.g. alphabetizing. Some recent relevant discussion (on XML-DEV) regarding the marking up of names [1,2,3,4,5,6] (Personally I like the format proposed by John Cowan, see [4]). [...] > There must be existing XML mailing address standards around. Better to > use them to leverage any other software that also does. These are good points - it is certainly worth looking around to re-use 'standard' markup conventions where posssible. The Dublin Core Metadata Initiative [7] may be one useful resource here. For example they specify qualifiers for some elements (e.g. creator/contributor) [8, 9] which allow identification of name, affiliation, etc. Even if the exact markup is not used, there are usually useful lessons to be learnt. -- There has been some discussion regarding producing an XML version of the current discussion proposal. Alongside this issues such as version numbering, date last modified, descriptive text, etc. These can be viewed as metadata describing the markup. There are some XML 'patterns' which relate to this area [10, 11]. The XML patterns site [12] is an excellent resource for information on defining good XML document types. -- I've become increasingly convinced lately that the RDF model [13, 14 (useful introduction)] may be useful in this context. For those who are not familiar with RDF it essentially allows one to make assertions about particular objects; expressed as 'triples'. e.g. socrates is a man, the leaf is ovate. Still mulling this one over... [1]. http://lists.xml.org/archives/xml-dev/200005/msg00396.html [2]. http://lists.xml.org/archives/xml-dev/200005/msg00408.html [3]. http://lists.xml.org/archives/xml-dev/200005/msg00412.html [4]. http://lists.xml.org/archives/xml-dev/200005/msg00422.html [5]. http://lists.xml.org/archives/xml-dev/200005/msg00410.html [6]. http://lists.xml.org/archives/xml-dev/200005/msg00423.html [7]. http://purl.org/DC/index.htm [8]. http://purl.org/DC/documents/rec-dces-19990702.htm [9]. http://www.mailbase.ac.uk/lists/dc-agents/files/wd-agent-qual.html [10]. http://www.xmlpatterns.com/SeparateMetadataAndDataMain.shtml [11]. http://www.xmlpatterns.com/HeadBodyMain.shtml [12]. http://www.xmlpatterns.com/index.shtml [13]. http://www.w3.org/TR/REC-rdf-syntax/ [14]. http://www.xml.com/xml/pub/98/06/rdf.html Cheers, L. -- Leigh Dodds, Systems Architect | "Pluralitas non est ponenda http://weblogs.userland.com/eclectic | sine necessitate" http://www.xml.com/pub/xmldeviant | -- William of Ockham

1 0

The view from the BioScape
by Kevin Thiele 21 Aug '00

21 Aug '00

This email may just show my naivety, but: All this discussion about how to accommodate web spiders and their inability to trigger cascading builds of treatments brings to mind two recent discussions outside TDWG - maybe there will be a solution here. It seems to me that there is a problem if we constrain our development to using off-the-shelf web systems rather than create our own. 1. If we ever get this standard thang resolved, can we create our own web spiders with the characteristics we need (e.g. some knowledge of the standard wrt version numbering etc, and the ability to interact with a treatment to trigger events). If this were possible, we wouldn't need to rely on standard search sites (Altavista etc) but could have our own search engine with reports from our own spiders. The standard would include a tag to make it identifiable to the spider. This may be a big job, but surely big is what GBIF is all about. David Yeates (University of Queensland entomologist) and I some time ago were toying with this idea. We called it the BioScape, being a view of Web content tailored for biologists. 2. At a recent NSF/ARC-funded meeting at Manassas near Washington, a group of Australians working in bioinformatics and their American counterparts (inc. Bryan Heidorn, Jim Croft, Stuart Poss) discussed some of the big questions and impediments in the field, and opportunities for collaboration. In the descriptive data part of that meeting we developed the idea of a Taxonomic Workbench, created by a New Taxonomy Collective (this lacks only a manifesto, but that could be arranged). The TW would be a site that taxonomists log onto to do their magic, including capturing, storing, sharing and manipulating descriptions. It would be furnished with server-app tools for these jobs. The gene jockeys have analogues of such a workbench for their work, and these are very successful. Our still-pre-incipient standard would be an important part of this. Again, developing the TW would be a big a big job, but if such a thing is necessary to make it work, then so be it. We would need to report this to TDWG, and boldy go forth. Cheers - k

1 0

the names of resources
by Robert A. (Bob) Morris 17 Aug '00

17 Aug '00

I've found a very cool page with a quite cogent explanation of the several internet standards involved with naming and locating resources on the internet, in distributed databases, etc. etc. I haven't looked at the author's (Norm Walsh) proposal for dealing with some of the associated mysteries generically, but his explanation of what those are is very readable, and he is a well informed fellow at ArborText, an important player in the distributed documentation world. It is at http://www.arbortext.com/Think_Tank/Norm_s_Column/Issue_Three/issue_three.h… Bob Morris p.s. Norm's column shtick is incidentally interesting to biologists: Title: Standard Deviation from Norm. This column: If you can name it, you can claim it.

1 0

Re: Creation/Modification times and Revision Numbers
by Bryan Heidorn 16 Aug '00

16 Aug '00

At 12:25 AM 8/16/00 -0600, Stuart G. Poss wrote: >Bryan Heidorn wrote: > >> What I am concerned about with the revision number is easing processing for >> www >> spiders and for composite documents created from lower level >> documents/treatments. www spiders search the network for new documents to >> index. If the documents are dynamically created "on demand", they are in some >> way different every time the spider looks, if nothing else because the >> "creation date" will change to always be now. We need something more stable >> like editorial date... the last time a qualified human said the record was OK. > >Yes. Each "atomic element" must have a "date last modified [by authority]" >attribute for the reason you suggest. > >However, would not the spec also need to require that the "spider", or >specifically those processing instructions that define the "behavior" or result >set produced by the spider or other collation [transformation] programs >(methods), also leave a distinguishing revision number in the document so that >one can determine what specific method was used? One might expect different >behaviors even for slight changes to the processing (compilation) code used to >assemble the consitutent [atomic] elements of the document to influence the >document content. I was thinking the document type definition would specify a method for generating a field. Kevin had an example of calculating a mean or something like that. That does mean that there need to be a set of predefined methods for value calculation and collection but I do not think that we need to be exhaustive in the spec. The spec can just say that you should identify your method. If it is all object oriented as Bob suggests it might be real executable code. I think that is too much to ask for the first rev of the spec but it should be an option. As Stuart suggests, the resulting value generated by a method at a particular time needs to be tagged with information about when and how it was generated. The attribution fields might do part of that. > >Even though there may be transient lack of availability of some distributed >resources (perhaps due to network failure, loss of a particular server, server >load, etc.] , the behavior of the "spider" also could influence the document >content [atomic element inclusion], albeit independently. This would be an issue >for "higher level" associations (documents) that are created by automatically >assembling other "documents" that are themselves constructed from "atomic >elements". Consequently, requiring the "spider" [read element inclusion >processing instructions] to leave an identifying mark in the document would >provide an ability to distinguish the source of the potential differences in the >final dynamic document. ditto > >> >> >> The same problem exists for higher level taxon descriptions that are created >> from lower level descriptions. There was a short thread about this a while ago >> on this list. A good feature of dynamic creation of the descriptions is that >> when a low level detail changes the higher level summary information also >> automatically changes. The "oops, that specimen was actually a different >> species" syndrome, may cause a character state recording some value to change >> (because the outlier was recognized as another species.) We do not want to >> have to recalculate and verify all atomic facts whenever someone looks at a >> high level description. > >Yes, I fully agree that the lower [atomic] level of detail must force changes at >higher more associative/inclusive levels precisely for the reason you suggest. > >However, within an environment where the data may be distributed there may be >sources of error that may be generated when "key" atomic elements are not found >(server load to great, network failure, etc) or perhaps only older versions can >be located (only mirrors available, unflushed cache, etc). Consequently, to >assess the logic needed to [possibly further] process or interpret a document's >contents would it not be useful to also have a means to pass knowledge of what >methods were used to assemble the document? Presumably, the behaviors of the >processing instructions (document generating methods) will influence the >circumstances under which some kinds of atomic element processing instructions >(methods) will fail while others may succeed, say in making subsequent changes >"automatically" or "recognizing" the existence of another species. > >Don't we need a spec that includes [requires?] a means to pass knowledge about >the kinds of associations that were made to generate the document, as well as the >lower level "atomic elements"and their attribution, if we are to avoid >recalculation to fundamental atomic level at each stage in the transformation >(document building) process? If documents were characterized in XML, this could >make it much easier to chain XML transformations by faciliating the recognition >of what order of transformations were permissible. This could also greatly >simplify the modification of processor (method) behavior and the >development/maintenance of efficient interprocess communication. A document that >was validated by successfully being transformed at one lower level of processing >to another by a given method, would not require revalidation at these "lower >levels" when being transformed to the next "higher" level by another method. >Presumably, such tags could be scattered at widely different levels within the >document, indicating scope of the document over which specific transformations >were relevant. Right. This is complex. Any CS doctoral students out there looking for a dissertation? Just kidding! It is not that bad. Well, if we make simplifying assumptions it is not that bad. For rev 1.0 we should skip it but I can think of an easy case to test. We could include a common name list in the butterfly records from itis*ca. That list could be manually generated at first. By "manually", I mean have the contributor search itis and type the results by hand into the treatment. Later we can have the system query itis for XML that can be inserted directly (or transformed first) into the treatment, on-the-fly. We'll see how the method tracking issue shakes out on the real example. > >These issues are separate from the kinds of errors that may result when a method >encounters "atomic elements" that are internally inconsistent, within a >distributed processing environment. So far we've avoided how to handle this >separate issue within the spec. I don't have an answer except perhaps simply >requiring everyone to agree :-) or specifying the kinds of errors that should be >generated under such conditions. Perhaps we should just report processing errors somewhere. All calculated fields have comment fields already. Perhaps there should be exception fields too that in most cases will be empty. Again, this is a bell or whistle that is not needed to get "something" running. > >Perhaps others may suggest a better/alternate approach to address these aspects >of dynamic document generation/transformation within the spec. > > Bryan -- -------------------------------------------------------------------- P. Bryan Heidorn Graduate School of Library and Information Science pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Creation/Modification times and Revision Numbers
by Cornelia Büchen-Osmond 16 Aug '00

16 Aug '00

Just a comment: I was recently told by an expert in this field that documents build on the fly are usually not indexed by WWW search engines and one had to have a stable document in place as well to be seen out there. Cornelia ----- Original Message ----- From: "Bryan Heidorn" <heidorn(a)ALEXIA.LIS.UIUC.EDU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Wednesday, August 16, 2000 8:56 AM Subject: Re: Creation/Modification times and Revision Numbers > What I am concerned about with the revision number is easing processing for > www > spiders and for composite documents created from lower level > documents/treatments. www spiders search the network for new documents to > index. If the documents are dynamically created "on demand", they are in some > way different every time the spider looks, if nothing else because the > "creation date" will change to always be now. We need something more stable > like editorial date... the last time a qualified human said the record was OK. > > The same problem exists for higher level taxon descriptions that are created > from lower level descriptions. There was a short thread about this a while ago > on this list. A good feature of dynamic creation of the descriptions is that > when a low level detail changes the higher level summary information also > automatically changes. The "oops, that specimen was actually a different > species" syndrome, may cause a character state recording some value to change > (because the outlier was recognized as another species.) We do not want to > have to recalculate and verify all atomic facts whenever someone looks at a > high level description. We do want to regenerate summary information when > something changes... We can know that something has changed when the revision > number on a fact does not match. > > Wow, what a pile of trouble for a little feature! > > I do not know what to do about defining "treatment", "document", "collection" > and "project". I am willing to adopt any one else's definitions. The key point > is that there are actually different things that need to be treated > differently > some how. > > Bryan > At 04:16 PM 8/15/00 -0600, Stuart G. Poss wrote: > >Bryan Heidorn wrote: > > > >> Yes, perhaps there are really two different fields > >> Treatment creation time and revision number. I think time alone is not > enough > >> since one can not tell from that if the treatment has changed since it was > >> last > >> viewed or used (to create higher level treatments). > > > >> > > > >> Do you instead mean time created and time last revised, as well as revision > >> number? > > > >It is conceivable that different systems (servers) might have various, > slighly > >different versions of the constructional software running on them that could, > at > >least in principle, produce two different version numbers even when > >"simultaneously" generating elements of the same document (treatment?). > > > >Don't we need to keep in mind that both "collections [attributable to a > unique > >source?]" and "treatments [virtual collections generated from multiple > sources > >with respect to specific <processing> instructions?]" [or visa versa?] > may be > >dynamic in distributed environments? > > > >I too remain unsure how the concepts and scope of terms "treatment" and > >"document" and "collection" are being used (defined) as this discussion > emerges. > >It might be useful for us to maintain a glossary, perhaps with qualifiers (ie > >sensu Bryan or sensu Kevin, etc), as such issues arise. We can then at least > >know whether we agree/disagree with respect to what definitions required or > with > >respect to how the definitions are used. > > > > > >> > >> > > >> >| The current standard makes a relatively weak standard that the > contributor > >> >| codes are unique to the treatment. I think we need to use a broader > >> >| definition. The should be unique to a collection at least. > >> > > >> >Again we have a definitional problem and I think my treatment = your > >> >collection. > >> > > >> >| Attribution: > >> >| Must this be a contributor? If so this information should be handles > as a > >> >| property of <CONTRIBUTOR ROLE=PRINCIPAL|COPRINCIPAL> or as another > tag of > >> >| <CONTRIBUTOR> > >> >| .... <ROLE>PRINCIPLE</ROLE>.... > >> >| Suggestions? > >> > > >> >Yes, it could be done like this, but what would be wrong with doing it the > >> >other way - seems somehow neater to me, and I can't see much inefficiency. > >> It could > >> > >> -- > >> -------------------------------------------------------------------- > >> P. Bryan Heidorn Graduate School of Library and Information Science > >> pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign > >> (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 > >> (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn > > > -- > -------------------------------------------------------------------- > P. Bryan Heidorn Graduate School of Library and Information Science > pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign > (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 > (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Creation/Modification times and Revision Numbers
by Bryan Heidorn 16 Aug '00

16 Aug '00

At 10:18 AM 8/16/00 +1000, Cornelia Büchen-Osmond wrote: >Just a comment: >I was recently told by an expert in this field that documents build on the >fly are usually not indexed by WWW search engines and one had to have a >stable document in place as well to be seen out there. >Cornelia That is correct. Generic web spiders would not know what parameters to send to a site to generate pages. Custom spiders do not have this problem. The other solution is to have the site refresh its html files whenever a change is made to the underlying data or every night if it needs it or not. -- -------------------------------------------------------------------- P. Bryan Heidorn Graduate School of Library and Information Science pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Creation/Modification times and Revision Numbers
by Stuart G. Poss 16 Aug '00

16 Aug '00

Bryan Heidorn wrote: > What I am concerned about with the revision number is easing processing for > www > spiders and for composite documents created from lower level > documents/treatments. www spiders search the network for new documents to > index. If the documents are dynamically created "on demand", they are in some > way different every time the spider looks, if nothing else because the > "creation date" will change to always be now. We need something more stable > like editorial date... the last time a qualified human said the record was OK. Yes. Each "atomic element" must have a "date last modified [by authority]" attribute for the reason you suggest. However, would not the spec also need to require that the "spider", or specifically those processing instructions that define the "behavior" or result set produced by the spider or other collation [transformation] programs (methods), also leave a distinguishing revision number in the document so that one can determine what specific method was used? One might expect different behaviors even for slight changes to the processing (compilation) code used to assemble the consitutent [atomic] elements of the document to influence the document content. Even though there may be transient lack of availability of some distributed resources (perhaps due to network failure, loss of a particular server, server load, etc.] , the behavior of the "spider" also could influence the document content [atomic element inclusion], albeit independently. This would be an issue for "higher level" associations (documents) that are created by automatically assembling other "documents" that are themselves constructed from "atomic elements". Consequently, requiring the "spider" [read element inclusion processing instructions] to leave an identifying mark in the document would provide an ability to distinguish the source of the potential differences in the final dynamic document. > > > The same problem exists for higher level taxon descriptions that are created > from lower level descriptions. There was a short thread about this a while ago > on this list. A good feature of dynamic creation of the descriptions is that > when a low level detail changes the higher level summary information also > automatically changes. The "oops, that specimen was actually a different > species" syndrome, may cause a character state recording some value to change > (because the outlier was recognized as another species.) We do not want to > have to recalculate and verify all atomic facts whenever someone looks at a > high level description. Yes, I fully agree that the lower [atomic] level of detail must force changes at higher more associative/inclusive levels precisely for the reason you suggest. However, within an environment where the data may be distributed there may be sources of error that may be generated when "key" atomic elements are not found (server load to great, network failure, etc) or perhaps only older versions can be located (only mirrors available, unflushed cache, etc). Consequently, to assess the logic needed to [possibly further] process or interpret a document's contents would it not be useful to also have a means to pass knowledge of what methods were used to assemble the document? Presumably, the behaviors of the processing instructions (document generating methods) will influence the circumstances under which some kinds of atomic element processing instructions (methods) will fail while others may succeed, say in making subsequent changes "automatically" or "recognizing" the existence of another species. Don't we need a spec that includes [requires?] a means to pass knowledge about the kinds of associations that were made to generate the document, as well as the lower level "atomic elements"and their attribution, if we are to avoid recalculation to fundamental atomic level at each stage in the transformation (document building) process? If documents were characterized in XML, this could make it much easier to chain XML transformations by faciliating the recognition of what order of transformations were permissible. This could also greatly simplify the modification of processor (method) behavior and the development/maintenance of efficient interprocess communication. A document that was validated by successfully being transformed at one lower level of processing to another by a given method, would not require revalidation at these "lower levels" when being transformed to the next "higher" level by another method. Presumably, such tags could be scattered at widely different levels within the document, indicating scope of the document over which specific transformations were relevant. These issues are separate from the kinds of errors that may result when a method encounters "atomic elements" that are internally inconsistent, within a distributed processing environment. So far we've avoided how to handle this separate issue within the spec. I don't have an answer except perhaps simply requiring everyone to agree :-) or specifying the kinds of errors that should be generated under such conditions. Perhaps others may suggest a better/alternate approach to address these aspects of dynamic document generation/transformation within the spec. > > > Wow, what a pile of trouble for a little feature! > > I do not know what to do about defining "treatment", "document", "collection" > and "project". I am willing to adopt any one else's definitions. The key point > is that there are actually different things that need to be treated > differently > some how. Thats fine by me as long as we can communicate which ones we're using. > > > Bryan > At 04:16 PM 8/15/00 -0600, Stuart G. Poss wrote: > >Bryan Heidorn wrote: > > > >> Yes, perhaps there are really two different fields > >> Treatment creation time and revision number. I think time alone is not > enough > >> since one can not tell from that if the treatment has changed since it was > >> last > >> viewed or used (to create higher level treatments). > > > >> > > > >> Do you instead mean time created and time last revised, as well as revision > >> number? > > > >It is conceivable that different systems (servers) might have various, > slighly > >different versions of the constructional software running on them that could, > at > >least in principle, produce two different version numbers even when > >"simultaneously" generating elements of the same document (treatment?). > > > >Don't we need to keep in mind that both "collections [attributable to a > unique > >source?]" and "treatments [virtual collections generated from multiple > sources > >with respect to specific <processing> instructions?]" [or visa versa?] > may be > >dynamic in distributed environments? > > > >I too remain unsure how the concepts and scope of terms "treatment" and > >"document" and "collection" are being used (defined) as this discussion > emerges. > >It might be useful for us to maintain a glossary, perhaps with qualifiers (ie > >sensu Bryan or sensu Kevin, etc), as such issues arise. We can then at least > >know whether we agree/disagree with respect to what definitions required or > with > >respect to how the definitions are used. > > > > > >> > >> > > >> >| The current standard makes a relatively weak standard that the > contributor > >> >| codes are unique to the treatment. I think we need to use a broader > >> >| definition. The should be unique to a collection at least. > >> > > >> >Again we have a definitional problem and I think my treatment = your > >> >collection. > >> > > >> >| Attribution: > >> >| Must this be a contributor? If so this information should be handles > as a > >> >| property of <CONTRIBUTOR ROLE=PRINCIPAL|COPRINCIPAL> or as another > tag of > >> >| <CONTRIBUTOR> > >> >| .... <ROLE>PRINCIPLE</ROLE>.... > >> >| Suggestions? > >> > > >> >Yes, it could be done like this, but what would be wrong with doing it the > >> >other way - seems somehow neater to me, and I can't see much inefficiency. > >> It could > >> > >> -- > >> -------------------------------------------------------------------- > >> P. Bryan Heidorn Graduate School of Library and Information Science > >> pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign > >> (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 > >> (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn > > > -- > -------------------------------------------------------------------- > P. Bryan Heidorn Graduate School of Library and Information Science > pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign > (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 > (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Creation/Modification times and Revision Numbers
by Robert A. (Bob) Morris 15 Aug '00

15 Aug '00

Cornelia Büchen-Osmond writes: > Date: Wed, 16 Aug 2000 10:18:02 +1000 > From: =?iso-8859-1?Q?Cornelia_B=FCchen-Osmond?= <buchen(a)rsbs.anu.edu.au> > To: TDWG-SDD(a)usobi.org > Subject: Re: Creation/Modification times and Revision Numbers > > Just a comment: > I was recently told by an expert in this field that documents build on the > fly are usually not indexed by WWW search engines and one had to have a > stable document in place as well to be seen out there. > Cornelia > > ----- Original Message ----- This is generally true, mostly because those engines have no particular way to construct a query that will induce the creation of the page. However, /other/ software, such as that which attempts to combine the data from several sources, may well wish to know which of those sources is more recent, whether cached data previously obtained from a source is stale, etc. For this reason, both a date (GMT of course) and revision number are useful. Ideally, these would be of very fine granularity, e.g. down to the field, but minimally they would be on the record. If you don't do them on the field it becomes more complicated to decide whether a datum from one database is more recent than that from another: Source 1 Record A: Item1(Jan 01, 2000) Item2(Feb 01, 2000) Source 2 Record B: Item1(Feb 15, 2000) Item2(Jan 15, 2000) Record B was modified later than Record A, but the datum in A-2 is the more current Item2. Revision numbers are not useful across sources unless the sources have a common revision number pool, which requires distributed revision control. --Bob Morris

1 0

Re: Creation/Modification times and Revision Numbers
by Bryan Heidorn 15 Aug '00

15 Aug '00

What I am concerned about with the revision number is easing processing for www spiders and for composite documents created from lower level documents/treatments. www spiders search the network for new documents to index. If the documents are dynamically created "on demand", they are in some way different every time the spider looks, if nothing else because the "creation date" will change to always be now. We need something more stable like editorial date... the last time a qualified human said the record was OK. The same problem exists for higher level taxon descriptions that are created from lower level descriptions. There was a short thread about this a while ago on this list. A good feature of dynamic creation of the descriptions is that when a low level detail changes the higher level summary information also automatically changes. The "oops, that specimen was actually a different species" syndrome, may cause a character state recording some value to change (because the outlier was recognized as another species.) We do not want to have to recalculate and verify all atomic facts whenever someone looks at a high level description. We do want to regenerate summary information when something changes... We can know that something has changed when the revision number on a fact does not match. Wow, what a pile of trouble for a little feature! I do not know what to do about defining "treatment", "document", "collection" and "project". I am willing to adopt any one else's definitions. The key point is that there are actually different things that need to be treated differently some how. Bryan At 04:16 PM 8/15/00 -0600, Stuart G. Poss wrote: >Bryan Heidorn wrote: > >> Yes, perhaps there are really two different fields >> Treatment creation time and revision number. I think time alone is not enough >> since one can not tell from that if the treatment has changed since it was >> last >> viewed or used (to create higher level treatments). > >> > >> Do you instead mean time created and time last revised, as well as revision >> number? > >It is conceivable that different systems (servers) might have various, slighly >different versions of the constructional software running on them that could, at >least in principle, produce two different version numbers even when >"simultaneously" generating elements of the same document (treatment?). > >Don't we need to keep in mind that both "collections [attributable to a unique >source?]" and "treatments [virtual collections generated from multiple sources >with respect to specific <processing> instructions?]" [or visa versa?] may be >dynamic in distributed environments? > >I too remain unsure how the concepts and scope of terms "treatment" and >"document" and "collection" are being used (defined) as this discussion emerges. >It might be useful for us to maintain a glossary, perhaps with qualifiers (ie >sensu Bryan or sensu Kevin, etc), as such issues arise. We can then at least >know whether we agree/disagree with respect to what definitions required or with >respect to how the definitions are used. > > >> >> > >> >| The current standard makes a relatively weak standard that the contributor >> >| codes are unique to the treatment. I think we need to use a broader >> >| definition. The should be unique to a collection at least. >> > >> >Again we have a definitional problem and I think my treatment = your >> >collection. >> > >> >| Attribution: >> >| Must this be a contributor? If so this information should be handles as a >> >| property of <CONTRIBUTOR ROLE=PRINCIPAL|COPRINCIPAL> or as another tag of >> >| <CONTRIBUTOR> >> >| .... <ROLE>PRINCIPLE</ROLE>.... >> >| Suggestions? >> > >> >Yes, it could be done like this, but what would be wrong with doing it the >> >other way - seems somehow neater to me, and I can't see much inefficiency. >> It could >> >> -- >> -------------------------------------------------------------------- >> P. Bryan Heidorn Graduate School of Library and Information Science >> pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign >> (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 >> (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn > -- -------------------------------------------------------------------- P. Bryan Heidorn Graduate School of Library and Information Science pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Trying it out
by Bryan Heidorn 15 Aug '00

15 Aug '00

At 03:28 PM 8/14/00 +1000, Kevin Thiele wrote: >This is getting places. > >Perhaps I'm stuck still in the way Lucid and DELTA do things. There, a >treatment is not a description of one taxon, but a set of descriptions for a >set of taxa - e.g. all the species in genus X, or all the trees of Victoria. >This is because the treatment is viewed as having a definite objective or >product - storing data that will become an interactive key to the trees of >Victoria, or a set of natural-language descriptions of the species in genus >X. >You're handling it very differently, with each treatment the description of >one taxon, the treatments then bundled into a project defined (presumably) >by the objective. The advantage of this is being able to bundle individual >treatments in different ways (for different projects); the disadvantage is >having to make sure that such cross-bundling works - ie you may end up >bundling together several taxon treatments with different character lists. >Perhaps what you're calling a 'treatment' is actually the Item Data block of >the DDST, and what I call a treatment is what you're suggesting as a >project. >We need to sort this out. Consistency of character lists across taxon could be handled by the document type definition for that taxon class (or some other mechanism if we do not use XML in the end) for a collection of taxon descriptions. The dtd defines what can go into the treatments and how they may be combined. > >| Treatment build/revision number >| Treatment build/revision number is a really good idea and we all agreed >| that we should have had it in our treatments before. >| <TREATMENT REVISION>0.1</TREATMENT REVISION> >| We use the 0 when the treatment is under development and not released yet. >| I do not know how to deal with dynamic treatment build revision numbers. >| Suggestions are welcome. > >I think this should be up to the contributor not the spec. The general >guideline that <1 is work-in-progress doesn't really work, since all >treatments are and always will be works n progress. The only requirement >surely is that treatment numbers should increment - but perhaps then we >should just use the arrow of time and date-stamp? Yes, perhaps there are really two different fields Treatment creation time and revision number. I think time alone is not enough since one can not tell from that if the treatment has changed since it was last viewed or used (to create higher level treatments). > > >| The current standard makes a relatively weak standard that the contributor >| codes are unique to the treatment. I think we need to use a broader >| definition. The should be unique to a collection at least. > >Again we have a definitional problem and I think my treatment = your >collection. > >| Attribution: >| Must this be a contributor? If so this information should be handles as a >| property of <CONTRIBUTOR ROLE=PRINCIPAL|COPRINCIPAL> or as another tag of >| <CONTRIBUTOR> >| .... <ROLE>PRINCIPLE</ROLE>.... >| Suggestions? > >Yes, it could be done like this, but what would be wrong with doing it the >other way - seems somehow neater to me, and I can't see much inefficiency. It could -- -------------------------------------------------------------------- P. Bryan Heidorn Graduate School of Library and Information Science pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Creation/Modification times and Revision Numbers
by Stuart G. Poss 15 Aug '00

15 Aug '00

Bryan Heidorn wrote: > Yes, perhaps there are really two different fields > Treatment creation time and revision number. I think time alone is not enough > since one can not tell from that if the treatment has changed since it was > last > viewed or used (to create higher level treatments). > > Do you instead mean time created and time last revised, as well as revision > number? It is conceivable that different systems (servers) might have various, slighly different versions of the constructional software running on them that could, at least in principle, produce two different version numbers even when "simultaneously" generating elements of the same document (treatment?). Don't we need to keep in mind that both "collections [attributable to a unique source?]" and "treatments [virtual collections generated from multiple sources with respect to specific <processing> instructions?]" [or visa versa?] may be dynamic in distributed environments? I too remain unsure how the concepts and scope of terms "treatment" and "document" and "collection" are being used (defined) as this discussion emerges. It might be useful for us to maintain a glossary, perhaps with qualifiers (ie sensu Bryan or sensu Kevin, etc), as such issues arise. We can then at least know whether we agree/disagree with respect to what definitions required or with respect to how the definitions are used. > > > > >| The current standard makes a relatively weak standard that the contributor > >| codes are unique to the treatment. I think we need to use a broader > >| definition. The should be unique to a collection at least. > > > >Again we have a definitional problem and I think my treatment = your > >collection. > > > >| Attribution: > >| Must this be a contributor? If so this information should be handles as a > >| property of <CONTRIBUTOR ROLE=PRINCIPAL|COPRINCIPAL> or as another tag of > >| <CONTRIBUTOR> > >| .... <ROLE>PRINCIPLE</ROLE>.... > >| Suggestions? > > > >Yes, it could be done like this, but what would be wrong with doing it the > >other way - seems somehow neater to me, and I can't see much inefficiency. > It could > > -- > -------------------------------------------------------------------- > P. Bryan Heidorn Graduate School of Library and Information Science > pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign > (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 > (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: Trying it out
by Kevin Thiele 14 Aug '00

14 Aug '00

Bryan - great! | Treatment not equal to file: | The second paragraph of the General Requirements of the DDST v1.1 states | that "One file will comprise one treatment...". There is no reason to | require in the specification that a treatment = a file. This is because | there is good reason to synthesize XML treatments on the fly from databases | and allow users to query the XML structure to extract just the elements | that they need. Most of the proposed spec works fine it we say that "A | treatment is a structured presentation of information. The DDST provides a | uniform view of descriptive data for taxonomy but it does not specify the | underlying storage and representation of the information." We'll examples | of why I say this below. | | Taxon Name: | We start right off with the Treatment Name. For the butterfly project at | least, the treatments are all about species. Is it reasonable to give each | treatment a name that equals the Taxon Name | Taxon ID? That is what we're | doing for now. In general, should the DDST include treatment naming | conventions linked to the Taxon ID? Of course you get into trouble if the | Taxon Name changes but you would be OK if the ID were kept constant. | So for now our treatments will have names like <Treatment Name>Papilio | polyxene</Treatment Name> but I am not happy with the decision. Any better | ideas out there? If so it would be helpful if those ideas were in the spec? | In our case the treatment name will also be a file name for now but | eventually parts will be in a database and we'll need a unique <Treatment ID>. | | Description: | I think it is fine that there is a description element to the treatment but | we were confused about what should be being described; the taxon or really | the treatment. We decided that decided to take the spec at face value and | really include the treatment which is fairly boring. All our treatment | descriptions will be pretty much the same. <DESCRIPTION>This treatment was | created as part of the Biological Information Browsing Environment project | funded by NSF, UIUC... Information selected for the treatment is intended | to support tasks associated with the PrairieWatch project....</DESCRIPTION> | This uniformity makes me believe that many aspects in this description | should be removed from the treatment and moved "up" one level to a higher | order entity such as a collection of treatments or project. Several other | elements of the treatment format support that notion. It means that DDST | v1.1 is really a Treatment Spec. We also need a Collection Spec. This means | that the treatments should all have an element called the Project ID. This is getting places. Perhaps I'm stuck still in the way Lucid and DELTA do things. There, a treatment is not a description of one taxon, but a set of descriptions for a set of taxa - e.g. all the species in genus X, or all the trees of Victoria. This is because the treatment is viewed as having a definite objective or product - storing data that will become an interactive key to the trees of Victoria, or a set of natural-language descriptions of the species in genus X. You're handling it very differently, with each treatment the description of one taxon, the treatments then bundled into a project defined (presumably) by the objective. The advantage of this is being able to bundle individual treatments in different ways (for different projects); the disadvantage is having to make sure that such cross-bundling works - ie you may end up bundling together several taxon treatments with different character lists. Perhaps what you're calling a 'treatment' is actually the Item Data block of the DDST, and what I call a treatment is what you're suggesting as a project. We need to sort this out. | Treatment build/revision number | Treatment build/revision number is a really good idea and we all agreed | that we should have had it in our treatments before. | <TREATMENT REVISION>0.1</TREATMENT REVISION> | We use the 0 when the treatment is under development and not released yet. | I do not know how to deal with dynamic treatment build revision numbers. | Suggestions are welcome. I think this should be up to the contributor not the spec. The general guideline that <1 is work-in-progress doesn't really work, since all treatments are and always will be works n progress. The only requirement surely is that treatment numbers should increment - but perhaps then we should just use the arrow of time and date-stamp? | | Contributors List: | Notice that if the information about collectors in the list such as contact | information is repeated in each treatment there is a data integrity | problem. People move. It might be possible that some treatments would have | one set of old contact information and not be updated while some treatments | might get updated information. This will always be a problem if you try to attribute data to a movng object such as a person. I see no way of getting around this. But presumably a combination of the contact details and date stamps on treatments could be used to track our wandering contributor? | It should be that when a person requests a treatment in DDST v1.1 format | that they will get back a contributor list with ID, Name and Contact | Details but in most cases the system providing the information would insert | the contact information "on the fly". There does not seem to be a reason to | force the contributor IDs to be numeric as stated in the spec. Alpha | numeric can carry at least a little information to make the codes readable. True | The current standard makes a relatively weak standard that the contributor | codes are unique to the treatment. I think we need to use a broader | definition. The should be unique to a collection at least. Again we have a definitional problem and I think my treatment = your collection. | Attribution: | Must this be a contributor? If so this information should be handles as a | property of <CONTRIBUTOR ROLE=PRINCIPLE|COPRINCIPLE> or as another tag of | <CONTRIBUTOR> | .... <ROLE>PRINCIPLE</ROLE>.... | Suggestions? Yes, it could be done like this, but what would be wrong with doing it the other way - seems somehow neater to me, and I can't see much inefficiency. | List of Sources: | Again, usually the underlying information might be kept in different files | or databases but the view of a treatment would include the fields of the | spec. For us the spec will include bibliographic references and "personal | observations" Again is seems that source ID should at least be unique to an | entire collection, not just to the treatment. | <LIST OF SOURCES> | <SOURCE> | <SOURCE ID>KL2000</SOURCE ID> | <DESCRIPTION>Koller and Smith (2000). Butterflies of the Great West. | Biology Press: New York. | </DESCRIPTION> | </SOURCE> | <SOURCE> | <SOURCE ID>MJ2000</SOURCE ID> | <DESCRIPTION>Mike Jacobs, personal communication August 10, 2000. | </DESCRIPTION> | </SOURCE> | </SOURCE LIST> Sources and attributions need to be thought through more. I see attribution as a reference to the person who actually encoded the data, and source as reference to the data source as far back as it can be pushed. Source may thus be a reference to a printed work, and attribution a reference to the person who interpreted the meaning of that description into the format; or source may be a reference to a specimen (or collection of specimens) and attribution be a reference to the person who observed that specimen. The critical thing is to have a hierarchy of ownership for both source and attribution; thus, for one character the (default) source may be a printed work, but for individual taxa the contributor may have referred back to specimens and this should be an overriding source. Cheers - k

1 0

Re: Trying it out
by Robert A. (Bob) Morris 14 Aug '00

14 Aug '00

Kevin Thiele writes: > Date: Mon, 14 Aug 2000 15:28:20 +1000 > From: Kevin Thiele <kevin.thiele(a)PI.CSIRO.AU> > To: TDWG-SDD(a)usobi.org > Subject: Re: Trying it out > > Bryan - great! > ... > by the objective. The advantage of this is being able to bundle individual > treatments in different ways (for different projects); We try to teach programming students that their abstractions should not forclose the use of data and code in presently unforseen applications. Software developers should never be permitted to utter "Why would anyone want to do X?" for any value of X. (FWIW, the most common bugs in languages such as C which do not do type checking arise from buffer overruns because a programmer said something like "Why would anyone ever want more than 256 <something> ? " > the disadvantage is > having to make sure that such cross-bundling works - ie you may end up > bundling together several taxon treatments with different character lists. As I frequently rave, this is an argument in favor of object oriented data representations, which are ipso-fact self-describing. XML is a simple way to accomplish this, but so are object oriented databases such as Object Store and its competitors. The book by Abiteboul et al. "Data on the Web" describes---albeit sometimes with some deep theory---how one can combine data whose objects have different descriptions. Bob Morris

1 0

Re: Trying it out
by Robert A. (Bob) Morris 11 Aug '00

11 Aug '00

Hey, I wrote some software a few years ago, still in use, that I didn't even /release/ until 27.3 ! Susan B. Farmer writes: > Date: Fri, 11 Aug 2000 09:35:12 -0400 > From: "Susan B. Farmer" <sfarmer(a)GOLDSWORD.COM> > To: TDWG-SDD(a)usobi.org > Subject: Re: Trying it out > > >> > Treatment build/revision number is a really good idea and we all agreed > >> > that we should have had it in our treatments before. > >> > <TREATMENT REVISION>0.1</TREATMENT REVISION> > >> > >> > We use the 0 when the treatment is under development and not released yet. > >> > I do not know how to deal with dynamic treatment build revision numbers. > >> > >>What's meant by this? > > > >I don't think this needs to be in the spec. We're just following software > >development practice that anything with a revision number less than 1.0 can > >not be trusted.... Or is that anything less than 2.5? > > > > IME, anything less than 1.0 -- and *nothing* that ends in a 0 even if > it is 5.0 ...wait till 5.1! > > Susan > > Susan Farmer > sfarmer(a)goldsword.com > Botany Department, University of Tennessee > http://www.goldsword.com/sfarmer/Trillium >

1 0

Re: Trying it out
by Susan B. Farmer 11 Aug '00

11 Aug '00

>> > Treatment build/revision number is a really good idea and we all agreed >> > that we should have had it in our treatments before. >> > <TREATMENT REVISION>0.1</TREATMENT REVISION> >> >> > We use the 0 when the treatment is under development and not released yet. >> > I do not know how to deal with dynamic treatment build revision numbers. >> >>What's meant by this? > >I don't think this needs to be in the spec. We're just following software >development practice that anything with a revision number less than 1.0 can >not be trusted.... Or is that anything less than 2.5? > IME, anything less than 1.0 -- and *nothing* that ends in a 0 even if it is 5.0 ...wait till 5.1! Susan Susan Farmer sfarmer(a)goldsword.com Botany Department, University of Tennessee http://www.goldsword.com/sfarmer/Trillium

1 0

Re: Trying it out
by Jim Croft 11 Aug '00

11 Aug '00

Bryan wrote: >My research group has finally been able to devote a couple of hours >together discussing the DDST V1.1 as it relates to the published treatments >of the Flora of North America and records that we are creating for the >EcoWatch Project. First, we quickly dismissed trying to fit FNA into the >spec since we ran into to many issues. We'll return to FNA another day but >we did decide that the PrairieWatch Butterflies of Illinois for EcoWatch >were much easier to deal with since we have full editorial control. So over >the next two weeks we'll be modifying the DTD for that project and working >up 20 or so example treatments (all at the species level.). We had some >immediate questions and comments even before we convert one treatment. I am very interested in this approach Bryan as we are design what might be a similar thing in association with the Flora of Australia and the Virtual Australian Herbarium for handling taxon-based descriptive information as published without the character level atomization of Delta, LucID and similar approaches. I had not mentioned it before because I thought it was a bit off topic for where this list is going. But since you raise it... The atomization of descriptive data elements is definitely the way to go, but attempts to start databasing our Flora in the past have foundered because the whole exercise gets too complicated too quickly. Much like on this list, people developed clinical universal standard character list fixation syndrome and lost sight of forest, not for the trees, but for the primary anadromy of subjuvenile leaf segments in taxon X :) We are now pursuing a compromise but hopefully achievable approach of handling flora treatments as partially parsed 'blobs' at the taxon level (where the most common levels are family, genus, species, infraspecies, etc), with an XML schema that breaks things up into readily identifiable elements from the published work - name author, reference, publication, synonymy, description, figures, distribution, ecology, notes, keys, etc. - without the need fro huge amounts of manual intervent, interpretation, rescoring, etc. Admittedly there are serious limitations to this approach, but we believe it will serve a useful purpose while the world and SDD gets it act together on a universal approach to descriptive data. It looks like we will be storing the data in our Oracle database and spewing it out via XML for internet delivery and various publication options. And a range of XML tools are arriving that will enable us to pour marked up treatments straight into the database. Have not got time to reply in detail right now, but this weekend I will try and tidy up some of our attempts at a data definition for the project and post it to the list. As indicated by Bob's response we are going to have to pay particular attention not to reinvent standards and definitions that already exist out there... it will be helpfudl for us to be able to piggyback on what your group is doing... cheers jim

1 0

Trying it out
by Robert A. (Bob) Morris 10 Aug '00

10 Aug '00

[URN = "Unform Resource Name". See http://www.ietf.org/rfc/rfc2141.txt if you are bold] P. Bryan Heidorn writes: > Date: Thu, 10 Aug 2000 10:59:50 -0500 > From: "P. Bryan Heidorn" <heidorn(a)alexia.lis.uiuc.edu> > To: TDWG-SDD(a)usobi.org > Subject: Trying it out >[...] > Treatment build/revision number is a really good idea and we all agreed > that we should have had it in our treatments before. > <TREATMENT REVISION>0.1</TREATMENT REVISION> > We use the 0 when the treatment is under development and not released yet. > I do not know how to deal with dynamic treatment build revision numbers. What's meant by this? > Suggestions are welcome. > > Contributors List: > Notice that if the information about collectors in the list such as contact > information is repeated in each treatment there is a data integrity > problem. People move. It might be possible that some treatments would have > one set of old contact information and not be updated while some treatments > might get updated information. IMO a contributor would be a URN, that is a globally unique identifier, and there would be catalogs at which the Contributor could update contact information. In this case, the contact information would be advisory only and contain the URL of the catalog service. Typical URN's are email addresses or URL's (even when the latter don't actually point to any actual web page.). The data might need to carry or point to a clue that the URN's are only for disambiguation---they might, e.g. not result in an email reaching the person). > > It should be that when a person requests a treatment in DDST v1.1 format > that they will get back a contributor list with ID, Name and Contact > Details but in most cases the system providing the information would insert > the contact information "on the fly". There does not seem to be a reason to Per above, the system could query the catalog for the above info, but so could the requestor's software if the data server identified the catalog URL and provided enough information for the requesting software to make a request to the catalog. Among other things, given the Contributer's URN it is even conceivable that the requestor might be able to find more accurate contact information that is available at the catalog the system consults. > force the contributor IDs to be numeric as stated in the spec. Alpha > numeric can carry at least a little information to make the codes readable. For example, email addresses as URN's /usually/ will be very meaningful and always unique. > The current standard makes a relatively weak standard that the contributor > codes are unique to the treatment. I think we need to use a broader > definition. The should be unique to a collection at least. That way it > would be easy to find all treatments in a collection that a particular > person was a contributor for. Better if they were unique for the world but > that is more than this group can bite off I think. DDST should at least > say that the Contributor ID is unique to a Collection. They should be unique on a galactic scale at least. > For us we have > <CONTRIBUTOR LIST> > <CONTRIBUTOR> > <CONTRIBUTOR ID>ML1</CONTRIBUTOR ID> > <CONTRIBUTOR NAME>Mary L.</CONTRIBUTOR NAME> > <CONTACT DETAILS> > <EMAIL>maryl(a)uiuc.edu</EMAIL> > <MAILING ADDRESS> > Address here > </MAILING ADDRESS> > </CONTACT DETAILS> > </CONTRIBUTOR><CONTRIBUTOR> > <CONTRIBUTOR ID>PBH1</CONTRIBUTOR ID> > <CONTRIBUTOR NAME>P. Bryan Heidorn</CONTRIBUTOR NAME> Yech. Separate names into different elements for ease of transformation, e.g. alphabetizing. > <CONTACT DETAILS> > <EMAIL>PHEIDORN(a)UIUC.EDU</EMAIL> > <MAILING ADDRESS> > Graduate School of Library and Information Science, > University of Illinois at Urbana-Champaign, > 501 East Daniel St., Champaign, IL 61820-6212 > </MAILING ADDRESS> There must be existing XML mailing address standards around. Better to use them to leverage any other software that also does. > </CONTACT DETAILS> > </CONTRIBUTOR> > <CONTRIBUTOR LIST> > > Attribution: > Must this be a contributor? If so this information should be handles as a > property of <CONTRIBUTOR ROLE=PRINCIPLE|COPRINCIPLE> or as another tag of > <CONTRIBUTOR> > .... <ROLE>PRINCIPLE</ROLE>.... > Suggestions? mm, isn't Linnaeus a frequent attributee but a rare contributor? > > List of Sources: > Again, usually the underlying information might be kept in different files > or databases but the view of a treatment would include the fields of the > spec. For us the spec will include bibliographic references and "personal > observations" Again is seems that source ID should at least be unique to an > entire collection, not just to the treatment. A galactically unique id would be good here for similar reasons to above, but might require a catalog to be useful. The publishing world got it right with Cataloging In Press and having the publisher assign the details of the ISBN. If all authors of new publications assigned a URN, and somebody else assigned them to all pre-existing publications in the galaxy ... > <LIST OF SOURCES> > <SOURCE> > <SOURCE ID>KL2000</SOURCE ID> > <DESCRIPTION>Koller and Smith (2000). Butterflies of the Great West. > Biology Press: New York. > </DESCRIPTION> > </SOURCE> > <SOURCE> > <SOURCE ID>MJ2000</SOURCE ID> > <DESCRIPTION>Mike Jacobs, personal communication August 10, 2000. > </DESCRIPTION> > </SOURCE> > </SOURCE LIST> > > Actually in XML we don't need the <SOURCE LIST> but if is OK for now. > > Sorry, I'm way out of time. I'll have to get back to our other comments > later. This is enough for one message in any case. > > Cheers, > Bryan > -- > -------------------------------------------------------------------- > P. Bryan Heidorn Graduate School of Library and Information Science > pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign > (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 > (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn > > >

1 0

Re: Trying it out
by P. Bryan Heidorn 10 Aug '00

10 Aug '00

At 03:43 PM 8/10/00 -0400, Robert A. (Bob) Morris wrote: >[URN = "Unform Resource Name". See http://www.ietf.org/rfc/rfc2141.txt >if you are bold] That would work! Need to fix the PRINCIPLE/PRINCIPAL problem too. >P. Bryan Heidorn writes: > > Date: Thu, 10 Aug 2000 10:59:50 -0500 > > From: "P. Bryan Heidorn" <heidorn(a)alexia.lis.uiuc.edu> > > To: TDWG-SDD(a)usobi.org > > Subject: Trying it out > >[...] > > Treatment build/revision number is a really good idea and we all agreed > > that we should have had it in our treatments before. > > <TREATMENT REVISION>0.1</TREATMENT REVISION> > > > We use the 0 when the treatment is under development and not released yet. > > I do not know how to deal with dynamic treatment build revision numbers. > >What's meant by this? I don't think this needs to be in the spec. We're just following software development practice that anything with a revision number less than 1.0 can not be trusted.... Or is that anything less than 2.5? > > Suggestions are welcome. > > > > > > > Contributors List: > > Notice that if the information about collectors in the list such as > contact > > information is repeated in each treatment there is a data integrity > > problem. People move. It might be possible that some treatments would have > > one set of old contact information and not be updated while some > treatments > > might get updated information. > >IMO a contributor would be a URN, that is a globally unique >identifier, and there would be catalogs at which the Contributor could >update contact information. In this case, the contact information >would be advisory only and contain the URL of the catalog service. >Typical URN's are email addresses or URL's (even when the latter don't >actually point to any actual web page.). The data might need to carry >or point to a clue that the URN's are only for disambiguation---they >might, e.g. not result in an email reaching the person). > > > > > > It should be that when a person requests a treatment in DDST v1.1 format > > that they will get back a contributor list with ID, Name and Contact > > Details but in most cases the system providing the information would > insert > > the contact information "on the fly". There does not seem to be a > reason to > >Per above, the system could query the catalog for the >above info, but so could the requestor's software if the data server >identified the catalog URL and provided enough information for the >requesting software to make a request to the catalog. Among other >things, given the Contributer's URN it is even conceivable that the >requestor might be able to find more accurate contact information that >is available at the catalog the system consults. > > > force the contributor IDs to be numeric as stated in the spec. Alpha > > numeric can carry at least a little information to make the codes > readable. > >For example, email addresses as URN's /usually/ will be very >meaningful and always unique. > > > The current standard makes a relatively weak standard that the contributor > > codes are unique to the treatment. I think we need to use a broader > > definition. The should be unique to a collection at least. That way it > > > > would be easy to find all treatments in a collection that a particular > > person was a contributor for. Better if they were unique for the world but > > that is more than this group can bite off I think. DDST should at least > > say that the Contributor ID is unique to a Collection. > >They should be unique on a galactic scale at least. > > > > For us we have > > <CONTRIBUTOR LIST> > > <CONTRIBUTOR> > > <CONTRIBUTOR ID>ML1</CONTRIBUTOR ID> > > <CONTRIBUTOR NAME>Mary L.</CONTRIBUTOR NAME> > > <CONTACT DETAILS> > > <EMAIL>maryl(a)uiuc.edu</EMAIL> > > <MAILING ADDRESS> > > Address here > > </MAILING ADDRESS> > > </CONTACT DETAILS> > > </CONTRIBUTOR><CONTRIBUTOR> > > <CONTRIBUTOR ID>PBH1</CONTRIBUTOR ID> > > <CONTRIBUTOR NAME>P. Bryan Heidorn</CONTRIBUTOR NAME> > >Yech. Separate names into different elements for ease of >transformation, e.g. alphabetizing. Yes. We should grab that spec somewhere else too so that we do not need to worry about details of how each culture orders names and titles. > > <CONTACT DETAILS> > > <EMAIL>PHEIDORN(a)UIUC.EDU</EMAIL> > > <MAILING ADDRESS> > > Graduate School of Library and Information > Science, > > University of Illinois at Urbana-Champaign, > > 501 East Daniel St., Champaign, IL 61820-6212 > > </MAILING ADDRESS> > >There must be existing XML mailing address standards around. Better to >use them to leverage any other software that also does. You bet. We just need to find it. > > </CONTACT DETAILS> > > </CONTRIBUTOR> > > <CONTRIBUTOR LIST> > > > > Attribution: > > Must this be a contributor? If so this information should be handles as a > > property of <CONTRIBUTOR ROLE=PRINCIPLE|COPRINCIPLE> or as another tag of > > <CONTRIBUTOR> > > .... <ROLE>PRINCIPLE</ROLE>.... > > Suggestions? > >mm, isn't Linnaeus a frequent attributee but a rare contributor? Yes, now-a-days I get it. > > > > List of Sources: > > Again, usually the underlying information might be kept in different files > > or databases but the view of a treatment would include the fields of the > > spec. For us the spec will include bibliographic references and "personal > > observations" Again is seems that source ID should at least be unique > to an > > entire collection, not just to the treatment. > >A galactically unique id would be good here for similar reasons to >above, but might require a catalog to be useful. The publishing world >got it right with Cataloging In Press and having the publisher assign >the details of the ISBN. If all authors of new publications assigned a >URN, and somebody else assigned them to all pre-existing publications >in the galaxy ... > > >

1 0

Trying it out
by P. Bryan Heidorn 10 Aug '00

10 Aug '00

My research group has finally been able to devote a couple of hours together discussing the DDST V1.1 as it relates to the published treatments of the Flora of North America and records that we are creating for the EcoWatch Project. First, we quickly dismissed trying to fit FNA into the spec since we ran into to many issues. We'll return to FNA another day but we did decide that the PrairieWatch Butterflies of Illinois for EcoWatch were much easier to deal with since we have full editorial control. So over the next two weeks we'll be modifying the DTD for that project and working up 20 or so example treatments (all at the species level.) We had some immediate questions and comments even before we convert one treatment. Treatment not equal to file: The second paragraph of the General Requirements of the DDST v1.1 states that "One file will comprise one treatment...". There is no reason to require in the specification that a treatment = a file. This is because there is good reason to synthesize XML treatments on the fly from databases and allow users to query the XML structure to extract just the elements that they need. Most of the proposed spec works fine it we say that "A treatment is a structured presentation of information. The DDST provides a uniform view of descriptive data for taxonomy but it does not specify the underlying storage and representation of the information." We'll examples of why I say this below. Taxon Name: We start right off with the Treatment Name. For the butterfly project at least, the treatments are all about species. Is it reasonable to give each treatment a name that equals the Taxon Name | Taxon ID? That is what we're doing for now. In general, should the DDST include treatment naming conventions linked to the Taxon ID? Of course you get into trouble if the Taxon Name changes but you would be OK if the ID were kept constant. So for now our treatments will have names like <Treatment Name>Papilio polyxene</Treatment Name> but I am not happy with the decision. Any better ideas out there? If so it would be helpful if those ideas were in the spec? In our case the treatment name will also be a file name for now but eventually parts will be in a database and we'll need a unique <Treatment ID>. Description: I think it is fine that there is a description element to the treatment but we were confused about what should be being described; the taxon or really the treatment. We decided that decided to take the spec at face value and really include the treatment which is fairly boring. All our treatment descriptions will be pretty much the same. <DESCRIPTION>This treatment was created as part of the Biological Information Browsing Environment project funded by NSF, UIUC... Information selected for the treatment is intended to support tasks associated with the PrairieWatch project....</DESCRIPTION> This uniformity makes me believe that many aspects in this description should be removed from the treatment and moved "up" one level to a higher order entity such as a collection of treatments or project. Several other elements of the treatment format support that notion. It means that DDST v1.1 is really a Treatment Spec. We also need a Collection Spec. This means that the treatments should all have an element called the Project ID. Treatment build/revision number Treatment build/revision number is a really good idea and we all agreed that we should have had it in our treatments before. <TREATMENT REVISION>0.1</TREATMENT REVISION> We use the 0 when the treatment is under development and not released yet. I do not know how to deal with dynamic treatment build revision numbers. Suggestions are welcome. Contributors List: Notice that if the information about collectors in the list such as contact information is repeated in each treatment there is a data integrity problem. People move. It might be possible that some treatments would have one set of old contact information and not be updated while some treatments might get updated information. It should be that when a person requests a treatment in DDST v1.1 format that they will get back a contributor list with ID, Name and Contact Details but in most cases the system providing the information would insert the contact information "on the fly". There does not seem to be a reason to force the contributor IDs to be numeric as stated in the spec. Alpha numeric can carry at least a little information to make the codes readable. The current standard makes a relatively weak standard that the contributor codes are unique to the treatment. I think we need to use a broader definition. The should be unique to a collection at least. That way it would be easy to find all treatments in a collection that a particular person was a contributor for. Better if they were unique for the world but that is more than this group can bite off I think. DDST should at least say that the Contributor ID is unique to a Collection. For us we have <CONTRIBUTOR LIST> <CONTRIBUTOR> <CONTRIBUTOR ID>ML1</CONTRIBUTOR ID> <CONTRIBUTOR NAME>Mary L.</CONTRIBUTOR NAME> <CONTACT DETAILS> <EMAIL>maryl(a)uiuc.edu</EMAIL> <MAILING ADDRESS> Address here </MAILING ADDRESS> </CONTACT DETAILS> </CONTRIBUTOR><CONTRIBUTOR> <CONTRIBUTOR ID>PBH1</CONTRIBUTOR ID> <CONTRIBUTOR NAME>P. Bryan Heidorn</CONTRIBUTOR NAME> <CONTACT DETAILS> <EMAIL>PHEIDORN(a)UIUC.EDU</EMAIL> <MAILING ADDRESS> Graduate School of Library and Information Science, University of Illinois at Urbana-Champaign, 501 East Daniel St., Champaign, IL 61820-6212 </MAILING ADDRESS> </CONTACT DETAILS> </CONTRIBUTOR> <CONTRIBUTOR LIST> Attribution: Must this be a contributor? If so this information should be handles as a property of <CONTRIBUTOR ROLE=PRINCIPLE|COPRINCIPLE> or as another tag of <CONTRIBUTOR> .... <ROLE>PRINCIPLE</ROLE>.... Suggestions? List of Sources: Again, usually the underlying information might be kept in different files or databases but the view of a treatment would include the fields of the spec. For us the spec will include bibliographic references and "personal observations" Again is seems that source ID should at least be unique to an entire collection, not just to the treatment. <LIST OF SOURCES> <SOURCE> <SOURCE ID>KL2000</SOURCE ID> <DESCRIPTION>Koller and Smith (2000). Butterflies of the Great West. Biology Press: New York. </DESCRIPTION> </SOURCE> <SOURCE> <SOURCE ID>MJ2000</SOURCE ID> <DESCRIPTION>Mike Jacobs, personal communication August 10, 2000. </DESCRIPTION> </SOURCE> </SOURCE LIST> Actually in XML we don't need the <SOURCE LIST> but if is OK for now. Sorry, I'm way out of time. I'll have to get back to our other comments later. This is enough for one message in any case. Cheers, Bryan -- -------------------------------------------------------------------- P. Bryan Heidorn Graduate School of Library and Information Science pheidorn(a)uiuc.edu University of Illinois at Urbana-Champaign (V)217/ 244-7792 501 East Daniel St., Champaign, IL 61820-6212 (F)217/ 244-3302 http://alexia.lis.uiuc.edu/~heidorn

1 0

Re: characters/states and measurements and other hoary problems
by Stuart G. Poss 07 Aug '00

07 Aug '00

Kevin Thiele wrote: An item in the DDS is like an old OTU - it may be anything from a specimen > to a species to a Kingdom. ... > > The possibility of specimens being items comes from the ability to nest > treatments. > > e.g. Treatment A comprises measurements of a series of specimens of > Imaginaria magica for some characters (e.g. hypopode length). Treatment B > comprises as its items species of Imaginaria. Some characters (e.g. CAM > metabolism) are scored directly in B while others (e.g. the range of > hypopode lengths) are collated from A. > > Data for the character hypopode length in B would then be attributed to > treatment A, where each data element is attributed to measurements taken by > me on a specimen. Redetermination of a specimen followed by rebuilding of > the treatment tree would allow the redetermination to be incorporated all > the way up. > > Would this work, and does it address your query? This seem plausible to me. The only complication that comes to mind is the situation where one might have two inconsistent identifications of particular specimens. How would the redetermination rule work with respect to A if one has a Treatment C, say for hypopode width, for which the ID for (some?) of the same specimens in A is inconsistent with that used in treatement A? If the inconsistency is based on soley a difference of combination (perhaps old synonym incorrectly used) one could make the redetermination automatically (using the nomenclaturally appropriate combination). Otherwise, I'm not sure what flags get raised since it would depend on the nature of the inconsistency. Perhaps just throw the data back to the user with an error message and let them make a decision might be the appropriate response? This could certainly aid in identifying mistaken identifications, but in any event there probably needs to be some kind of default logic once inconsistency in the data is located. It will be difficult to eliminate entirely. > > > >Statement: > > > >One file will comprise one treatment, the basic unit of which is one or more > >characters describing one or more taxa or individuals. > > > Surely the data level to which a character is attributed is determined by > the context of the treatment: I would agree. I think its a question of to what extent we want the system to be able to make (part of) the inference for us so that we can be aware of the "universe" of features out there for which there are relevant data. When the data are initially recorded they are most likely defined within a much narrower context. I'm still struggling with how we can determine the extent to which the rules might be constructed to determine (identify/establish) context. > > Another collation rule may convert low-order numeric data into a > higher-order multistate: > Could be lots of options here. >

1 0

Re: characters/states and measurements and other hoary problems
by Kevin Thiele 07 Aug '00

07 Aug '00

At 12:52 PM 3/8/00 -0600, Stuart Poss wrote: >1 Attribution and sources for an item datum overides that for a character or >taxon, which override that for the treatment as a whole. Attribution for >characters and taxa are equivalent and additive. > >Don't we also need to say that item data attribution at the specimen level >may override that for a character or taxon as a whole? Otherwise, the system >has no way of dealing with misidentifications, particularly if some but not >all parts have been associated with the wrong ID, as might be frequently >encountered in fossils, or when dealing with taxa whose character state >definitions are later found applicable for only a specific size range (ie >differentially break down at small sizes). Specimen or parts level >data/attributions also would presumably be additive, even if potentially >contradictory (subject to differences of opinion), would they not? An item in the DDS is like an old OTU - it may be anything from a specimen to a species to a Kingdom. In footnote 1 I'm trying to address the relationships between attribution of the different possible sources of data, not between different levels of the hierarchy. That is, there may be an attribution for the treatment as a whole: e.g. Data for this treatment, unless otherwise attributed, are derived from the literature source Bloggs & Hogwash (1899) But data for a particular character (for all OTUs) may come from a different source: e.g. Data for character 9 (presence or absence of the CAM photosynthetic pathway) comes from the literature source Meg & Mog (1999) and the attribution Meg & Mog 1999 will override the default attribution. But data for a particular item (in this case a taxon that was not included in Meg & Mog 1999) for character 9 comes from pers. obs. The possibility of specimens being items comes from the ability to nest treatments. e.g. Treatment A comprises measurements of a series of specimens of Imaginaria magica for some characters (e.g. hypopode length). Treatment B comprises as its items species of Imaginaria. Some characters (e.g. CAM metabolism) are scored directly in B while others (e.g. the range of hypopode lengths) are collated from A. Data for the character hypopode length in B would then be attributed to treatment A, where each data element is attributed to measurements taken by me on a specimen. Redetermination of a specimen followed by rebuilding of the treatment tree would allow the redetermination to be incorporated all the way up. Would this work, and does it address your query? >Statement: > >One file will comprise one treatment, the basic unit of which is one or more >characters describing one or more taxa or individuals. > >If we are to presume nested levels of groupings of descriptor elements, then >we need to be able to clearly distinguish data values that are regarded as >referring to "individual units" (specimen, species, higher level taxon) at >one level, but are "collective" when evaluated at a different level. Not >only with the "collation rules" be different for different levels, but may be >different depending on whether a given feature (possibly "same feature but >defined differently") is regarded as a data item refering to a specific >"individual unit", or as a "collective unit". That is, the data item is a >representation of data that might apply to a collection, rather than a >measurable value that may have a scope no larger than a specific measure of a >specific specimen. Perhaps some treatments might include "collections of >collections" that would imply a mixing of both situations. > >Seems to me we need a means of distinguishing between collective >representations and "unit values" (for lack of a better word), if for no >other reason than to be able to track which data items apply to particular >"features of general interest" (eg. leaves, roots, head, foot, etc) and which >taxa are involved (higher-level taxon, species, individuals, parts of >individuals). Its not clear to me how the current DDST can be used to >associate "basic units" that might be reasonably differentially defined at >different "levels of composition" by different investigators. Perhaps we >need some general means to assign the "scope" over which the definitions of >"unit" apply. Surely the data level to which a character is attributed is determined by the context of the treatment: >we need to be able to clearly distinguish data values that are regarded as >referring to "individual units" (specimen, species, higher level taxon) at >one level, but are "collective" when evaluated at a different level. Not The attribution of data for a collated character in B to "raw" data in A provides the context: we know that the character in B is collated and hence higher-level data than in A. Same goes for "collations of collations" - the attribution allows you to track the data down to its source. Or am I misinterpreting you? Peter Stevens added: >the measurement(s) of either the specimen or the species could be assigned >to states; those states might encompass a range of variation such that the >attributuion of a specimen/species to that state would mean that, when >refering to the state, one loses sight of the original measurements. A collation rule may derive a higher-order numeric from numeric data: e.g. Treatment A stores hypopode lengths for specimens, Treatment B collates a range (and/or mean, median etc) of hypopode lengths for a species, Treatment C collates a higher-order range of lengths for a genus etc. Another collation rule may convert low-order numeric data into a higher-order multistate: e.g. Treatment A stores leaf length, leaf width and distance to widest point for specimens, Treatment B collates these into shapes for species, Treatment C collates the shapes again, this time direct from treatment A rather than bringing in the problems of collating a collation. (Note that sometimes collating a collation may be acceptable e.g. determining the full range of petal colours in a higher-level taxon, where the rules at all levels are simple additive) Thus, with both the collation rules and attribution at all levels fully explicit, one should be able to track any data element to its source. Any good, Peter? Cheers - k

1 0

Re: Where are we?
by Jim Croft 05 Aug '00

05 Aug '00

>We're discussing the need for a standard rather than actually creating one. Very deftly put Kevin... >I put up a while ago an initial attempt at a proposal (the document DDST >Specifications.doc, you all will have this buried in your attachments >folder somewhere). Some people have looked at this, I know, but I think we >need to decide: >1. Is this a start, or is it the wrong way to proceed and should be ditched >in favour of something better I think it is a good start... if you ditched it, you would only have to reinvent it, or something very like it... >2. If it's an adequate start, what concrete changes are needed to >incorporate the ideas people are discussing? It would be useful to migrate to definition to the XML arena so we can throw some data at it, dump into some XML parsers and see what the resulting mess looks like... >3. If it should be ditched, can anyone produce a better draft specification >that we can build on. ??? Is anyone out there going to XMLify it? >I think at this stage we need a draft document around which the discussion >can focus. Contributions that point out complications and problems can then >make concrete suggestions as to changes to the draft proposal, rather than >be mere discussion points. It seems to me we should be at this stage around >now - we've discussed the problems for close on 12 months now. yep... time to stop slicing bait and go after the fish... >Now it may be that the structure of this group is poorly suited for the >task, and a recommendation should go to TDWG that this isn't the way to >proceed. As it stands, it seems to me that we're functioning well as a >discussion group but not well as a working group (actually working on the >problem). This is undoubtedly partly because we're all busy - I know that >I'm doing all this in my "spare" time and I'm sure most of us are in the >same boat. Perhaps the only way that this can happen properly is for funds >to be sought to employ someone on a contract basis to turn the ideas raised >here into concrete output, using the list as an expert group/listening >post/scratch-pad resource or whatever. We need to be honest as to whether >we're going to achieve something. Experience with contractors/consultants is that they require a fairly tight specification of what they are being asked to build or you will end up with a pedal-powered space shuttle, or worse. We need to come up with the specs, and having done that there will probably not be much for the contractor to do. Nailing the specs to the wall should be something that this group can be able to do. We have all developed specs, schemas, models, etc. at some stage of our lives for our own enterprises. All we have to do is reach consensus on what this one might look like. Hey - shouldn't be much more difficult than herding cats or nailing jelly to a wall... :) And once we have the specs there may even be one or several among us who will actually build something with it. jim

1 0

Re: Structure vs content
by Jim Croft 05 Aug '00

05 Aug '00

>To some people, character definitions are part of the *structure* of >a data format, while to others these definitions are *content*. E.g., >character definitions as structure (attribution lost): Quite! I have always regarded this group as one dealing with structure and until we are able to nail down this distinction and put the content to one side for a short while, it is going to continue to be difficult to make clear progress on the underlying structural issues... jim

1 0

Re: Expression of continuing interest
by Bryan Heidorn 04 Aug '00

04 Aug '00

In my humble opinion, as many people have stated in this group, we need to put the actual content issues aside to establish the standard. In the end we only really care about sharing the content. The structure is just a means to enable sharing of content. The point that I was trying to make about "ovate" is not that the actual word "ovate" needs to be in the standard but that the descriptive mechanisms of the standard should allow data types such as "ovate" to exist as content and that the structure of the standard should be able to encode information about the content to allow people or computer programs to make decisions about the use of the content. The particular XML-like syntax is only as means of how that kind of information could be encoded in the structure. Maybe if I ground this in Kevin's document I'll have a little better luck trying to communicate. ------------------------------------- Character List {required unless an external lexicon resource has been specified above} [ Character Name3 Character ID Set membership {list of sets to which the character belongs; a character must be able to belong to more than one set} Attribution1 {reference to a contributor�s ID from the Contributors list} Source1 (reference to a source�s ID from the Sources list) Collated Character source {path name for another treatment that contains lower-level data for this character} Collation rule name {Name of a collation rule as defined in the Collation Rules list}2 Character type {ordered multistate, unordered multistate etc} Character dependencies (up) 4 Applies To list (or global/restricted type definition, then leave it to program to extract) 5 Character attachments [ attachment name attachment type attachment path/URL Public notes7 Private notes7 ] Private notes {internal notes for character}7 Character State List [ Character state name | Character state ID Character dependencies (down) Character state attachments . . . --------------- The authors of an Angiosperm treatment standard might want to use the document created by this group (BioSDD?) as a guideline for making their treatment definition. As part of their definition may wish to create a Character Name = "Leaf Shape", with a Character dependency of "Leaves". They will need to provide a Character State list for this Character. These states could take many forms. The BioSDD should provide guidance on this form. There should be a range of options of data types and processing to choose from (along of course with the options of using something not included in the BioSDD). I am arguing that the BioSDD should include data types and type qualifiers that are different from and addition to the "Character type" in Kevin's document "Character type {ordered multistate, unordered multistate etc} " So you might say that a particular character like "leaf shape" in the Angiosperm might have Character States that are assigned by "text", "collation rule" or "Fourier descriptor". The Angiosperm standard authors might further specify that vocabulary for character states of the text based state descriptions. They might include "ovate", "oblong" and "round" in that list. (This list would not be included in the BioSDD. The BioSDD would just say that if you have a unordered unistate text field that you can provide a list to the authors or leave the state values open to any text.) An author of a treatment then might decide by ungrounded opinion that the leaves of the Waga oni plant are "ovate". The author would record "ovate" and that it is of type "text" so that not computer program will read it and try to treat it like a Fourier descriptor. I am sorry that I am having difficulty making this clear. I might be way off base. There seem to be two issues related to this problem. Should we allow a standard that flags these kinds of data and how can we represent this type of functionality in the structure of the BioSDD guidelines so that Angiosperm standard authors can easily use them. now I need to get some work done. Bryan

1 0