Trying it out

[P. Bryan Heidorn]

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

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

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

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