[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[handle-dev] Re: Handle URI parameters
Norman,
Thank you for this very positive message, inviting for a joint effort on
OpenURL.
May be the upcoming reference linking meeting provides a good
opportunity explore how to get such collaboration off the ground.
many greetings
herbert
"Paskin, Norman (DOI-ELS)" wrote:
>
> I would support the suggestion of working with the OpenURL syntax, which is
> to be proposed as a formal NISO standard. It appears that e.g. IDF and SFX
> communities will both encounter similar problems of defining services and
> vocabularies and we could make good progress working together; it therefore
> makes sense to try for one rather than two solutions. I don't see any
> downside to this. For the STM-ers on this list: I have suggested that a
> presentation on SFX/OpenURl etc be a feature of the STM December Innovations
> Committee meeting.
>
> I think Larry's write-up is a very good description of the problem and
> approaches to solutions.
>
> Norman
>
> -----Original Message-----
> From: Larry Lannom [mailto:llannom@cnri.reston.va.us]
> Sent: 09 October 2000 02:41
> To: CrossRef Technical Working Group; handle-dev@cnri.reston.va.us;
> Herbert Van de Sompel; Paskin, Norman; Tim Ingoldsby
> Subject: Handle URI parameters
>
> CNRI is proposing an extension to handle URI syntax to define and encode
> various types of parameters. Our initial proposal divides the parameters
> into three categories, in addition to which we have a number of
> different syntax proposals which differ on the positioning of the
> parameters and the delimiters used. The little exposition below
> describes the proposed parameter types first, followed by the syntaxes.
>
> A small group saw this a few weeks ago but had little comment. One
> significant set of comments, however, recommended that we try to follow
> the OpenURL syntax (one description of which is here -
> http://sfx1.exlibris-usa.com/OpenURL/openurl.html) which uses a
> controlled set of tags in tag/value pairs in a fairly standard URI query
> syntax. (I hope Herbert will correct me if I've misrepresented this.)
>
> I send this out somewhat hesitantly, as I am just leaving town for two
> weeks and will be reading mail only intermittently, but also know that a
> resolution of this issue is overdue.
>
> All comments appreciated. Thanks.
>
> Larry
>
> ======================================================
>
> 1. Handle parameter -- applies to the the whole handle and is expressed
> as attribute=value pairs. A common use of this would be to specify a
> particular handle type in a resolution request. Thus, adding type=EMAIL
> to a URI for a handle would serve as an instruction to a handle client
> to request only EMAIL types as returned values from the resolution of
> the given handle. This could also be used to parameterize the
> resolution, e.g., perform an authoritative query (don't ask a secondary
> server).
>
> 2. Handle value parameter -- applies to the returned handle value(s).
> Implementations would be driven by the returned values. Thus, while it
> is easy to imagine stating these parameters as attribute=value pairs,
> this would not be a requirement. A common use of this would be to append
> a given string to a returned URL, e.g., "source=JournalABC" would append
> the string "source=JournalABC" to the end of any returned handle values
> according to some further specification that would be implemented by the
> handle client. The further specification would probably be along the
> lines of append this only to values of type URL and separate with
> question marks.
>
> 3. Object parameter -- applies to objects referenced by a handle or by
> specific handle values. Again, implementation would be driven by the
> type of the returned object and the syntax specification would be silent
> on the specifics. A common use would be to identify a section in a
> returned object, e.g., "chapter23".
> So that leaves the question of syntax. As you probably know, we've
> experimented with and implemented a syntax for handle parameters. This
> is of the form
>
> (attribute=value)@hdl
>
> Thus
>
> (type=EMAIL)@200/1
>
> will return a handle value of type email. For this particular handle,
> this is equivalent to
>
> (index=4)@200/1
>
> This is currently implemented, for resolution in both the http/handle
> proxy and the handle resolver extension for web browsers, although not
> to our knowledge used in any production processes.
>
> We initially had two ideas for extending this to include the other two
> parameters. The first was to simply come up with two other sets of
> delimiters, e.g.,
>
> (handle parameter){returned value parameter}[returned object
> parameter]@hdl
>
> The second was to nest them, e.g.,
>
> (handle param(returned value param(returned obj param)))@hdl
>
> We didn't really like either. The discussions ranged around which would
> be easier to parse, which would be more confusing, what to do with
> compound statements, e.g., two handle parameters and one value
> parameter, and how well it would fit into current and potential future
> URI syntax.
>
> The third suggestion, and currently the local favorite, is to more
> closely imitate current URI syntax and delimiters as follows
>
> hdl!handle param?returned value param#returned object param
>
> thus
>
> hdl:10.123/456!type=email?subject=Request for Account
>
> or
>
> http://dx.doi.org/10.123/654?src=JournalABC#p12
>
> note that this last case is equivalent to
>
> http://dx.doi.org/10.123/654!type=URL?src=JournalABC#p12
>
> as URL is the default type for the proxy.
>
> If we wanted to allow multiple instances, we would probably define the &
> as the internal delimiter, e.g.,
>
> hdl:200/1!type=EMAIL&type=PUBKEY
>
> This example assumes, of course, that you have a client that you expect
> to do something specific with an email address and a public key.
>
> The trailing !?# delimiters approach seems to have several advantages -
> mostly from fitting better into the URL legacy world with which we have
> to live. Leading with the parameters had some appeal both in the way it
> scanned for human consumption and for encoding issues, but the trailing
> approach using common URI delimiters will probably give less trouble
> overall. The nested parens have a certain elegance, but require the two
> outer layers to get to the third layer even if you have nothing to say
> in the outer two.
>
> Note that these proposals deal only with URI syntax and with client
> functionality. They do not affect in any way the core handle system
> protocols or data model, but instead provide a way to leverage existing
> features, such as handle value typing, and provide a common approach to
> solving some current problems, e.g., passing along the source of a link.
--
Herbert Van de Sompel
Visiting Assistant Professor
Cornell University -- Computer Science
tel + 1 - 607 - 255 - 3085
fax + 1 - 607 - 255 - 4428
digital life in libraries used to be primitive
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev