[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Nick

With regard to the "chooseby" attributes on the basis of which the
resolution of a Handle can be selected out of a range of URLs:

Sean indicated that CNRI would be interested in further feature
additions. The FRED project I worked on last year scoped
infrastructure for repository federation in the e-learning domain, and
one of the crucial use cases for repository federation is appropriate
copy delivery. (And after all, that's what the proposed locator
parameters are doing.) We went with OpenURL as a solution, talking to
Handles as the registry of available URLs per identifier. But our
analysis of what parameters resolution can be determined by may be of
interest: we found that in that domain, geographical location was only
one of the possible considerations.
Thanks for the comments and for describing the FRED project. I have a good feeling of deja vu .

CNRI is involved with a digital library project for DTIC (Defense Technical Information Center)
where we implemented an OpenURL contextual linking system to provide a generic, extensible query
mechanism to an extensible underlying set resources and services. These resources and services consist
of handle values/digital objects and our services are digital object disseminations.

All of the OpenURL entities ID and data payloads make use of handle identifiers to identify (and de-reference)
clients, services, resources, types etc...
Like you, we found that the OpenURL provides the appropriate level of flexibility, extensibility, and
specificity needed to target resources and services while also expressing the context of the requests.

We are in the process of considering developing a generic OpenURL contextual linking service
(basically an extensible service capable OpenURL resolver) as a new type of proxy to the
handle system.

The use of OpenURL will be especially valuable as a generic syntax for expressing queries to handles
that have handle types registered in the handle type registry that we are in the process of developing
at the moment.

The scenarios we gathered (with OpenURL illustrations of the
parameters involved) are at
http://fred.usq.edu.au/appropriatecopyscenarios.html

The conclusions we came up with were that the required parameters, in
order of priority, were:

1. Requester's institutional affiliation
1a. Alternative: Individual Requester identity (but that requires
non-trivial mapping: an email address domain will need munging to
translate to a choose-by attribute)
2. User accessibility (visual, colour, hearing, physical)
3. Physical location
4. File format
5. Content language
6. Version of content
We had to implement a policy system to control who could access and search what but
your institutional affiliation maps logically well to an access right group membership.

Some of these are too complex for a simple XML lookup to handle
(version), and are more appropriately dealt with behind an OpenURL
black box or another custom resolution service. Some of these can
I think this is right. In many of our OpenURL requests, the OpenURL actually targets services which
have no XML serialization. (e.g search engine).
already be dealt with in the HTTP protocol (language, possibly
accessibility), and need not be realised as distinct URLs. But for
portal-based access in particular, affiliation (and thus
authorisation) is more important than geographical location; and
geographical location can be more granular than countries.
The big advantage of the OpenURL approach is the ability to modulate the information
that is passed through to the contextual linking service. Of course this results in different contextual
results but that might be what is appropriate at that moment.


Thanks,

-Christophe





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