Trying it out
Robert A. (Bob) Morris
ram at CS.UMB.EDU
Thu Aug 10 15:43:51 CEST 2000
[URN = "Unform Resource Name". See http://www.ietf.org/rfc/rfc2141.txt
if you are bold]
P. Bryan Heidorn writes:
> Date: Thu, 10 Aug 2000 10:59:50 -0500
> From: "P. Bryan Heidorn" <heidorn at alexia.lis.uiuc.edu>
> To: TDWG-SDD at 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?
> 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 at 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.
> <CONTACT DETAILS>
> <EMAIL>PHEIDORN at UIUC.EDU</EMAIL>
> <MAILING ADDRESS>
> Graduate School of Library and Information Science,
> 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.
> </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?
>
> 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 ...
> <LIST OF SOURCES>
> <SOURCE>
> <SOURCE ID>KL2000</SOURCE ID>
> <DESCRIPTION>Koller and Smith (2000). Butterflies of the Great West.
> Biology Press: New York.
> </DESCRIPTION>
> </SOURCE>
> <SOURCE>
> <SOURCE ID>MJ2000</SOURCE ID>
> <DESCRIPTION>Mike Jacobs, personal communication August 10, 2000.
> </DESCRIPTION>
> </SOURCE>
> </SOURCE LIST>
>
> Actually in XML we don't need the <SOURCE LIST> but if is OK for now.
>
> Sorry, I'm way out of time. I'll have to get back to our other comments
> later. This is enough for one message in any case.
>
> Cheers,
> Bryan
> --
> --------------------------------------------------------------------
> 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
>
>
>
More information about the tdwg-content
mailing list