[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] indirect handles actually implemented?
On Apr 10, 2008, at 15:23 , Eric Auer wrote:
"10320/loc" and data field with content such as:
If XML is okay for you to handle in the JAR...
We now have a simple, lightweight XML/SGML parser in the client jar
file. I think it makes sense for handle clients to use XML for some
of the higher level data structures rather than invent our own encoding.
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.
I'm not sure of any format that would allow for easier reverse lookup
in the handle database and that would allow the flexibility we get
from using XML.
I think it would make sense to have a separate index that allowed for
things such as reverse URL lookup. Separating the indexing function
from the handle server database would allow for an index that covered
more than one handle server, as well as indexing other types of
information.
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...
I think it is always assumed that any method, except 'weighted', can
fail. The weighted method will only ever fail if there are no
locations at all.
If a <location> has a country attribute then it must be either a
positive or negative match (not just lower priority). The only way a
location with a country attribute would be returned is if:
1) the client 'matches' that country
2) all other locations have a country attribute that doesn't match,
so we fall through to 'weighted' selection
3) the "chooseby" attribute of the handle has been overridden to not
choose by country
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).
I don't think "locatt" could be a replacement for country, because the
country is calculated by the client's IP address (or plugin software
if using a native handle resolver client).
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.
I agree that the relative-href part is probably not a good idea. But
the <repo> mechanism would be helpful in a lot of places (DSpace, for
example) if it used something like OpenURL or URL templates in general
(with the handle itself as a parameter).
It is really a general mechanism of saying "this object lives at
repository X" and letting repository X locate the object within its
own filing system rather than having to store a static URL with an
http domain + file path in every handle.
Thanks for your feedback, we really appreciate it even if it takes me
far too long to reply :)
Thanks,
Sean
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info