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

On Sun, Mar 31, 2024 at 6:18 AM Michael C. Thornburgh <zenomt@zenomt.com> wrote:
> i'm sure i'm not the only one to have thought this, though.

I applaud your effort, Michael, especially since you've built
something to prove the benefits. The runtime size, and reduction in
complexity, is particularly impressive.

What you propose is more or less where we started, and over the years,
as the use cases have grown, that has led to the set of features that
are in JSON-LD today. I'll argue that I personally don't find about
60% of the feature set useful, but that's only because I'm not
regularly dealing with the use cases for those features. I'd even go
as far to say that some of the features in JSON-LD today, that we felt
would be heavily used, are not used nearly as much as we thought they
would be. HTML, C++, C, CSS, and Javascript suffer from the same
"bloat" problem.

You'll find that once a feature enters a language, it's exceedingly
difficult to get rid of it because there is always some community
nestled in the corners of the Internet that finds any particular
feature critical to their usage of JSON-LD.

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. For every feature we put
on the chopping block, we enter a painful discussion w/ a subcommunity
that would rather fork JSON-LD than see the feature go... even if we
assert that they can continue to use JSON-LD 1.1 because it /does/
have the feature they want.

It's a difficult task, but your profiling approach is the first step
towards cutting features. The next step, and this one is the hardest,
is convincing most of the JSON-LD community to switch to the reduced
profile. That can take years, with lots of effort, only to find out
that people would rather not risk missing a feature than saving
complexity or a few hundred KBs in executable size.

Another approach could be to do this in a statistical way... gather as
many types of JSON-LD examples in the wild and do an analysis on how
many features are used by tracing the hot paths in the source code. We
might find out that only 5% of the examples out there use a feature
that constitutes 15% of the code base... that would be a signal to
remove the feature in JSON-LD 2.0. However, ensuring a proper
statistical set would be difficult... there is a TON of schema.org out
there, and it's not possible to get a lot of "hidden" JSON-LD that
never hits the Internet.

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?

>   - complexity

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

>   - availability, especially when disconnected

Permanent caching (for well-known contexts), or caching addresses this issue.

>   - temporal decoupling

Digital signatures, via W3C Data Integrity, addresses this issue.

> * i'd use Turtle for pure Linked Data applications, but processing Turtle is a lot of code and complexity too, unfortunately

Yes, well the challenge has always been getting a larger developer
community to adopt the RDF languages that look foreign to them. Before
JSON-LD, they had been almost a non-starter for two reasons:

1. Most web developers were using JSON, and none of the languages
mapped cleanly to JSON.
2. RDF triples/quads don't map to most of the deployed database
platforms (SQL-based, or schema-less).

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. This is one of the reasons RDF stalled for a
decade or more.

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

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Sunday, 31 March 2024 15:25:08 UTC