| |
Comment: |
From Frank:
I'd like to share two use cases for the return of a alias-EPI a an
alternative to returned referral resolver services:
* Two EPIs are independently generated for the same resource.
If we associate a resource with some bio-object, the it happens that two
different researchers "name" the same object independently from each
other. When this is discovered, one needs the option to consolidate the
metadata and policy "underneath" one of those EPIs to lessen the burden
of maintenance and to ensure consistency. A common solution is to assign
a "master-EPI", and to let the other EPIs refer to that master-EPI when
it receives resolution requests.
* Moving metadata management to a different admin domain.
When a global naming system and global resolution frameworks are used,
like DNS, HandleSystem or LSID, then the EPI's URI will include
information about the naming server, i.e. the "prefix". This prefix in
the name is commonly mapped to a real, physical identifier service that
is used to administer the metadata/resolution bindings and such a server
will be part of a certain admin domain. When the owner/administrator/PI
of the individual identifier binding moves/changes-jobs, she often wants
to take the data-objects with her to the new admin domain as well as the
ability to administer the identifier bindings. Unless that user "owns" a
whole prefix, the administration of the identifier has to remain at the
original naming server. This is often not an acceptable solution both
for the naming server admin domain as well as the original identifier
owner. A common solution is to create a new EPI with a prefix that is
maintained in the new admin-domain, and to use that for all the
bindings/resolution information, and to add to the original EPI a
one-time referral to the new EPI.
The semantics for the referral fault is something like:
"The resolver service that was asked for the resolution was unable to
provide the caller with the resolution information. However, the
resolution service has alternative information returned which the caller
may optionally use to try to resolve."
It seems to me that returning a alias-EPI fits very well within the
referral fault semantics. Furthermore, the processing of a returned
alias-EPI seems completely equivalent to the processing of the original
EPI with some checks for looping and such.
Enjoy the F2F without me.
|
