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

> On Mar 31, 2024, at 1:51 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> … and it's not
> clear to me how much of JSON-LD's usage is "convert your ad-hoc JSON
> format to RDF" vs. "I want to simply express linked data using JSON".
> I'd say its more about the latter than the former.

"i want to simply express linked data using JSON" is where i'm coming from. :)

[consolidating several points which i think all have the same response]

> Sure, but it seems that you're analyzing that in a way that ignores
> the benefits. There are benefits to using externally referenced
> files... one of them being readability, no? Programming languages have
> #include / import for this very reason.

my approach for this profile was "starting from zero, what do i need to add
in from JSON-LD to serialize RDF the way i would in Turtle", and not "what
can i cut away from the full JSON-LD". for example, i went back and forth on
@vocab, but it seems too useful, and it can take the place of the empty prefix
in Turtle (at least the JSON-LD Playground doesn't seem to like an empty prefix
definition). 

one of the things i really like about Turtle documents is they're self-contained.
and i know if i see something in <angle-brackets>, it's an IRI ref; things not
in quotes with colons are compact IRIs; things in quotes are string literals; etc.
i'd like the same consistency of expression for this. coercions and other 
transformations i think can harm understandability, even if they may make the
JSON look less cluttery. but like Ivan, i also think about RDF in Turtle.
with only direct-replacement terms, compact IRI prefixes, @vocab, and @base
in an @context, external contexts don't seem necessary (this doesn't seem
to be a major pain point in Turtle).

my thinking is also that, like Turtle, it's easy for a human to make a document
by hand in a text editor (especially with a generic JSON syntax helper to not
end up with unbalanced quotes or braces or brackets or missing commas etc),
and for another person to read such a hand-made document. i imagine that, if
parsing these documents is no big deal, programmers would deal with the
fully-resolved RDF graph directly, with fully-resolved predicate IRIs, and
not care about the shape of the JSON it came in or what abbreviations were
used or any other aspect of the serialization.

as far as machine-to-machine transfer, it turns out gzip is way better than
any @context. :) of course you still want relative URIs when you can get them.
that's why my implementation doesn't do any compaction beyond optional URI
relativization (and optional don't-array-one-thing when rendering back to
JSON-LD, but that's more for people).

> Isn't the ideal outcome here a library of
> well-known vocabularies and JSON-LD Context files?

i think we have a library of well-known vocabularies (like FOAF, schema.org,
OWL, RDF/RDFS, etc). i don't think well-known JSON-LD context files are
necessary.

> Ah, but that argument exists in a vacuum, doesn't it? It's presuming
> that there isn't a strong argument for that decoupling, which there is
> -- reusability. If everyone has to become a JSON-LD Context author,
> we've failed to make this stuff easy to use, right?
> 
> I know the argument is: "Well, let's simplify the JSON-LD Context so
> anyone can write one in embedded form!", but that presumes a level of
> sophistication that I'd argue is still out of reach for most
> developers.
> 
> It's an equivalent argument to getting rid of #include / import in
> programming languages, isn't it?

as i'm imagining it, being a "context author" is the same as adding one or
more #include/import lines to your source files, because the only thing you'd
be doing in the context is defining compact IRI prefixes (and @base & @vocab). 
i definitely agree that if @context ends up needing to be more complicated
than that, where they require special crafting and skill to get just right,
it's definitely out of reach for most developers. but my hope is that a more
complex @context isn't needed.

> It would be really neat to have something like VanJS for RDF that
> let's you build/express a graph and then possibly "compile it down" to
> JSON-LD (which might use an external context, or it might embed a
> simplified context).

my implementation today actually takes a JavaScript Object (or Array) to merge
into a graph. you need to JSON.parse() an actual JSON document yourself (or
get it from a fetch response's json() promise) to give to my API. see my 
test.html. but the Object you give it doesn't need to be a tree — it could've
been manually assembled and be connected with cycles and stuff. if you used
fully-qualified IRIs for property names, or provide a fallback context/vocab
to interpret the property names, it'll merge that (cycles and all) into the
graph, and you can then ask for the graph as (not-compacted, no @context, but
possibly with relative URIs, and an @included for disconnected nodes) JSON-LD.

> I think many of us still think there is plenty of room to improve,
> perhaps even go at this from a wildly different direction. Clarifying
> who the target audience for this new approach/language will be
> important to do early on so it's clear who the stakeholders are.

i'm definitely scratching an itch i have, but i know others have different itches. :)

-mike

Received on Monday, 1 April 2024 01:35:57 UTC