TriG graphs in JSON-LD

[iherman]

I just try to test my understanding...

Consider the following TriG dataset:

@prefix a <http://example.org/a> .
@prefix b <http://example.org/b> .
@prefix c <http://example.org/c> .

<http://example.org/gr1> {
    a:something a:predicate "value1",
                b:predicate c:something1 .
}
<http://example.org/gr2> {
    a:something a:predicate "value2",
                b:predicate c:something2 .
}

The only way to express this in JSON-LD to repeat a @context, i.e.,

[
    {
        "@context" : {
            "a": "http://example.org/a",
            "b": "http://example.org/b",
            "c":  "http://example.org/c",
            "b:predicate" : { "@type" : "@id" }
        },
        "@id" : "http://example.org/gr1",
        "@graph" : {
            "@id" : "a:something",
            "a:predicate" : "value1",
            "b:predicate" : "c:something1"
        }
    },
    {
        "@context" : {
            "a": "http://example.org/a",
            "b": "http://example.org/b",
            "c":  "http://example.org/c",
            "b:predicate" : { "@type" : "@id" }
        },
        "@id" : "http://example.org/gr2",
        "@graph" : {
            "@id" : "a:something",
            "a:predicate" : "value2",
            "b:predicate" : "c:something2"
        }
    }
]

I.e., the context must be repeated.; there is no way of using a "global" context. I am not sure whether this is a problem in practice, but it may become one if JSON-ID is used for large datasets. In any case, this may have to be documented somewhere because it may not be 100% obvious for a first-time reader (best practices document?).

---

That being said: one way of handling that over the Web is if the server returns

[
    {
        "@id" : "http://example.org/gr1",
        "@graph" : {
            "@id" : "a:something",
            "a:predicate" : "value1",
            "b:predicate" : "c:something1"
        }
    },
    {
        "@id" : "http://example.org/gr2",
        "@graph" : {
            "@id" : "a:something",
            "a:predicate" : "value2",
            "b:predicate" : "c:something2"
        }
    }
]

and the @context is returned via an HTTP Link. According to section 6, the processor is supposed to repeat the context for each element of the array...

[dlongley]

This expresses the above using a single context:

{
  "@context" : {
    "a": "http://example.org/a",
    "b": "http://example.org/b",
    "c":  "http://example.org/c",
    "b:predicate" : { "@type" : "@id" }
  },
  "@graph": [{
    "@id": "http://example.org/gr1",
    "@graph": {
      "@id": "a:something",
      "a:predicate": "value1",
      "b:predicate": "c:something1"
    }
  }, {
    "@id": "http://example.org/gr2",
    "@graph": {
      "@id": "a:something",
      "a:predicate": "value2",
      "b:predicate": "c:something2"
     }
  }]
}

[pchampin]

... which unfortunately gives the wrong impression that there are three graphs in this dataset. And I'm assuming this is why Ivan didn't naturally came up with this solution.

Wouldn't the following also work?

{
  "@context" : {
    "a": "http://example.org/a",
    "b": "http://example.org/b",
    "c":  "http://example.org/c",
    "b:predicate" : { "@type" : "@id" },
    "graphs": {
      "@id": "@nest",
      "@container": ["@graph", "@id"]
    }
  },
  "graphs": {
    "http://example.org/gr1": {
      "@id": "a:something",
      "a:predicate": "value1",
      "b:predicate": "c:something1"
    },
    "http://example.org/gr2": {
      "@id": "a:something",
      "a:predicate": "value2",
      "b:predicate": "c:something2"
    }
  }
}

