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

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.

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.
- 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.
- 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...

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