Graph vs DataSet

[gkellogg]

Although JSON-LD allows the expression of named graphs, the documents don't really describe the notion of a Dataset. I think we do need to talk about datasets, as this is at least required to align with RDF Concepts. However, the issue goes a bit deeper.

Generally, and RDF document expression a graph can be used to define the contents of a named graph, for example in SPARL as follows:

FROM <path/to/json-ld/doc.json-ld
FROM NAMED <path/to/another/json-ld/doc.jsonld>

In this case, each is presumed to be the serialization of a specific graph, and are either added to the default graph or a named graph depending on the use of FROM or FROM NAMED.

JSON-LD is different from TriG, in that it can't be determined simply by knowing the document type, whether it serializes a single graph or a Dataset. It's not clear to me how Dataset serializations are used in the context of SPARQL, as they are typically used to transfer an entire dataset, and not just a single graph.

PROPOSAL: normatively define the concept of a JSON-LD Dataset. In the context of a Dataset, a JSON-LD document including only a default graph serializes a Dataset with only a default graph. A JSON-LD document describing a default graph and/or one or more named graphs serializes a Dataset with default and named graphs.

PROPOSAL: define an alternate extension and mime-type for describing JSON-LD documents serializing Datasets, as distinct from the existing type which serializes a single graph. Named graphs used within a graph serialization are flattened into a single graph, and produce only a single graph when parsed.

[lanthaler]

To be honest, I don't really understand why we would need to "normatively define the concept of a JSON-LD Dataset". Isn't it enough to say in the section Richard is writing that a JSON-LD document serializes a dataset?

-1 for creating different mime-types for JSON-LD documents with/without named graphs. Every processor MUST expect named graphs when parsing a JSON-LD document. Of course a user can decide to flatten everything into a union-graph, but that decision is beyond the scope of the spec.

[lanthaler]

Issue #183: Is JSON-LD as a graph or a dataset syntax? was a duplicate of this:

The RDF WG has been concerned about whether or not a specific serialization that is capable of serializing RDF is thought of as a 'graph syntax' or a 'dataset syntax'. The group should come to a consensus on what JSON-LD is and clearly state that in the JSON-LD 1.0 Syntax specification.

Without knowing much about the background discussion, it seems to me that JSON-LD is a Dataset syntax because you can express multiple graphs in a single JSON-LD document. In JSON-LD, if you don't identify any particular graph, the 'default graph' is assumed. [@msporny]

[gkellogg]

This issue is an RDF one; when is it appropriate to use a Dataset document vs. a Graph. Similar to when to use Turtle vs. TriG. If JSON-LD can only be used where TriG is, then it might be at a disadvantage; my proposal whould allow it to be used in both contexts, but it might not be an issue, depending on how the RDF WG comes down on Turtle vs TriG. We should bring it up there, or get @cygri to weigh in and handle it here.

[tidoust]

The question on whether the definition is normative or informative depends on what refers to that definition in the doc. I take it the goal is to include a reference to it in the definition of a JSON-LD document. That makes it a normative definition.

+1 for the first proposal
-1 for the second proposal as I feel it would just be misused by authors in practice

[cygri]

I'm concerned that requiring different media types, depending on whether multiple graphs are present or not, would be confusing, and would often be deployed in an inconsistent way.

Saying that JSON-LD documents serialize datasets (which may contain only a default graph) seems reasonable to me.

[lanthaler]

OK, let's try it with a new set of proposals:

PROPOSAL 3: Normatively define the concept of a "JSON-LD document".

PROPOSAL 4: Add in the RDF-mapping section Richard is writing a statement that JSON-LD documents serialize datasets (which may contain only a default graph)

PROPOSAL 5: Do not introduce additional mime types or file extensions to distinguish between JSON-LD documents containing only a default graph from documents containing multiple graphs.

[msporny]

PROPOSAL 3: +1
PROPOSAL 4: +1
PROPOSAL 5: +1

[cygri]

Thinking more about it, I think there's a problem. Let's say someone wants to use only “flat” JSON-LD with only a default graph, and also offer content-negotiation via Turtle. Now he has a single resource with a graph representation (Turtle) and a dataset representation (JSON-LD). In current RDF-WG thinking, these are two completely different things.

[tidoust]

For my own understanding, the way to make JSON-LD a serialization of a graph and not a dataset would be to only allow the "@graph" keyword on a root level node definition, right?
Not that I'm proposing that as a solution at this stage, just trying to weigh in the different possibilities at hand.

[gkellogg]

Only allowing @graph at the root level only allows a single named (or default) graph. We could limit them to top-level node definitions, which could provide a way of identifying if a document serializes a graph or a dataset. I'm not sure how we would serialize a dataset containing only a default graph, as opposed to just a graph, or even if this is interesting. So, I think I would prefer the following:

+1 to PROPOSAL 3

PROPOSAL 6: A JSON-LD document which does no @graph, or containing @graph only as part of the top-level node definition without an @id property serializes a an RDF Graph.

PROPOSAL 7: A JSON-LD document containing any node definition having both @graph and @id serializes an RDF Dataset.

PROPOSAL 8: The @graph keyword may only be used in top-level node definitions, i.e., node definitions which are not the value of a property of another node definition.

My thinking on 8 is that this provides a simple way to determine if the JSON-LD document serializes a Graph or a Dataset, but has implications for framing.

[lanthaler]

Maybe I don't fully understand the difference between datasets and graphs. As far as I understand it, in RDF a graph is a set of triples and a dataset is a set of graphs with the restriction that there's only one unnamed graph (the default graph). So, for the consumer @cygri described above there would exist two options: a) use just the data from the default graph and ignore the rest or b) ignore the graph component in the extracted quads. In practice though it wouldn't be the client making that decision but the server.

The client just expresses his preference regarding the serialization format. It is then the server who decides whether to honor that request or not; and if it does, what "representation" of the data is returned (only default graph/union graph) in Turtle. So in my opinion that is not something JSON-LD has to care about. It's the implementers decision which would depend on the specific application.

Do I misunderstand something?

[cygri]

http://www.w3.org/2011/rdf-wg/track/issues/105 is related.

[msporny]

After discussing this with Ivan, there is a use case that plays into our decision - processing of large files. In this case, Steve Harris has said that he needs to know whether he is dealing with a graph or a dataset because it impacts the performance of the program (that is, which code path is executed - not having to deal with multiple graphs is faster).

If we care about this use case, we may tell folks that they MUST inject the following into JSON-LD documents that contain more than one graph and SHOULD NOT specify statements for any other graph than the default graph:

{
  "@container": "@graph"
  ...
}

That said, I don't think that JSON-LD is a data-dump format and I don't think we need to specify this. JSON-LD is a Dataset syntax that may contain one or more graphs.