- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Tue, 24 Apr 2018 11:22:15 -0700
- To: Linked JSON <public-linked-json@w3.org>
- Message-ID: <CABevsUHNovW_LitB18DfSsNepSVXYDOt4Z88xMMVJwzQg5oY4A@mail.gmail.com>
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 -- Rob Sanderson Semantic Architect The Getty Trust Los Angeles, CA 90049
Received on Tuesday, 24 April 2018 18:22:40 UTC