Re: Library Standards and URIs

Dirk Herr-Hoyman (
Thu, 29 Dec 1994 14:12:46 -0500

Date: Thu, 29 Dec 1994 14:12:46 -0500
Message-Id: <ab2908a901021004c24a@[]>
To: (Michael Mealling)
From: (Dirk Herr-Hoyman)
Subject: Re: Library Standards and URIs

At 2:01 AM 12/29/94, Michael Mealling wrote:
>Dirk Herr-Hoyman said this:
>> Let me start by saying that I see 3 levels of use for URCs, in order of
>> increasing complexity.
>> 1) URN to URL mapping
>> 2) URN to URL with minimal meta-data
>> 3) URN with full meta-data
>> I think we are mostly interested in levels 1+2 here, but that we'd like to
>> keep our options open for the free wheeling type of use that would be in
>> level 3.
>I think that if 2 were kept simple that you could fold 1 and 2 together
>as far as data records are concerned. I think the resulting system would
>be more powerful.
Michael, I'm only using these levels for the purposes of explanation.  I'm
with you that it's really level 2 we want at this point.

>> So, with the idea of
>> creating an SGML syntax use in the simple sorts of URC meta-data, I offer
>> this example:
>> <urc>
>> <urn>urn:mysite.uri/myauth/11122233</urn>
>> <title>My really good resource</title>
>> <author>Ima Nutt</author>
>> <date>December 22, 1994</date>
>> <locationGroup>
>> <list>
>> <item><url></url>
>> <extent>24567 bytes</>
>> <format>text/html</>
>> </item>
>> <item><url></url>
>> <extent>12543 bytes</>
>> <format>text/plain</>
>> </item>
>> </list>
>> </locationGroup>
>> </urc>
>I can deal with this. Are you suggesting then that a URC is defined
>as this limited set? If so I would like to see a level attribute to
>the <urc> tag so that we can extend the complexity of URCs.
I offer this as an example of how a URC with SGML tagging would look, not
as a specification.  My goal at this point is to get the idea of using SGML
on the table for discussion.  If we wish to pursue this, I would think some
sub-group, of which I would be happy to volunteer for, would work on an
acceptable tag set.

>> The elements of this that are TEI syntax are:
>>         <title>
>>         <author>
>>         <date>
>>         <list>
>>         <item>
>>         <extent>
>>         and <locationGroup> follows the spirit of TEI tagging.
>In addition to your additions I would add tags for signatures and possibly
Absolutely.  One of the nice things about SGML/TEI tagging is that it
scales to yet-to-be-conceived uses.  I would like to think that the TEI
header is rich enough to handle most any new use.  So, we wouldn't have to
maintain a registry of attributes.

>> This example also brings forth the issues of language and character sets.
>> In SGML and TEI in particular, there has been consideration given to this
>> issues, and we could piggy back on their work, if we so choose.  This is
>> another area which I think that if we can provide for an extensible
>> framework for URCs, then so much the better.
>(I always love it when I can hand off the character set/language problem
>to someone else. ;-)
>There is one other major problem with SGML though and that is the
>impact it has on the URC resolution service. The powerful nesting makes
>simple query syntaxes impossible. One of my personal requirements is that
>I should be able to build a functional resolution server in a weekend with
>perl. I personally am not that familiar with SGML based databases so
>if someone can illustrate a decent method that is easy to implement I'd
>appreciate it....
I believe this to be possible, though must confess I'd have to get up to
speed at bit on the sgmls parser.  My understanding is that with sgmls, you
could parse SGML into a canonical form, which could then be handled by
something like perl, tcl, c or what not.

Dirk Herr-Hoyman <> |          I tried to contain myself
CyberBeach Publishing               |                                but
   * Internet publishing services   |                          I got out
Lake Worth, Florida, USA            |
Phone:     +1.407.540.8309