August 2000 - tdwg-content

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