RE: RDF-ISSUE-128 JSON-LD-1.0 Last call comment: Mandatory profiles for JSON-LD document interchange

Hi Peter,

I’ve opened RDF-ISSUE-128 [1] to keep track of your request. Below is my personal opinion about the concerns you raise.

On Wed, 8 May 2013 13:42:30 +1000, Peter Ansell wrote:
> 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.

The JSON-LD specification specifies a serialization format. It therefore makes no statements about server behavior at all. The profile parameter doesn't change the semantics of a JSON-LD document, it just specifies additional conventions or constraints a representation adheres to.


> 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.

On the Web, no such things as a "guarantee" exist. The whole idea is to have a loosely coupled, distributed system. Contracts are negotiated at run-time. If a server doesn't support a specific profile it can either respond with a different one (which will be visible in the Content-Type header) or respond with an HTTP status coding signaling an error. This is exactly the same as with media types in general.


> 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.

Yes, that's a goal. And if servers and clients process the JSON-LD as JSON-LD and not as JSON that's also the case.


> 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

This is to foster adoption. The paragraph you are citing is about "Interpreting JSON as JSON-LD" in that case you don't even uses JSON-LD's media type but you reference a context using an HTTP Link header.


> 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.

The feature is typically intended to work the other way round. A server exposes a certain profile to allow legacy clients to continue to process the responses as plain old JSON. It doesn't make much sense for a server to switch to JSON-LD if it doesn't understand it.


> 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.

I think it should be clear if you are talking about JSON-LD aware applications that that means that the data is processed as JSON-LD and not as JSON. The profile is just a hint. It can be safely ignored if you process the data as JSON-LD:

"A profile does not change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation"

 
> 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.

I completely disagree. Profiles are optional and can be safely ignored. "JSON-LD complaint servers and clients" must be able to process every JSON-LD document. But again, since we are just defining a serialization format we do not define "JSON-LD complaint servers and clients". If you look at the API spec, you will find the definition of a "JSON-LD processor" and to be compliant, it *must* be able to interpret every valid JSON-LD document (in fact, it completely ignores profiles). So I do not see any problem here.


> 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,

I assume the previous content type would be application/json. So that's fine. 


> 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

You mean for every JSON-LD-aware server, right? If it is JSON-LD aware, why should it be restricted to a single profile?


> 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 they cannot interpret any valid JSON-LD document, they are not JSON-LD-aware. They are just JSON clients that happen to request a different profile.


> 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.

That's true but again, we are not defining server behavior. 


> 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.

A client can easily transform a document to get rid of the external contexts before storing it for later processing. Since we are talking about Linked Data, I think it's safe assume that clients have internet access. If not, than they can't even access a the document itself in the first place and so putting requirements on server implementations wouldn't help either. It's the same as storing an HTML page locally. If you don't store things like external JavaScript files as well, you can't use it locally.

So summed up, IMO you cannot call something which can't process all valid JSON-LD documents JSON-LD-aware. Thus, specifying a mandatory profile that servers must support only helps clients which are *not* JSON-LD-aware. That's what profiles are for in the first place.

How would you define a "JSON-LD complaint server"? Just a server that is able to return JSON-LD data in a certain profile? How would you find out that you are talking to such a server? IMO you would do exactly what you describe as being impracticable:

 1) send a request asking for a specific profile in the Accept header
 2) check the profile in the Content-Type header of the response

A server that is not a "JSON-LD complaint server" would return a different profile in step 2.
So, what exactly do you think is missing in the current specification?


Regards,
Markus


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


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 8 May 2013 11:48:33 UTC