[Handle-info] Service Typing of Handle Values

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

Hi All:

Sorry to bang on so. Am just slow in figuring things out.

So, I was wondering if with the development of the type registry [1,2] we
are beginning to see the handle system migrate from a data repository to a
service repository.

This from Sean's post [2]

    "We are building the ability to select between multiple locators for an
object into the handle proxy (or any handle client, really). To use this
feature you will be able to add a handle value with type "10320/ loc" and
data field with content such as:

<locations>
<location id=0 href="http://uk.example.com/";; country="gb" weight=0 />
<location id=1 href="http://www1.example.com/";; weight=1 />
<location id=2 href="http://www2.example.com/";; weight=1 />
</locations>

"

What this means is that the proxy will be able to deliver a dynamic redirect
service, i.e. a preferred URL based on runtime computable criteria. (Btw, I
really don't understand what "or any handle client, really" means. Seems
like one is assuming mindshare.)

And a service like this is undoubtedly a good thing for many users. As far
as it goes. Because I don't see how it goes any further. Without something
else we've lost access to the data primitives - the URIs in the markup.
Seems that to gain access to those one would need to understand the XML and
to parse the XML client side, or else to call up another proxy service, or
perhaps the primitives could be separately recorded in the handle record
(possible but unlikely).

With access to the data primitives another 3rd-party could make immediate
use of that info and deliver a new service. It would mean, however, having
some idea as to what the semantics of those primitives are.

I'm just trying to get a clearer picture of what is the value proposition of
handle. While there may be no restrictions placed on what can be put in the
handle value (or how it is typed), nevertheless if there is a move towards
allocating service types then there will be a strong interest (temptation,
even?) in using those and there will thus necessarily be a "lock in" to
those services.

So, to put it very crudely I guess my concerns are:

    1. "My" data/"Your" services

    2. Data/Service hard wiring

which (taking the URL example) leads to the following comparison ('scuse the
RDF/N3):

    1. Data exposed as primitive:

        <> h:type "URL";  h:data <http://...> .

    2. Data embedded in "opaque" carrier

        <> h:type <hdl:10320/loc>;  h:data "..."^^rdf_xml:literal .

How can the data uploaded into the HS be reused? And what's the point of
opening up handle (facilitating data access) if the data is just a service
input "blob"? Or, if the data in the HS is generally bound to service type
inputs then what are the reuse prospects for that data?

Hope I'm not being too awkward.

Cheers,

Tony


[1] http://www.handle.net/mail-archive/handle-info/msg00303.html
[2] http://www.handle.net/mail-archive/handle-info/msg00276.html


********************************************************************************   
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