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@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