RDF-ISSUE-128 (mandatory-profile): Mandatory profiles for JSON-LD document interchange - by Peter Ansell [JSON-LD Last Call 1]

RDF-ISSUE-128 (mandatory-profile): Mandatory profiles for JSON-LD document interchange - by Peter Ansell [JSON-LD Last Call 1]

http://www.w3.org/2011/rdf-wg/track/issues/128

Raised by: Markus Lanthaler
On product: JSON-LD Last Call 1

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

Received on Wednesday, 8 May 2013 11:01:08 UTC