W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2018

Ecosystem issues for JSON-LD 1.1

From: Robert Sanderson <azaroth42@gmail.com>
Date: Tue, 24 Apr 2018 11:22:15 -0700
Message-ID: <CABevsUHNovW_LitB18DfSsNepSVXYDOt4Z88xMMVJwzQg5oY4A@mail.gmail.com>
To: Linked JSON <public-linked-json@w3.org>
Dear all,

The following issues came out of a discussion with Dan Brickley of Google
and Charles McCathie Neville recently of Yandex last week.  This is my
summary, and does not necessarily reflect the opinions of Dan or Chaals, or
their employers.

* Practical backwards compatibility with 1.0
It is important to ensure that the next version of the specification is
backwards compatible with the current 1.0.  There are hundreds of millions
of sites using JSON-LD 1.0 that we cannot afford to invalidate over night.
Processing a 1.0 context in a 1.1 environment should have the same results,
in practice even if there are bugs in the 1.0 spec that get fixed.  Or,
another way, if schema.org put @context:1.1 in their context document, no
one should really notice. One idea was to scrape the JSON-LD out of the
Common Crawl [1], and use it as a testbed for validating the effects of
algorithmic changes in practice.  Any incompatibilities need to be very
carefully considered with strong justification.

* Complexity / Value
As with any transformation or mapping language (comparisons were drawn with
GRDDL [2] and XSLT [3]), there is a trade off between complexity and
expressivity.  As we add more features to the @context mapping language, we
add the ability to express further use cases, but at the cost of fewer
complete implementations.  This can be managed in several ways, including
structured documentation and explicitly calling out what systems MUST or
SHOULD implement and the consequences of not doing so, however better yet
is to not add the complexity in the first place.  A systemic approach to
evaluating the costs and advantages of adding features should be adopted
for the working group. Each feature should have stronger use cases for when
it is important to use, rather than just examples of its use.

* Context Best Practices in a Distributed Ecosystem
Regardless of the functionality available, how _should_ contexts be
deployed that take into account the wide variety of use cases and
environments? This needs to encompass the possibility that browsers would
process JSON-LD embedded in HTML to make additional functionality available
for the use. Consider the gmail (and now in Outlook) email actions [4] ...
but encountered in pages by the browser.  If contexts are to matter beyond
a flag for further processing, there needs to be a method for not
performing a massive denial of service attack on an unsuspecting server as
every web browser suddenly starts pinging it for its context.

As we move towards a new Working Group, these sorts of systemic issues
should be taken into account as well as the details of the algorithms and
context/framing description languages.

Thoughts on these sorts of issues would be appreciated!


Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049
Received on Tuesday, 24 April 2018 18:22:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:51 UTC