Re: Library Standards and URIs

Dirk Herr-Hoyman (hoymand@gate.net)
Thu, 5 Jan 1995 10:29:27 -0500


Date: Thu, 5 Jan 1995 10:29:27 -0500
Message-Id: <ab3221f201021004728d@[199.227.1.66]>
To: winograd@cs.stanford.edu (Terry Winograd),
From: hoymand@gate.net (Dirk Herr-Hoyman)
Subject: Re: Library Standards and URIs
Cc: michael.mealling@oit.gatech.edu, uri@bunyip.com

At 9:58 PM 1/4/95, Terry Winograd wrote:
>At 5:40 PM 12/31/94, Ronald E. Daniel wrote:
>>Fortunately, I think that the requirement that we be able to put just about
>>ANYTHING into the URC points us to a possible solution. If people can add
>>their own attributes to their URCs (which I think is good), we are going to
>>see name clashes (which is bad). We also have the problem of knowing how to
>>interpret these new attributes, after all, someone else might want to
>>utilize them. To overcome these problems, I suggest that non-standard
>>attributes carry along the URN of a human-readable explanation of their
>>purpose, semantics, and syntax
>...
>>In talking with Larry Masinter about this in San Jose, he suggested that
>>we put the URN of the "attribute set" being used at the top of the URC.
>
>...
>In a class-based system (which can, but need not be, hierarchical with
>inheritance) you have a two-level structure -- a class name specifies the
>kind of description and the attributes are specific to the class.  I have
>worked with systems that allow a single object to have multiple
>simultaneous class assignments (multiple descriptors), so you might end up
>with something like the following for a single document:
>
>
>[URC:
>  Class  Corebib <url:http//mysite.net/corebibdef>
>  Class Rated <url:http//yoursite.com/ratingsdef>
>  Class MARC <urn:loc.uri/official/marcdef>
>
>   [COREBIB
>    [urn   mysite.uri/myauth/11122233]
>    [title   My really good resource]
>    [author   Ima Nutt]
>    [date   December 22, 1994]
>    [locations
>      ( [url   http://www.mysite.com/myresource]
>        [extent 24567 bytes]
>        [format text/html]
>      ( [url   ftp://ftp.mysite.com/pub/myresource.txt]
>        [extent 12543 bytes]
>        [format text/plain]    )]   ]
>
>  [RATED
>    [violence 8.a.G ]
>    [sex  0.ssd.Y]
>    [language 4.woi.L]   ]
>
>  [MARC
>    [040$c_Transcribing_Institution  Stanford University]
>    [780-3_Supersedes_In_Part urn:mysite.net/old/resource.txt] ] ]
>
>I have not used SGML syntax here, although there is an obvious translation,
>because of the DTD problem -- since the class definitions (which is an
>open-ended extensible collection) each have their own attributes, there is
>no convenient way to map attribute names to tag names in a DTD -- we can't
>have one huge DTD for everyone's classes, but you don't want a
>mix-and-match DTD specific to every document.   From my point of view, this
>is a strike against using SGML (as opposed to some other variant of
>nested, tagged syntax which doesn't employ the same definition mechanisms).
>
I like the idea of trying to use classes, somehow.  One idea I have mulled
around is that a DTD itself can be an object.  So, even though we need to
have a core DTD for URCs, we might allow for a class-like mechanism where
new tags could be created, along with the associated DTDs.  And how would
we provide for this?  Why, with a URC, of course.

I don't have an example in my back pocket here, but the idea would be that
the URC could specify another URC which had associated with it an alternate
DTD.
And the resolution service would have to be in the business of accepting
retreiving and utilizing these DTD objects.  Not what I would want to
deploy in the first pass, but something that could come later without
breaking the first round deployment.

--
Dirk Herr-Hoyman <hoymand@gate.net> |          I tried to contain myself
CyberBeach Publishing               |                                but
   * Internet publishing services   |                          I got out
Lake Worth, Florida, USA            |
Web: http://www.gate.net/cyberbeach/
Phone:     +1.407.540.8309