Re: JSON-LD 1.1 Design Principles - brainstorm

Thanks Adam!

Responses inline below.


On Thu, Jul 5, 2018 at 4:36 PM, ajs6f <ajs6f@apache.org> wrote:

> Hey, Rob!
>
> On the whole, I'm ready to subscribe to these principles. I do have a
> question or two that I'll ask mostly in the interest of furthering
> discussion:
>
> > * Require two organizations [not necessarily WG participants, or even
> W3C members] to have the use case.
> This isn't intended to require two orgs to support a case just to discuss
> it, right? You mean more in the sense of requiring support for the use case
> from the deliverables-- requiring support from two orgs for that, yes?
>

I think we should discuss all of them, but as a way to determine which make
it into the final specification I think we should have two organizations
willing to put their hand up and say that they have the use case.
Process wise, we can mark any features that don't make this pretty low bar
as at-risk, thereby encouraging people to let us know that they have it.
Some of the very specific graph oriented features might end up in this set,
such as using document relative URIs for predicates.


> * 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.
>
> Rob-- do you mean by "confidence" that every JSON-LD 1.1 document has
> exactly one mandated translation into RDF, or that it has at least one
> translation, or something else (or am I reading too much into your text)?
>

Certainly at least one. The only situation I think 1.0 doesn't handle is
the list of lists case. The cases it would exclude are the proposed text
direction pattern and my format+value+language proposal.

I /think/ (though not exhaustively) that it should be exactly one,
otherwise the process would not be deterministic.

Agenda coming shortly :)

Rob



> > On Jul 3, 2018, at 6:08 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
> >
> >
> > 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
>
>
>


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