ISSUE-128: Mandatory profiles for JSON-LD document interchange - by Peter Ansell

LC2 - Ansell - Mandatory Profiles

Mandatory profiles for JSON-LD document interchange - by Peter Ansell

State:
CLOSED
Product:
JSON-LD Last Call 2
Raised by:
Markus Lanthaler
Opened on:
2013-05-08
Description:
This was raised by Peter Ansell on public-rdf-comments (http://lists.w3.org/Archives/Public/public-rdf-comments/2013May/0028.html):


The JSON-LD-1.0 W3C Last Call Working Draft 11 April 2013 specifies an
optional profile parameter to attach to the content type to signal the
profile for either a document sent by a client with a request or to signal
the desired response profile in a request to a server [1]. However, there
is no specification of any mandatory profiles that must be supported by
JSON-LD servers. Hence, there is no guarantee that the document will be
acceptable to the server when sent in that profile, or whether a response
will actually be returned in the profile that was requested, or whether it
will be returned in a form matching any of the standard profiles.

The introduction section specifies that one goal of JSON-LD is "to build
interoperable Web services", implying that the results from one web service
can be used to easily create JSON-LD documents compatible with another
parties web service. However, the design goals section then specifies that
one of the desired goals for JSON-LD is to avoid modifying documents at all
in most cases [2], to avoid having to modify servers or clients to support
JSON-LD specifically. This implies that servers and/or clients may not be
aware of JSON-LD, so a client who is aware it is using JSON-LD may still
need to serialize their document in a manner specific to the server they
are going to submit it to, possibly outside of one of the standard profiles
and hence not using a standard algorithm. This makes it very difficult to
determine what JSON-LD profile to submit to an arbitrary servers or send to
arbitrary clients if they potentially do not accept all profiles, which
seems to be the anti-thesis of a goal for "interoperable Web services", as
each client must be still aware of the implementation used by each web
service to submit valid requests.

The JSON-LD specification must therefore outline a minimum set of standard
profile for all JSON-LD compliant servers and clients to allow consistent
interchange of valid JSON-LD documents between all complying clients and
servers. Not having at least one mandatory minimum profile would make it
impossible to implement a consistent document interchange strategy from
RDF-aware clients to JSON-LD servers and vice-versa, which MUST be a goal
of the W3C RDF Working Group, and should be a goal of a large Linked Data
ecosystem.

Adding a requirement for one or more mandatory profiles would require
modifications to servers to actually process requests and responses using
the JSON-LD algorithms, but it would not necessarily require changes to
existing clients, as they may be able to continue submitting requests using
the previous JSON format based on the design goal for zero edits, and
continue requesting responses using the previous content-type to signal
that they are not JSON-LD aware. New, JSON-LD-aware, clients however, could
then be assured that their generic JSON-LD libraries could generate
acceptable documents for any service without hand-compiling to JSON to be
compatible with particular services, and they could be assured that if they
ask for a document in a mandatory profile that they could interpret the
result consistently in a simple manner. If the server did need to change to
either accept or respond with valid JSON-LD, then the zero edits design
goal would not be relevant in those cases.

At least one mandatory profile, in order to be interoperable with different
server implementations, must not include external contexts, as that would
require servers to be able to access external websites in order to complete
the JSON-LD processing algorithms. Requiring servers to be able to access
arbitrary external contexts will always be incompatible with a large number
of server/corporate firewalls. Doing so would also require clients to have
internet access to be able to interpret JSON-LD documents that are
processed offline, which need not be a requirement as there are profiles
that do not require this in the current specification.

Thanks,

Peter Ansell

[1] http://www.w3.org/TR/2013/WD-json-ld-20130411/#iana-considerations
[2]
http://www.w3.org/TR/2013/WD-json-ld-20130411/#design-goals-and-rationale
Related Actions Items:
No related actions
Related emails:
  1. Re: Resolutions for features at risk [JSON-LD] (from danbri@danbri.org on 2013-06-02)
  2. Re: Resolutions for features at risk [JSON-LD] (from sandro@w3.org on 2013-05-31)
  3. Re: Resolutions for features at risk [JSON-LD] (from gregg@greggkellogg.net on 2013-05-31)
  4. Re: Resolutions for features at risk [JSON-LD] (from sandro@w3.org on 2013-05-31)
  5. Resolutions for features at risk (from markus.lanthaler@gmx.net on 2013-05-31)
  6. Re: Official response to RDF-ISSUE-128: JSON-LD Mandatory Profiles (from ansell.peter@gmail.com on 2013-05-22)
  7. Official response to RDF-ISSUE-128: JSON-LD Mandatory Profiles (from msporny@digitalbazaar.com on 2013-05-21)
  8. JSON-LD Telecon Minutes for 2013-05-21 (from msporny@digitalbazaar.com on 2013-05-21)
  9. Re: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129 (from gregg@greggkellogg.net on 2013-05-19)
  10. RE: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129 (from markus.lanthaler@gmx.net on 2013-05-19)
  11. Re: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129 (from gregg@greggkellogg.net on 2013-05-19)
  12. RE: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129 (from markus.lanthaler@gmx.net on 2013-05-19)
  13. Re: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129 (from ansell.peter@gmail.com on 2013-05-19)
  14. Agenda: JSON-LD Telecon - Tuesday, May 21st 2013 (from msporny@digitalbazaar.com on 2013-05-19)
  15. RE: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129 (from markus.lanthaler@gmx.net on 2013-05-18)
  16. JSON-LD Telecon Minutes for 2013-05-14 (from msporny@digitalbazaar.com on 2013-05-14)
  17. RE: Agenda: JSON-LD Telecon - Tuesday, May 14th 2013 (from markus.lanthaler@gmx.net on 2013-05-13)
  18. Agenda: JSON-LD Telecon - Tuesday, May 14th 2013 (from msporny@digitalbazaar.com on 2013-05-12)
  19. RE: RDF-ISSUE-128 JSON-LD-1.0 Last call comment: Mandatory profiles for JSON-LD document interchange (from markus.lanthaler@gmx.net on 2013-05-09)
  20. Re: RDF-ISSUE-128 JSON-LD-1.0 Last call comment: Mandatory profiles for JSON-LD document interchange (from gregg@greggkellogg.com on 2013-05-09)
  21. Re: RDF-ISSUE-128 JSON-LD-1.0 Last call comment: Mandatory profiles for JSON-LD document interchange (from ansell.peter@gmail.com on 2013-05-09)
  22. RE: RDF-ISSUE-128 JSON-LD-1.0 Last call comment: Mandatory profiles for JSON-LD document interchange (from markus.lanthaler@gmx.net on 2013-05-08)
  23. RDF-ISSUE-128 (mandatory-profile): Mandatory profiles for JSON-LD document interchange - by Peter Ansell [JSON-LD Last Call 1] (from sysbot+tracker@w3.org on 2013-05-08)

Related notes:

Official response here: http://lists.w3.org/Archives/Public/public-rdf-comments/2013May/0149.html

Manu Sporny, 21 May 2013, 17:01:58

Fixed in https://github.com/json-ld/json-ld.org/commit/e6a7c851db88eb89a59d0540bf7c10bf31776f6c

Markus Lanthaler, 31 May 2013, 19:16:38

Display change log ATOM feed


Guus Schreiber <guus.schreiber@vu.nl>, Chair, Ivan Herman <ivan@w3.org>, Sandro Hawke <sandro@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 128.html,v 1.1 2014-07-09 12:17:56 carine Exp $