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@alexia.lis.uiuc.edu To: TDWG-SDD@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@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@UIUC.EDU</EMAIL> <MAILING ADDRESS> Graduate School of Library and InformationScience,
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 ...