Web services on LLD

From Library Linked Data
Jump to: navigation, search

Authors: Kevin, Joachim

Generic Linked Data implementations offer access through resolvable URIs and links to other (RDF) data, which facilitate resource browsing. Sometimes generic LD implementations provide SPARQL endpoints, permitting users to query the data freely, and/or downloads of complete datasets to be loaded locally into a triplestore. Unfortunately, many LD implementations, for a variety of reasons, can not or have not provided SPARQL endpoints (or bulk downloads). Some LD implementations might not use a triplestore in the back-end, which is seen as a natural precursor for a SPARQL endpoint; for others, security or robustness considerations preclude such a feature in production use. Not offering these options can hinder further resource discovery. And, even when they are provided, application programmers who want to use the data from a LD implementation to enhance their own projects, therefore, must often master Semantic Web techniques and tools before they can do anything useful with the published data.

A number of organizations have mitigated these issues by providing Linked Data Web Services (LD Web Services) from their LD implementations to foster greater resource discovery. A few of these, but not all, are:

These LD Web Services host some form of an application programming interface (API) that enhances discovery and use of resources. Geonames and VIAF, for example, provide an XML-based search API. That this is XML-based is notable: LD Web Services might do well to make use of existing and current standards and technologies. SRU/CQL is offered by VIAF; alternatively, LC's ID service publishes an ATOM feed for updated information. Agrovoc and STW offer ways to discover resources based on relationships in the data, among many more web services. VIAF, LC's ID, and STW offer autosuggest services for resources, delivering JSON responses ready for consumption in AJAX browser applications. Agrovoc and STITCH/CATCH include support for pure RDF responses. Some services provide full-fledged SOAP APIs, while others support a REST approach. Most LD implementations that offer LD Web Services document their services. By focusing on method parameters and response formats to provide enhanced discovery, these LD Web Services diminish, if not eliminate, the requirement that data be stored in a triplestore. Furthermore, because web service APIs are common, web services can lower the barrier to entry.

Therefore, whether in the absence of a SPARQL endpoint or in conjunction with one, future LLD efforts should encourage the development of LD Web Services, including their full documentation, to facilitate greater access to the data offered by a LD Implementation.

Future LLD efforts might also explore establishing a formal core set of web services - just as traditional library-specific protocols have been developed for resource discovery and sharing, such as OAI-PMH, SRU/CQL, etc. - to be offered by Library LD implementations. For example, Library LD implementations focusing on thesaurus and vocabulary data might provide some type of "label" service, which would attempt to match a string to some label of a resource and, upon a positive match, the URI and preferred label of the matched resource would be returned. Alternatively, a web service might offer further resource discovery based on a specified relationship parameter. Bibliographic LD implementations (see Cluster BibData) might provide for example a "name" web service that would return URIs of bibliographic resources associated in some way with the supplied personal name. Should a formal core set of web services be pursued by the LLD community, the types of web services currently offered by LD implementations and how those web services are presently used will directly inform the types of "core" web services to be defined.