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 ----- From: "Bryan Heidorn" heidorn@ALEXIA.LIS.UIUC.EDU To: TDWG-SDD@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@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@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
participants (1)
-
Cornelia Büchen-Osmond