No query output for Turtle and RDF/XML when result set contains any blank-node cycles

[namedgraph]

http://graphity.dydra.com/graphity/homepage-test/query#constructnowhere 13 results

versus

curl -X POST -d @construct-nowhere.rq -H "Content-Type: application/sparql-query" -H "Accept: text/turtle" "http://graphity.dydra.com/graphity/homepage-test/sparql" 0 results

construct-nowhere.rq:

PREFIX  sioc: <http://rdfs.org/sioc/ns#>
PREFIX  rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX  foaf: <http://xmlns.com/foaf/0.1/>
PREFIX  gh:   <http://graphityhq.com/gh#>
PREFIX  dct:  <http://purl.org/dc/terms/>
PREFIX  bibo: <http://purl.org/ontology/bibo/>
PREFIX  xsd:  <http://www.w3.org/2001/XMLSchema#>
PREFIX  gp:   <http://graphity.org/gp#>

CONSTRUCT 
  { _:c0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> foaf:Document .
    _:c0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> gh:ArticleItem .
    _:c0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> gp:Item .
    _:c0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> sioc:Item .
    _:c0 foaf:primaryTopic _:c1 .
    _:c0 gp:slug " "^^xsd:string .
    _:c1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> foaf:Document .
    _:c1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> gh:Article .
    _:c1 foaf:isPrimaryTopicOf _:c0 .
    _:c1 dct:title " " .
    _:c1 dct:description " " .
    _:c1 foaf:homepage _:c2 .
    _:c1 foaf:maker _:c3 .}
WHERE
  {  }

[lisp]

i must be overlooking something, as i seen neither something which could be bound, nor a query parameter in the example. what did you intend to have happen with these two requests and what does it have to do with bindings.

[namedgraph]

Sorry, nothing to do with the bindings -- I updated the title. The issue is that there are no results returned over HTTP.

[lisp]

i believe both of the implied scenarios to involve http. would a more accurate distinction be between a curl request and the web ui?

[namedgraph]

Yes

[artob]

I'm looking into this...

[artob]

Confirmed this as a bug: with otherwise identical curl commands, Accept: application/rdf+json yields results, Accept: text/turtle does not. I'm presently investigating the cause of this.

[artob]

We have confirmed that this is a bug in the underlying Raptor RDF library that we use to serialize Turtle and RDF/XML specifically. We've reported the issue upstream as Raptor issue 0000596.

As described in our Raptor bug report, the issue concerns cyclical blank-node relationships, as follows:

_:g1 foaf:primaryTopic _:g2 .
_:g2 foaf:isPrimaryTopicOf _:g1 .

At present, any result set that contains such cycles will result in no output when requesting Turtle or RDF/XML output. (Other RDF serialization formats, such as RDF/JSON, are not affected, however.)

We are still investigating the options for resolving this bug.

For Turtle, we will in the interim switch to using another serializer which does suffer from this problem.

For RDF/XML, there is no immediate workaround; one not-so-satisfactory option would be to configure the serializer to not use so-called "abbreviated" RDF/XML, which would result in more verbose output but would not suffer from the problem with cyclical nodes. From previous experience I suspect, however, that the non-abbreviated RDF/XML would break your XSLT stylesheets.

[namedgraph]

Hm, I'm pretty sure this was working before the latest upgrade(s).

How would the non-abbreviated RDF/XML look like? New rdf:Description per each triple? That could still work as I'm applying pre-processing that groups triples by resources before doing the main transformation.

[artob]

Hm, I'm pretty sure this was working before the latest upgrade(s).

As I commented in 0000596, this does indeed seem to be a regression bug. Data files containing such cycles are not all that rare.

How would the non-abbreviated RDF/XML look like? New rdf:Description per each triple? That could still work as I'm applying pre-processing that groups triples by resources before doing the main transformation.

Yes, the non-abbreviated RDF/XML is triple-by-triple instead of grouped-by-resource, so it does yield a new rdf:Description element per triple. Since you say you can work with that for the time being, we will go ahead and configure your host accordingly as a workaround for this issue.

[artob]

Your host has now been configured to emit unabbreviated RDF/XML as a temporary workaround to this issue, until it can get properly resolved.

We will also shortly add support for a content-type parameter, application/rdf+xml;abbrev={1,0}, whereby you can explicitly control whether you want abbreviated or unabbreviated RDF/XML output.