LSID

Any organization with a bit of work or outsourcing could provide their existing databases via LSID.

The "server" side of this resolver solution is called an LSID authority.

Each servlet parses the method, arguments, and target LSID (which may be a SOAP parameter or part of the URL) from a request.

Consider a Caching Proxy Resolution Service that was also the direct authority for a certain set of LSIDs.

If you know about a meaningful relation between two LSIDs, you should describe it in the metadata, regardless of who issued the LSIDs.

The Caching Proxy Resolution Service also serves as a method to monitor LSID traffic in an organization.

Certain data sources will require only mapping from LSID to URL, if each piece of data has a URL that can retrieve it in a standard format.

The data itself is immutable, per the LSID specification, so cached data never expires but may be removed by local cache policy enforcement.

Metadata about a particular LSID consists of a collection of RDF statements.

getAvailableOperations returns a WSDL document describing locations at which data and metadata for the LSID may be retrieved.

We implement the LSIDDataService interface and pass it as a parameter to the DataServlet servlet class provided by the LSID package.

This capability is a prerequisite to fully achieving the level of collaboration and data federation enabled by the LSID Resolution Network.

The lookup procedure compares the authority and namespace components of the LSID to mappings in the registry.

Using the target LSID, the servlet looks in the service registry to determine which configured service implementation to invoke.

That means that the metadata about an LSID is the perfect location for storing transient information about the object in question.

The objects in RDF are either URIs (in which case you can use LSIDs) or so-called "literal" values that may or may not be typed.

As the service handles more requests for external LSIDs, the cache grows, allowing increasingly rapid access to external data.

A given LSID Resolution Service need only consist of an Authority Service.

Unlike the data associated with an LSID, metadata can expire.

Finally, we'll see how enterprises might integrate these components to form an Enterprise LSID Resolution Network.

Location independence and the guarantee of immutability of LSIDs make them perfect candidates for database cross-references.

An ASDL document contains a list of available LSIDs and their corresponding data and metadata locations.

Security in the LSID Resolution Network is handled at the protocol level.

Utopic visions aside, LSID Resolution will become more useful when more providers use LSIDs to expose their data.

The first, illustrated in Figure 3, is to provide an LSID-based view of a local data store.

The LSID Client Stack and Server Framework handle these two cases.

To avoid any potential for error, you should always represent LSIDs in RDF using their canonical form: lower case.

All LSIDs with authority myauth will be handled by the Local LSID Services. All other LSIDs will be handled by the Caching Proxy.

In addition to this symmetry, the client applications can access external LSID-based data sources such as PDB and Gateway-based services.

The caching proxy can process any LSID that is resolvable via DNS, so its list of known URIs is technically the global space of LSIDs.

Once you have done this, you should have a file called sprot40. dat in your lsid directory.

If you decide to test with an LSID that has associated data, you can try the command

For more information about the LSID protocol, resolution model, and