(the dev playground refuses it, but I'm assuming this is a missing implementations of the @graph container feature)...

If so, it might be worthwhile to document this "pattern", which might be more natural for some people?

[iherman]

@dlongley indeed, #128 (comment) also works but, just @pchampin remarks, it did not come naturally.

The point is a very long time grudge I have against the current syntax, namely the conflation of the term @graph for different usages. The outer level in this solution, in spite of its name, does not define any graph by itself, it is only a syntactic sugar to get around a problem imposed by JSON (and a problem that does not come in Turtle). The same is true when @graph is used for a single graph which has several roots (we referred to a 'bush'): it does not define a graph in the RDF dataset term and the result is not really different from the shorter and friendlier way when a tree-like graph is defined.

There is still an open issue (#30) but I do realize this is a battle I am loosing. I was already messed up by the duality of the @graph usage in the JSON-LD 1.0 days, and I remember I was not successful either.

@pchampin your example probably works, but shouldn't it be a "@nest":"graphs" on the top-level? I did not find a definition (or example) for "@id":"@nest" in the spec. But yes, otherwise the idea works, but it is just a (great) fig leaf to hide something that you are not supposed to see...

[dlongley]

Yeah, I've never been a fan of overloading @graph in this way, but there were concerns about the number of keywords in JSON-LD 1.0 and I think this was compromise that was somewhat awkward but fell out of other algorithms/approaches. Its use was also considered quite rare so less of a concern.

[gkellogg]

One thought that came up some time ago as to allow @container at the top level of a context, so you could have a processor interpret a top level object as a map of graph names.

{
  “@context”: {
    “@container”: [“@graph”, “@id”]
  }
}

[pchampin]

I like that, but would it generalize to any kind of container? If not, wouldn't it be more confusing than helpful?

[gkellogg]

Yes, it would generalize, but note that it may be more confusing than its worth, as every value which is an object would then be interpreted as a graph map, unless each term redefined it, or another context changed it.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Verify that @nest solution for #19 solves issue in #128 and defer until then {: #resolution14 .resolution}

View the transcript

TriG graphs in JSON-LD
Rob Sanderson: ref: #128
Gregg Kellogg: The concern is that TRiG does not use the value, insomuch as it’s just a set of graphs, names, etc, where JSON-LD has the object being the name of something in the default graph.
Ivan Herman: that’s what the issues says. What dave put in is a solution that technically works. It’s awful, and you can put in a fig leaf by aliasing @graph, but…
… what did come up is that Pierre Antoine put in a proposal for a solution and the syntax was wrong, but the way that it is now after our discussion this morning it probably works, but it is consistent.
… what he has here will work once we’ve done the cognates.
… that’s the figleaf
Gregg Kellogg: I like that more than one problem is solved with a single solution
Rob Sanderson: should we validate that it expands correctly one the fixes are in?
Gregg Kellogg: something might expand oddly…
Ivan Herman: expanding is for machines. I don’t care. But for humans, what P.A. has put in is fine.
Proposed resolution: Verify that @nest solution for #19 solves issue in #128 and defer until then (Rob Sanderson)
David Newbury: +1
Jeff Mixter: +1
Rob Sanderson: +1
Gregg Kellogg: +1
Ivan Herman: +1
Rob Sanderson: we should make sure it’s solved before closing
Harold Solbrig: +1
David I. Lehn: +1
Resolution #14: Verify that @nest solution for #19 solves issue in #128 and defer until then {: #resolution14 .resolution}
Adam Soroka: +1

[VladimirAlexiev]

Closing 141 as duplicate.
But we need a clarification in the section referenced there, a good example, and preferably a single way to do it.

[Cold-A-Muse]

Is converting TriG Graphs to JSON-LD supported? I couldn't find any documentation for this yet and ended up at this issue 😅

[gkellogg]

JSON-LD supports conversion to and from RDF datasets, as does TriG. This is the same for all RDF formats, either converting to graphs or datasets. The Playground doesn’t directly support it (PR to do so would be great), but you can try it on my distiller.

The key is they express the same abstract data model. In the algorithm, this is described using quads, so turn TriG into quads and use as input to JSON-LD fromRdf or do the opposite.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Leave #128 open until we can determine the effects of @container / @nest

View the transcript

TriG graphs in JSON-LD
Rob Sanderson: link: #128
Simon Steyskal: [ivan contemplating about issue 128]
Ivan Herman: there was some activity on this issue in February
… there is a comment on it from pchampin providing a solution and asking whether that’s valid
… idk though
Gregg Kellogg: I think I had an action on looking into interaction with nest/container stuff
… we def. need a dedicated section on graphs/trig etc. in the bpr document
Ivan Herman: then let’s leave it open for now
Proposed resolution: Leave #128 open until we can determine the effects of @container / @nest (Rob Sanderson)
Ruben Taelman: +1
Rob Sanderson: +1
Pierre-Antoine Champin: +1
Gregg Kellogg: +1
Tim Cole: +1
Simon Steyskal: +1
Ivan Herman: +1
Dave Longley: +0
Adam Soroka: +1
David Newbury: +1
David I. Lehn: +1
Resolution #6: Leave #128 open until we can determine the effects of @container / @nest

[dlongley]

Note that #19 may help resolve this.