Re: [Handle-info] Service Typing of Handle Values

["Hammond, Tony" <t.hammond@nature.com>]

Hi:

I would just first note that the cited text comes from an offline exchange I
had with Eric.

I was harking back to early work with DOI circa '00/'01. Many of the mails
about that work were made to the private and now defunct doi-twg list. So
inaccessible to me, at least.

The basic ideas explored back then was a grouping mechanism for handle
values using a so-called "handle map". That work was built upon and realized
in some real world deployments and has vestiges also in the CrossRef deposit
schema for DOIs.

As I just remarked to Eric, it struck me now that associating e.g. Labels
with URLs is something that these days one would instinctively reach out to
RSS for. (RSS was not available back then.) The one main defect that RSS has
is that it does not support hierarchy but is essentially "flat".

Worth noting also the OAI-ORE work uses Atom in its "resource maps" (a term
I put forward from the YADS work [1] and based on the earlier "handle
maps"). Again the ORE resource maps do not support hierarchy easily but must
needs do some very cumbersome cross-referencing to achieve the same effect.

Interesting idea anyway (RSS). I wonder if that might be something that
OpenHandle might support. The thing about RSS/Atom is that it provides an
industry standard XML format. Something to think about, anyway.

Cheers,

Tony


[1] http://nurture.nature.com/tony/yads/
[2] http://www.openarchives.org/ore/


On 27/5/08 16:53, "Eric Auer" <eric.auer@mpi.nl> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hi Tony,
> 
>> [no] inferencing [...], just trying to do a dead simple thing.
>> A simple declaration of handle value relationships.
>> 
>> Given two URLs, say, how does one distinguish between them? If presented to
>> a user they would need (at minimum) labels to differentiate them. (Shouldn't
>> expect users to be able to make any sense of the URI strings themselves...)
>> So, if we then have 2 URLs and 2 labels how do we associate each with the
>> other. That's what the handle map was intended to do with URIs and text
>> labels stoired in separate handle values. It's sort of similar to what Sean
>> has but he has it internalized into a single data structure and for a
>> particular use case.
> 
> The only way in a "classic" Handle System would be to
> distinguish the URLs by their index. Each type/value
> pair has one... So it might make sense to have some
> per-namespace/prefix service which can "recommend"
> a preferred index for a given realm and a given set
> of selections from the user. One example...: The user
> could ask the service for a good prefix for URLs for
> MPI handles for users in France, and the service may
> reply "try index 5001, then 5002, then any". Then the
> browser of the user (or some service) could use the
> information returned by the "proxy-ish recommendation
> service" to make a pick among the set of URLs it gets
> when it asks the Handle System for values of type URL
> for the handle hdl:MPI/someresourcenumber :-). Actually
> there could also be some interface / query style which
> lets the Handle System server do all of this on the
> server side, but the idea stays the same... :-).
> 
> Labelled URLs (and other data types) are also a nice
> idea. Sometimes it is good to have some sort of name
> value pair storage. One could either use a free form
> type string (maybe hard for queries?) or a complex,
> for example XML, data string to store data tuples.
> 
> I guess for some tasks name value pairs are better,
> for others type index pairs and for yet other some
> more "server calculated" type of processing...
> 
> Eric
> 
> PS: The "proxy-ish recommendation service" could be
> something completely static, for example a chunk of
> data stored at 0.NA/MPI or a similar location, but
> it could also be something which calculates. Or some
> machine readable rule for calculating things on the
> server or client side. Anything which works will do.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
> 
> iD8DBQFIPC6V99dkROyhRRsRAjOdAJ0UpmdIdJlOi8E/qs0guOhbW1HFgwCffy26
> FNOE5Pypfadj6raiuuV49xE=
> =bQsl
> -----END PGP SIGNATURE-----


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info