Re: a simplified Turtle-like profile for JSON-LD

> On Mar 31, 2024, at 9:02 AM, Ivan Herman <ivan@w3.org> wrote:
> 
> Like Manu, I would love to see this type of JSON-LD profile coming up. JSON-LD, as it stands, is indeed fairly complex, and I have the impression that the complexity has become counter-productive: the idea was that “pure” JSON users would happily use this and do linked data without even realizing it, but the complexity of JSON-LD (probably primarily the  complexity of @context) has become an obstacle.

Indeed, the historical context is important. JSON-LD was coming about at a different time: there was no schema.org, and there were other initiatives that the JSON-LD 1.0 was looking to for adoption. The use case was to be able to give regular JSON have semantic meaning, so the context (which could be implicit) did the heavy lifting by defining complicated ways of conforming to existing JSON shapes, as well as being able to round-trip from RDF back into those complicated shapes. The idea was to make JSON-LD easy to use for end users and the expense of a more complicated tool chain for implementors of JSON-LD tooling. Indeed, many people continue to interact with JSON-LD as regular JSON.

But, as Manu suggested, time has moved on, and some of this complexity may be getting in the way of further adoption.

I think a mechanism can be exploited to allow an implementation to detect a simplified profile via the `@version` announcement feature. For example, adding something like `”@version”: 1.1e-1` could announce that this JSON-LD conforms to a simplified profile (or a new context keyword could be created) which would be allow it to be processed by any JSON-LD 1.1 processor as well as by a simplified processor.

But, note that some mechanisms, such as favoring terms over PNames, become important when processing the JSON-LD as JSON (or natively in JavaScript), but I don’t think this really changes the simplification itself, but may depend on more terms being defined in the context.

> Some immediate reactions:
> 
> - I think it would be very important to compare it to TriG rather than Turtle. JSON-LD is capable of expressing named graphs and that is important; do you have that as part of your profile? I must admit I always had issues with the way it is handled in JSON-LD.

Yes, but I’d like to see less use of `@graph` and rely more on `@included`. The `@graph` keyword should really be reserved for named-graph use cases.

> - Thinking in terms of a "profile" is probably a great idea; we may not want to throw the full JSON-LD away, and it is important that this is compatible with JSON-LD.

+1

> - Maybe it is worth contacting the semantic web community as well. The interesting question is whether those who are used to Turtle would consider this as an alternative to _replace_ turtle, knowing that, as you say, parsing this language is way easier, and it may bind Linked Data developments into the Javascript world easily (and more easily than JSON-LD). Judging for myself, who "grew up" with Turtle, I could never make the mental switch, and I just continue thinking in terms of Turtle when it comes to RDF. This profile may make me think...

Some things are more easily expressible in Turtle because it is a language with a defined grammar that allows for expressing things like lists, datatyped- or language-tagged literals, and in 1.2 Triple reifications and annotations. The proposals for doing this in JSON-LD (requiring some update now) would require using more expanded forms for this, which may keep JSON-LD (simplified) at a disadvantage compared to Turtle/TriG.

Gregg

