- tdwg-content - lists.tdwg.org

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