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

> On Mar 31, 2024, at 8:24 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> The runtime size, and reduction in complexity, is particularly impressive.

i was recently inspired by Tao Xin's [VanJS](https://vanjs.org). though
not quite to his extreme — i still want my code to be pretty. :)

> I'd love to see a serious attempt at CUTTING features in JSON-LD for a
> presumptive JSON-LD 2.0 specification, though admit that the chances
> of that actually happening are slim to none.

i think that so long as JSON-LD wants to be "you can have your ad hoc
JSON format and eat your RDF cake too" (or the other way around), most
of the features will need to remain.

> It's a difficult task, but your profiling approach is the first step
> towards cutting features.

as Ivan suggests in his next message, i think considering this profile
as a replacement for Turtle (that also happens to be valid JSON-LD)
might be more fruitful than trying to convince the JSON-LD community
to give up most of their features.

> I did see a few "external contexts are problematic" assertions that
> have had quite a bit of thought put into them over the years, just
> briefly mentioning these since the community continues to
> misunderstand some best practices. I was also confused by some
> assertions.
> 
>>  - privacy
> 
> Why is having an external public context a privacy issue?

triggering an externally-visible action (like loading an essential external
context that's marked "do not cache") reveals that i'm parsing some document
right now, even if getting that document didn't involve a network fetch or i
got it some time ago. in other words, external contexts could be used as
activity-tracking beacons.

>>  - complexity
> 
> This isn't really about external contexts as much as it is the JSON-LD
> language, right?

the main point of this claim is that, if external contexts are allowed, then
processing any document is at least a _potentially_ asynchronous operation
instead of a synchronous and purely local manipulation of data on hand. and 
that potential asynchronous operation entails the intrinsic complexity of the
web and the Internet (IP, DNS, TCP and/or QUIC, TLS, HTTP), vs "these bytes here".

>>  - availability, especially when disconnected
> 
> Permanent caching (for well-known contexts), or caching addresses this issue.

caching solves the problem as long as you've had a chance to (know to) retrieve
them already. i find the notion of "permanent caching (for well-known contexts)"
a little distasteful just on principle (since it divides contexts into 
"well-known" and "hoi polloi" classes) and implies some contexts as de facto
parts of the language. but at least not being able to retrieve a context (and
therefore not being able to parse a document) is no worse than not being able
to retrieve a CSS for your HTML document in practice (while your HTML _should_
still be usable without the CSS, that's not actually the case for modern web
pages anymore).

>>  - temporal decoupling
> 
> Digital signatures, via W3C Data Integrity, addresses this issue.

the part of this issue that concerns me more is the "HTML and CSS are out of 
sync" problem, which to be sure is an edge case. it's just an edge case that 
doesn't need to exist in the first place. :)

> So, the value proposition wasn't there for most developers, the RDF
> community was asking them to switch away from JSON and to get a graph
> database, simultaneously.

i'm hoping my implementation's approach of "Plain Ol' JavaScript Objects that
point directly to each other" could be both palatable and a convenient way to
work with a graph in JS. i know this doesn't conform to the standard APIs.

>> i hope this is of interest and use to others.
> 
> It is of great interest, thank you for putting in the effort to try to
> figure out a simpler profile for JSON-LD. I'll be interested to see
> if/where this gets traction. As I said, JSON-LD could benefit from a
> haircut... it's just not clear where to start chopping. Your efforts
> might give us a place to start. :)

i hope so, and i'm glad i'm not the only one thinking about this problem.
pointers (like Ivan's suggestion to engage the semantic web community) are
appreciated.

-mike

Received on Sunday, 31 March 2024 19:33:22 UTC