- tdwg-content - lists.tdwg.org

Re: Draft Spec mark 2
by Una Smith 01 Sep '00

01 Sep '00

On Fri, 1 Sep 2000, Erik Westlin wrote: >Plant descriptive data is much to complex to be captured in XML which is >more geared towards presentation than representation. I'll second that. I use LaTeX, and previously used a precursor to SGML, to typeset all my printed documents. These *typesetting* languages are great for defining the appearance of the content of documents, but they are utterly inadequate for representing the content (ie., data) itself. For an example of how to present (think about) the relationships within taxonomic datasets, see Appendix A of the manual for BIOTA. IIRC, the PANDORA website at www.rbge.org.uk may aveso has some diagrams relating to this problem. Una Smith una.smith(a)yale.edu Department of Ecology and Evolutionary Biology Yale University New Haven, CT 06520-8106

1 0

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 15 Aug '00

15 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