Re: [External] JSON-LD 1.1 Design Principles - brainstorm

Rob,

Thanks for compiling this list. I think this is a great place to start and I tend to agree with all of your points. I do want to emphasize a point, that I think you alluded to in your email, but it very important to me.

There is typically conflict, or at least friction, between the principle of “ease of consumption”:

* We follow our overall mission of making production and consumption of linked data as easy as possible for the widest variety of web developers, with or without any experience of the underlying graph models.

And “following RDF principles/best practices”:

* The underlying data model is RDF.

We have seen this in some of our IIIF work. There is always a give and take and I personally feel that the latter (RDF as the underlying model) is more important than ease of use (within reason). I do not think our working group with have issues given all of our interests/expertise in RDF – this is only a real problem when developers/modelers not familiar with RDF start throwing their weight around.

Some issues are not a really a problem. For example, make every potential literal a list of one or more literals but others are more complicated and can result in weird outcomes when the JSON-ld is re-serialized as N-Triples, Turtle, or (god forbid) RDF/XML.

Jeff Mixter
OCLC Research

From: Rob Sanderson <azaroth42@gmail.com>
Date: Tuesday, July 3, 2018 at 6:08 PM
To: W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
Subject: [External] JSON-LD 1.1 Design Principles - brainstorm
Resent-From: <public-json-ld-wg@w3.org>
Resent-Date: Tuesday, July 3, 2018 at 6:08 PM


Dear all,

As part of our work over the next couple of years, we will have to determine whether some feature should be added to the specifications or not.  The earlier that we can come to some degree of consensus on how to make those subjective calls, the easier our discussions will be.  I have no illusions that we will be able to come to a deterministic process, but at least we can discuss some guiding principles to apply.

It would be great if we could try to brainstorm on the list some principles from our own experiences of using and implementing JSON-LD (or similar technologies), and then discuss them on the call on Friday.

Not as chair, just to start the ball rolling, some of the patterns that I have found very useful in other efforts:


* We follow our overall mission of making production and consumption of linked data as easy as possible for the widest variety of web developers, with or without any experience of the underlying graph models.

What it says on the tin :)

* Require real use cases, with actual instance data.

If decisions are tied to real world use cases, with actual data that you can point at, then that keeps the entirely theoretical, never useful in practice, features at bay.

* Require two organizations [not necessarily WG participants, or even W3C members] to have the use case.

Just because one organization has a use case, doesn't make it good for interoperability.  A minimum of two organizations should support every new feature, though that doesn't have to be via membership on the WG.

* "As simple as possible, but no simpler."

A simpler solution is better than a more complicated one that achieves the same ends.

* Consistency is simpler than exceptions.

20 inconsistent but individually easy to understand solutions are worse than 2 more complicated but all encompassing solutions.

* Given the option, optimize for data producers and consumers before library implementers.

Or, simplicity / usability is determined by the audience (data producers and consumers) not by the specification text. There will be MANY more data producers than consumers, and MANY more consumers than library implementations. Thus we should make it was easy as possible to create data and consume it, at the expense of a more complicated specification.

* Provide on-ramps.

A solution that can be implemented in incremental stages is better than a solution that is all or nothing, as not everyone needs every feature but many people need various parts.

* Define success, not failure.

We should define things in terms of what it means to be conformant, rather than what is not conformant.  The fewer constraints we require, the easier to have non-breaking changes in the future and the easier it is to have experimentation.

* The underlying data model is RDF.

If a feature comes up that can't be modeled with RDF as the underlying abstract data model, then we refer the feature to a future RDF WG for potential inclusion at that time. Similarly, we should ensure that the features of RDF are expressed in JSON-LD, to ensure that data can be round-tripped with confidence through different serializations.

* Follow existing standards and best practices, where possible and where they do not conflict with other principles.

Between invention and reuse, pick reuse... unless that reuse would demonstrably harm adoption by being more complicated than necessary.


Thoughts? Further ideas for principles to discuss?  How did the 1.0 WG make scoping decisions, and was that process seen as effective and fair?


Rob

--
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049