json-ld / ndjson-ld Goto Github PK

On the call, I think we discussed that blank nodes would be scoped to each individual record, however this would make using this format in a manner similar to N-Quads unable to represent shared blank nodes.

Most serializations scope blank node identifiers to the file. In this reckoning:

{"@id": "foo", "prop": {"@id": "_:bar"}}
{"@id": "_:bar", "prop": {"@id": "baz"}}

could be semantically equivalent to:

{"@id": "foo", "prop": {"@id": "_:bar", "prop": {"@id": "baz"}}}

Otherwise, there would be no way to state this using independent records.

Proposal: blank node labels are shared across all documents within a stream.

Similar to how it's done in the YAML-LD spec, the spec should mirror the JSON-LD API WebIDL definitions, and largely delegate each line to the JSON-LD API.

This requires extending the JSON-LD Internal Representation with the notion of a document type with a sequence being an array of documents with a document consisting of either an array or map.

From json-ld/yaml-ld#63, there are at least three different formats that could serve as the basis for this work:

• NDJSON – newline delimited JSON, which prohibits the use of newlines within a given record. Media type is specified as application/x+ndjson, which is not recommended. It purports to be a living spec. Previous support for comments between records, now removed.
• JSON Lines – the basis from which NDJSON was forked. Apparently not intended as a spec. No suggested media type, although issue comments suggest application/x+jsonlines and application/x-json-stream. Otherwise, virtually indistinguishable from NDJSON.
• LDJSON – Aside from the obvious confusion of LDJSON-LD, I can't find anything definitive other than the Wikipedia entry.
• JSON Text Sequences – RFC7464 – This has the obvious advantage of being an RFC with a registered media type application/json-seq. Allows newlines within JSON records, but requires records be proceeded by an ASCII Record Separator (%x1E). A disadvantage is that this is not as amenable to presentation or editing by a common text editor.

I have seen a number of possible use cases expressed in various repos, email threads, etc.

Given that we could use these to help us gather the specific set of requirements that any new specification/standard needs to support - perhaps we should start here.