Creation/Modification times and Revision Numbers

[Cornelia Büchen-Osmond]

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 at ALEXIA.LIS.UIUC.EDU>
To: <TDWG-SDD at 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 at 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 at 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