Pipeline that produces json-ld output

[fsasaki]

I tried the attached pipeline to produce json-ld output. I then get the error message "no reason given by request". If I change the accept header in the last pipeline step to text/turtle everything is fine. Is this a bug or of the pipelining? pipelining-request.txt

[ghsnd]

What I observe when debugging is that e-Translate - the last step - returns a 406 - NOT ACCEPTABLE response. This is probably because json-ld should in fact be application/ld+json. But the body and thus the reason is empty. The pipeline service returns the last response as is - so if there is no body in that response, pipelines won't add any.

If you send a request to the e-Translate serice directly with the same headers, e.g.:

curl -vX POST --header "Content-Type: text/turtle" --header "Accept: json-ld" -d @etranslatebody "http://api-dev.freme-project.eu/current/e-translation/tilde?source-lang=en&target-lang=fr"

where etranslatebody is a file containing the example from the API docs:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# > .
@prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core# > .
@prefix itsrdf: <http://www.w3.org/2005/11/its/rdf# > .
@prefix xsd: <http://www.w3.org/2001/XMLSchema# > .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# > .
<http://freme-project.eu/ >
  a nif:String , nif:RFC5147String , nif:Context ;
    nif:beginIndex  "0"^^xsd:nonNegativeInteger ;
    nif:endIndex    "11"^^xsd:nonNegativeInteger ;
    nif:isString    "translate me"@en ;

you get the same error, without body. Changing the accept header to application/ld+json -which should work - gives 500 Internal Server Error, this time with body:

{
  "exception": "eu.freme.broker.exception.ExternalServiceFailedException",
  "path": "/e-translation/tilde",
  "message": "External service failed with status code 500",
  "error": "Internal Server Error",
  "status": 500,
  "timestamp": 1444637497092
}

I have not further tested this, but maybe it is a bug at the e-Translation service?

[andish]

Tilde API for E-terminology and e-Translation not supporting json-ld. [simply because used .net library does not support this RDF serialization]. @jnehring Maybe FREME server could easily convert from json-ld to turtle before sending to tilde API?

[fsasaki]

I am not sure if this is an issue of the Tilde API. See attached pipeline. It does not encompass Tilde e-Terminology or e-Translation but e-Entity and e-Link. Still it producers the error "no reason ...". pipelining-request2.txt

[ghsnd]

OK, I think I see your point. When a service in the pipeline gives no reason for failure - like both examples - the response body of the pipelines response should also be a json object, like e.g.:

{
  "exception": "org.springframework.http.converter.HttpNotAcceptableException",
  "path": "/e-link/documents/",
  "message": "No reason given by service",
  "error": "Not Acceptable",
  "status": 406,
  "timestamp": 1444660396003
}

and maybe I should replace service with the "path" value.

[fsasaki]

But what is the reason for the failure in the pipelining-request2.txt ? Or: can you give a valid pipeline example that at the end produces json-ld?

[jnehring]

I did not try to reproduce the error but in general fremes e-Terminology endpoint supports json-ld. All input, plaintext, json-ld, turtle, ... is converted to turtle and then send to the Tilde API.

[ghsnd]

But what is the reason for the failure in the pipelining-request2.txt ? Or: can you give a valid pipeline example that at the end produces json-ld?

The reason is that json-ld is no valid value for the accept header. If you add the -v option to curl, you see the error code. You have to use the dev-version of e-Link though:

curl -vX POST --header "Content-Type: application/json" --header "Accept: application/json" -d '[ {   "method": "POST",   "endpoint": "http://api-dev.freme-project.eu/current/e-entity/dbpedia-spotlight/documents",   "parameters": {     "language": "en"   },   "headers": {     "content-type": "text/plain",     "accept": "text/turtle"   },   "body": "This summer there is the Zomerbar in Antwerp, one of the most beautiful cities in Belgium." }, {   "method": "POST",   "endpoint": "http://api-dev.freme-project.eu/current/e-link/documents/",   "parameters": {     "templateid": "3"   },   "headers": {     "content-type": "text/turtle",     "accept": "json-ld"   } } ]'  http://api-dev.freme-project.eu/current/pipelining/chain

This produces (correctly):

< HTTP/1.1 406 Not Acceptable
...
No reason given by service.

which means that e-Link does not accept the header accept: json-ld, but does not give an extra explanation on this, hence the "No reason".

If you change the accept header into accept: application/ld+json, it works:

curl -vX POST --header "Content-Type: application/json" --header "Accept: application/json" -d '[ {   "method": "POST",   "endpoint": "http://api-dev.freme-project.eu/current/e-entity/dbpedia-spotlight/documents",   "parameters": {     "language": "en"   },   "headers": {     "content-type": "text/plain",     "accept": "text/turtle"   },   "body": "This summer there is the Zomerbar in Antwerp, one of the most beautiful cities in Belgium." }, {   "method": "POST",   "endpoint": "http://api-dev.freme-project.eu/current/e-link/documents/",   "parameters": {     "templateid": "3"   },   "headers": {     "content-type": "text/turtle",     "accept": "application/ld+json"   } } ]'  http://api-dev.freme-project.eu/current/pipelining/chain

But maybe the "No reason..." is not a clear message. I will change it into something like "No further explanation given by path-to-the-service."

[jnehring]

But maybe the "No reason..." is not a clear message. I will change it into something like "No further explanation given by path-to-the-service."

Maybe add also: "The service reported HTTP Status 406 - Not acceptable. No further explanation given by ..."

[ghsnd]

Maybe add also: "The service reported HTTP Status 406 - Not acceptable. No further explanation given by ..."

OK

[jnehring]

Is this finished?