Re: [Handle-info] indirect handles actually implemented?

[Eric Auer <eric.auer@mpi.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Sean,

sorry for the late reply...

> "10320/loc" and data field with content such as:

If XML is okay for you to handle in the JAR...

At the moment, we use the HS only for publishing
object data, not for processing it. Otherwise it
might be useful to have something which allows
easier "reverse URL to handle lookup" than XML.

But as said - if XML works for you, okay for me.

> The chooseby attribute refers to a comma-delimited list
> of known method names.  These method names are...

This raises the question whether and when it is okay
for a method to fail. I assume locatt is mostly good
for enumerating entries by iterating over the id.

I think country could return "wrong country" entries
with lower priority than "no country" entries, but
maybe country could be considered a fail as soon as
no exact match WITH country is found: If none is
found, go on using the weighted method...

That way, you can even get by with only two methods:
"locatt" (exact match or none) and "closeto" (return
probabilistic pick from entries matching by country;
if none match, a probabilistic pick from the rest).

> hdl:123/doc1 resolves to:
> <locations relative-href="mydocument.pdf" >
> <repo id="hdl:123/repo1" />
> <repo id="hdl:123/repo2" />
> <repo id="hdl:123/repo3" />
> </locations>

That is an interesting idea but I think that various
"mirrors" might have different directory structure,
so the "several completely separate URLs per handle"
approach you describe above is probably better. Uses
less CPU but more storage space, of course, and it
does not support easy update when a whole mirror/repo
moves to another URL, but as far as I am concerned,
one of the main ideas behind the handle system is to
make NO assumptions about the mapping from handles
to values. If you introduce "repo handles" then you
introduce an assumption (that the relative HREF plus
the repo root URLs combine to the right URLs) which
introduces new risks... In general, I must say that
the repo suggestion feels like adding WAY too much
complexity to the handle system data and semantics.

Regards, Eric

> Hi, to follow-up myself: I notice that the
> HS_ALIAS *is* processed by both the browser
> plugins and the hdl.handle.net web proxy:
[overriding all indexes for the affected handle,
redirecting all queries to another alias handle]

>>>> For now, I did some experiments with putting a
>>>> hdl:... value into URL records of handles...
>>>> a browser with Handle System plugin (tested and
>>>> works w/ MSIE) then it should still be possible
>>>> to follow the recursion without having to install
>>>> special client or server side software...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH/iLJ99dkROyhRRsRApDfAKCcrZcvMhNwqm/6v/m54iEylhxvTgCfbmLx
iOVdppXCJytzpTDyXrvDXUs=
=G8+k
-----END PGP SIGNATURE-----


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