> You may well be correct in your thinking that a similar approach
> offers a good compromise. In fact to my mind it may actually leave
> everyone with something that is significantly stronger than what we
> have currently and the fact is that the software required to support
> it already exists [1] modulo a few tweaks.
>
To expand a little on why I am coming to believe this approach has a
number of technical advantages, please consider the following
possibilities:
1] The same gateway server software that would run at http://lsid.info/
(for example) can also be run locally by any party.
2] A DNS entry can be established locally to return for all ip address
requests for hostname lsid.info their local gateway server?s address
instead - perhaps at the organization/geographic location/machine cluster
level.
3] An organization's local gateway server behaves in exactly the same way
that the centrally located gateway server does (which is why it can safely
provide that service in its stead), except that it may in addition have
access to data/metadata services that are behind the firewall for that
organization.
4] Any gateway server can safely & indefinitely cache and re-serve out all
LSID named data that it retrieves.
5] The result would often be fast single access dereferencing of those
data objects from local caches. There would also be far less traffic for
the central gateway service and privacy of the dereference requests are
guaranteed.
Programs have the option of either dereferencing LSID URNs using the
existing DDDS based resolution protocol (which is how the gateway server
software would do it) or by applying the appropriate transform to any LSID
URN to create a URL in the manner suggested by Henry and the ARK paper.
URN:lsid:myorg.org:namespace:objectid:v1 would morph to something like
http://lsid.info/lsid:myorg.org:namespace:objectid:v1 I would expect this
to be trivial to implement even in a Web 2.0 style application executing
in a browser.
Data providers need only continue to serve their data/metadata using the
existing standard LSID mechanism. All the requirements for a decentralized
naming and data/metadata service discovery scheme continue to be met (the
named objects remain independent of location and transport protocol &
there is no central point of failure) while at the same time the gateway
scheme would additionally provide _stable_ global and optionally local
http URL access to all accessible LSID named data objects and metadata
along with possible performance benefits.
Little new programming & standards work would be required.
Kindest regards, Sean
--
Sean Martin
IBM Corp