> Thanks. I am curious to see where this may go.
> 
> Cheers
> 
> Ivan
> 
> B.t.w., there was an attempt to define a simple JSON serialization of RDF back in 2013, when JSON-LD became a standard, see [1]. I do not believe [1] ever caught on; that one was probably way too simple. It was more a nquads-in-json, rather than turtle-in-json... 
> 
> 
> [1] https://www.w3.org/TR/rdf-json/
> 
> 
>> On 30 Mar 2024, at 22:45, Michael C. Thornburgh <zenomt@zenomt.com> wrote:
>> 
>> i expected this to have come up already, but i didn't find this sentiment in
>> list archives (including the CG and WG lists) or GitHub issues. i'm sure i'm
>> not the only one to have thought this, though.
>> 
>> in the interest of brevity (and foreshadowing), i'll leave most of this as
>> bullets instead of prose.
>> 
>> * the full JSON-LD spec is large and complex, and isn't really "lightweight" (anymore)
>> * common implementations are huge (jsonld.js is 1.2 MB unminified, 287 KB minified, 84 KB min+gzip)
>> * "developer friendly idiomatic JSON":
>>  - counterproductive for pure LD applications
>>  - coercions and other mappings mean a casual human reader can't actually be sure what the document is saying (as RDF)
>>  - need to know the JSON schema (formal or informal) of every document type one expects to encounter
>>  - assumes it's too hard, or too much code, to parse and work with RDF directly
>>  - relative URIs are desirable; those still need to be resolved
>> * external contexts are problematic:
>>  - privacy
>>  - complexity
>>  - availability, especially when disconnected
>>  - temporal decoupling
>> * i'd use Turtle for pure Linked Data applications, but processing Turtle is a lot of code and complexity too, unfortunately
>> 
>> i propose a simplified profile of JSON-LD, inspired by Turtle:
>> 
>> * @context can only define an @base, @vocab, and compact IRI prefixes
>> * IRIs are always in an @id member (except for @type)
>> * one graph per document (no @graph, use @included if needed)
>> 
>> * no external contexts (documents are self-contained)
>> * no recursive compact IRI prefix definitions
>> * no coercions (except for @type itself) or other transformations
>> * no @index, @reverse, @nest, @protected, @propogate, @import, etc.
>> 
>> i'm calling this the "Terse" profile (since Turtle is the "Terse RDF Triple
>> Language"), identified (for now) by profile URI
>> 
>>    http://zenomt.com/ns/jsonld-terse
>> 
>> dereferencing that URI yields a more detailed and precise description of the
>> constraints.
>> 
>> my reference implementation for this profile is at
>> 
>>    https://github.com/zenomt/jsonld-terse
>> 
>> it's currently 201 lines of plain JavaScript (about 7 KB, GitHub says "170 loc")
>> with no external dependencies, and gzips to 2116 bytes. it parses and expands
>> conforming documents to interconnected Plain Old JavaScript Objects, resolves
>> relative URIs given the document's URI and any @base directives, and can
>> render a graph as a JSON-LD tree rooted from any node (optionally relativizing
>> URIs to a provided base, but not "compacting" with an @context) or as an array
>> of triples. there's a test page included in the repo, and it's published to
>> GitHub Pages so there's a live test page to play with.
>> 
>> limitations of this implementation: @list is intentionally not expanded to
>> an RDF List, since RDF Lists are harder to work with than JavaScript Arrays;
>> only URIs are processed, since web browser JavaScript doesn't provide native
>> IRI processing functions. IRIs in documents might end up transformed to URIs
>> according to the JavaScript `URL` API.
>> 
>> example Terse JSON-LD document:
>> ```
>> {
>>    "@context": {
>>        "@base":  "https://example.com/people/card",
>>        "foaf":   "http://xmlns.com/foaf/0.1/",
>>        "schema": "http://schema.org/"
>>    },
>>    "@id": "#me",
>>    "@type": ["foaf:Person", "schema:Person"],
>>    "foaf:name": { "@value": "Michael Thornburgh", "@language": "en-us" },
>>    "foaf:nick": "Mike",
>>    "foaf:depiction": { "@id": "mike.jpg" },
>>    "schema:worksFor": {
>>        "@type": "schema:Corporation",
>>        "schema:name": "Example Corp.",
>>        "schema:employee": { "@id": "#me" }
>>    },
>>    "@included": [
>>        { "@id": "", "@type": "foaf:PersonalProfileDocument", "foaf:primaryTopic": { "@id": "#me" } },
>>        { "@id": "_:b86", "foaf:knows": { "@id": "_:b99" } },
>>        { "@id": "_:b99", "foaf:knows": { "@id": "_:b86" } }
>>    ]
>> }
>> ```
>> 
>> equivalently expressed as idiomatic Turtle:
>> ```
>> @base           <https://example.com/people/card> .
>> @prefix foaf:   <http://xmlns.com/foaf/0.1/> .
>> @prefix schema: <http://schema.org/> .
>> 
>> <#me>
>>    a foaf:Person, schema:Person;
>>    foaf:name "Michael Thornburgh"@en-us;
>>    foaf:nick "Mike";
>>    foaf:depiction <mike.jpg>;
>>    schema:worksFor [
>>        a schema:Corporation;
>>        schema:name "Example Corp.";
>>        schema:employee <#me>
>>    ] .
>> 
>> <> a foaf:PersonalProfileDocument; foaf:primaryTopic <#me> .
>> 
>> _:b86 foaf:knows _:b99 .
>> _:b99 foaf:knows _:b86 .
>> ```
>> 
>> i hope this is of interest and use to others.
>> 
>> -michael thornburgh
>> 
>> 
> 
> 
> ----
> Ivan Herman, W3C 
> Home: http://www.w3.org/People/Ivan/
> mobile: +33 6 52 46 00 43
> 
>