This document recommends best practices for building Linguistic Linked Open Data (LLOD) aware web services. LLOD denotes the representation of linguistic resources in accordance with linked data principles. These principles include that entities are to be identified by HTTP URIs providing RDF-based information about the entity including links to related entities. LLOD-aware services consume, process and produce such resources. LLOD-aware services are services that consume resources available as Linked Data as Input and output an RDF resource that can in turn be published as Linked Data.

This document was published by the Best Practices for Multilingual Linked Open Data community group. It is not a W3C Standard nor is it on the W3C Standards Track.

There are a number of ways that one may participate in the development of this report:

Use Case

Assume that we want to develop a service that consumes two terminologies that have been published as linguistic linked data using the guidelines published at http://www.w3.org/2015/09/bpmlod-reports/lld-exploitation/. The services is invoked by pointing it to two resources and is expected to return a set of links between the two terminological resources indicating which terminological concepts of the two terminologies should be regarded as equivalent. In our example, we will assume that the two terminological resources to be linked are:

Recommendations

We recommend building LLOD-aware web services using RESTful interfaces. Each resource provided by a REST-service is given its own URI. HTTP methods operate on resources in the following way:

We assume that each LLOD-aware service has a certain persistence layer in which snapshots of LD resources can be stored. This is because downloading resource just-in-time when the algorithm is actually invoked using a GET-method can take too long. Therefore, it is recommended to download and update relevant LD datasets asynchronously. There are multiple possible ways of providing RDF data to a service. For now, we assume that there is RDF-based metadata containing the location of an RDF dump in a http://www.w3.org/ns/dcat#accessURL field. This metadata should be the input to the service.

Results of the service should be returned in RDF/XML, Turtle-RDF or JSON-LD. Ideally, all three return types would be supported through content negotiation.

An example service for linking terminological resources

Our example service that we have implemented as a proof-of-concept to illustrate the best practice described here induces matches between two terminological resources in RDF and creates links between the associated concepts.

Terminologies are expected to use the lemon vocabulary for representing lexical resources in RDF. Comparison of entries is performed based on the entries lemon:writtenRep property. The concepts associated with entries as lemon:reference are regarded as equivalent if the concepts written representations match. A linking between the concepts is then created using skos:exactMatch.

Three basic operations are supported:
  1. Adding a new resource to the database
  2. Updating a resource in the database
  3. Retrieving links between resources in the database

We recommend building web services using a RESTful HTTP interface. The interface for our linking service is described in the following.

Adding a new resource to the database

HTTP request

A new resource is added by sending a HTTP POST request to 
http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/resource/{resourceURL}

HTTP response

Example call

Correspondingly, the call to ask the service to index the EMN dataset would be as follows: 
POST http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/resource/http://datahub.io/dataset/emn
Note: Support for this operation is deactivated.

Updating a resource in the database

HTTP request

An existing resource is updated by sending a HTTP PUT request to 
http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/resource/{resourceURL}

HTTP response

Example call

The call to ask the service to update the current version of the IATE dataset in the index is as follows: 
PUT http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/resource/http://datahub.io/dataset/iate-rdf
Note: Support for this operation is deactivated.

Retrieving links between resources in the database

HTTP request

A linking for all concepts in a dataset is retrieved by sending a HTTP GET request to 
http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/linking/dataset/{sourceURL}?target={targetURL}
A linking for a single concept is retrieved by sending a HTTP GET request to 
http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/linking/concept/{sourceURL}?target={targetURL}

HTTP response

Example call

The call to retrieve all the links between IATE and EMN would be as follows: 
GET http://sc-lider.techfak.uni-bielefeld.de/LinkingWebService/linking/dataset/https://datahub.io/dataset/emn?target=https://datahub.io/dataset/iate-rdf
And would return as result: 


european_migration_network:absconding                skos:exactMatch  iate:IATE-3544259 .
european_migration_network:accommodationcentre       skos:exactMatch  iate:IATE-878245 .
european_migration_network:acquisitionofcitizenship  skos:exactMatch  iate:IATE-3549121 .
european_migration_network:actofpersecution          skos:exactMatch  iate:IATE-3549123 .
european_migration_network:actorofprotection         skos:exactMatch  iate:IATE-3549124 .
…
where Note: N-Triples is the only output format currently supported by our implementation.