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

Also a general set of comments about JSON-LD complexity...

I believe that a lot of the complexity / richness of JSON-LD comes from
different scenarios as to who has control over what: the ontology, the
context, and the json structure/properties.

For example, in IIIF (https://iiif.io/) we have full control over all
three, and the ontology is a side effect of the desired structure rather
than vice versa. We use JSON-LD features for integration purposes rather
than that we expect people to process the API as a graph. IIIF uses Web
Annotations and Activity Streams as core parts of its suite of APIs, and
JSON-LD lets us be interoperable and consistent, despite differences in
those specs. If push came to shove and a slimmed down version 2 didn't
support the features we use, IIIF would likely just drop the semantic side
of the specs all together.

Conversely in Linked Art (https://linked.art/) we do not have control over
the ontology -- it's an ICOM and ISO specification that has made various
non-developer-friendly choices over the 25+ years of its development,
including having arbitrary numbers for predicates, inconsistent naming and
a proliferation of specific predicates that could all have been one. Using
the context functionality we can "fix" those "mistakes" (from the
developer's perspective) and present a set of JSON document structures that
are easy to work with and simultaneously conform to the ontology. If push
came to the same shove, the linked art community would have a much harder
decision -- give up the standard ontology, versus give up JSON-LD, versus
give up the developer friendly serialization that makes Linked Art useful.
My guess would be that we would give up the ontology and mint our own with
a cross-walk back to the standard if that would keep developers
sufficiently happy, or if not (e.g. not being able to rename the numbers
away) then we'd drop JSON-LD and define the transformation between ontology
and JSON.

(These are not meant as threats, just observations in support of Manu's
very correct assertion that once complexity is in, it's Very hard to get
rid of because someone wanted it there for some real reason, and there are
implementations and tests for it... otherwise it wouldn't have gotten into
the spec in the first place)

An interesting distinction between the two is a choice about URIs as
vocabulary values. In IIIF, they are @vocab aliased away into strings that
end up looking a lot like enums, whereas in Linked Art we made the choice
to not even shorten the URIs with namespaces in order to make it easier to
dereference them without having to process the context. Those opposite
choices are the right choice for the particular usage and community -- IIIF
is all about the JSON, Linked Art is focused on making the global cultural
heritage knowledge graph.

Now the fact that JSON-LD supports both choices leads to complexity in the
algorithms for sure, but the end-user of the data ... the developer ... is
happy. This follows the W3C hierarchy of constituencies -- end users
(application devs) over authors (data producers) over tool makers (json-ld
libraries) over specification authors (Gregg et al) over theoretical
purity. (https://www.w3.org/TR/design-principles/#priority-of-constituencies
)

Rob


On Mon, Apr 1, 2024 at 7:30 AM Ivan Herman <ivan@w3.org> wrote:

> (This is not an answer to this particular mail, just general thoughts on
> the full thread.)
>
> Manu wrote at some point:
>
> > 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 think that is a very important point, because the result of the
> discussion would become
> drastically different. Michael did say:
>
> > 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".
>
> If the target audience may be the current RDF community (and I would count
> myself
> to be part of that, i.e., I would like that direction) then the primary
> question is
> why would the RDF community need this. Manu rightfully said:
>
> > Do we know how many Turtle developers there are... or how disgruntled
> they are?
> > Most everyone I know that uses Turtle/TRiG likes using the language.
>
> I think most of the core RDF developers/users are all Turtle users today,
> which may answer
> Manu's first question. But the second question is definitely to be
> answered.
>
> In other words, we have to find out what the problem is that would be
> solved by this
> turtle-like JSON-LD. Trying to find an answer, I would look into two areas
> (there might be more):
>
> - While RDF developers often use languages like Python, Java, or Rust,
> there is a separate
> community trying to create a Javascript/Typescript environment for RDF,
> much like we have
> RDFLib for Python, or Jena for Java. For Javascript there is an rdfjs
> community[1] but I
> am not sure if there is a stable library like RDFLib that everyone is
> using. (Maybe n3[2] it is, but
> it is also not complete). But that community might be interested in a very
> natural, quick, and small
> foot-print RDF serialization in Json, which may be more efficient than
> handling Turtle/TriG. I would
> definitely look for a parsing directly into the rdfjs data model.
>
> - There are number of json based non-sql databases out there, and I am
> sure some of those are used
> to store RDF data. I am not familiar with that world (although I used
> mongodb for some toy projects at a time).
> There again, having a natural, quick, etc, route from RDF data to the
> database might be a really
> interesting proposition.
>
> Thanks
>
> Ivan
>
>
> [1] https://rdf.js.org
> [2] https://rdf.js.org/N3.js/
> [3] https://rdf.js.org/data-model-spec/
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +33 6 52 46 00 43
>
>
>
>

-- 
Rob Sanderson
Senior Director for Digital Cultural Heritage
Yale University