JSON-LD resource containing named graphs

[pchampin]

When I post a JSON-LD resource containing named graphs, I get very different (and sometimes surprising) across different POD implementations. Note that I think the standard is currently silent on what should be the "correct" behaviour. Note also that this use-case is important if we want to use Verifiable Credentials (or Linked Data proofs) on Solid.

The example JSON-LD is available at

• https://p20n.inrupt.net/dagstuhl.jsonld (NSS, if am not mistaken)
• https://solid.champin.net/pa/dagstuhl.jsonld (CSS)

When you simply curl these URLs, you get

{
   "@context": { "ex": "http://example.org/ns/" },
  "@id": "ex:test",
   "@type": "ex:Graph",
   "@graph": {
     "@id": "ex:naughty",
      "@type": "ex:Trial"
   }
}

which expand the following dataset (in n-quads):

<http://example.org/ns/test> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/ns/Graph>.
<http://example.org/ns/naughty> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/ns/Trial> <http://example.org/ns/test>.

Now, curl -Haccept:text/turtle https://p20n.inrupt.net/dagstuhl.jsonld returns

@prefix n: <http://example.org/ns/>.
n:naughty a n:Trial.
n:test a n:Graph.

(note that the named graph has been collapsed into the default graph)

while curl -Haccept:text/turtle https://solid.champin.net/pa/dagstuhl.jsonld retuns

<http://example.org/ns/test> {
<http://example.org/ns/naughty> a <http://example.org/ns/Trial>
}
<http://example.org/ns/test> a <http://example.org/ns/Graph>.

which is not valid Turtle (despite a content-type: text/turtle in the response).
Note that it is valid TriG, which could be ok-ish if the content-type header was correct.

Conclusion: there should be a test for that in the test suite 😄

[pchampin]

Note that the Turtle/Trig issue of CSS is a known issue: CommunitySolidServer/CommunitySolidServer#1327

[michielbdejong]

Thanks for reporting! I created an NSS issue about the collapsing of the named graph ^

You're right, we should add this as a test (the ones in https://github.com/solid-contrib/solid-crud-tests/blob/main/test/surface/conneg.test.ts are clearly not sufficient) and also test what Solid-Nextcloud and TrinPod do with this.

[michielbdejong]

I just checked the spec; it indeeds requires storage servers to store RDF documents, and

An RDF document is a document that encodes an RDF graph or RDF dataset

So although we usually only store triples inside RDF documents (i.e. the document encodes a graph), a Solid pod server should also support storing an RDF Dataset as a non-container resource.

[michielbdejong]

See https://solidproject.org/TR/protocol#resource-representations
and https://www.w3.org/TR/rdf11-concepts/#managing-graphs
and https://solidproject.org/TR/protocol#resource-representations

[michielbdejong]

See also solid/specification#291