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

On 8 May 2013 21:48, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> 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.
>
>
The requirements for servers to switch to actually supporting JSON-LD
should be emphasised in the document.


>
> > 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?
>
>
No, I did mean JSON-LD clients. Previous discussions where people have been
emphasising the desire of Web developers to have a deterministic structure
for their JSON documents had me a little worried that there were going to
be services advertising JSON-LD support but really only supporting clients
sending them JSON-LD documents that use a particular structure (without the
services having the ability to transform other valid JSON-LD documents to
that structure or understand another JSON-LD document).


>
> > 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 every server and every client is JSON-LD aware then it is technically
fine, but if a server must/should generally recognise profiles then they
could be used to increase interoperability.


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

I still don't think that is safe to assume that a server will actually have
access to external contexts, just because it is part of the web. If the
profile support is completely optional then clients will not "usually" be
able to "rely" on the server to return documents that do not have external
contexts.


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

That is the main point of what I am getting at. Ie, ensuring that wherever
JSON-LD support is advertised that the documents will be interoperable with
other JSON-LD web services.


> 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?
>
>
I would like the section on profiles to change to a "SHOULD" requirement to
return results using one or more of the profile URIs that are given to
emphasise that servers "must, unless they have a good reason not to",
support those profile URIs when rendering the documents returned to
clients. Servers would then be expected to, in general, implement that
requirement, even if they may be forced to fall-back to another profile in
some exceptional circumstances (for example, if the server only serves
static files it should not be required to transform the document if it was
already valid JSON-LD as it has a reasonable excuse not to).

Clients could then use the profile mechanism to indicate that they do not
favour documents with external contexts, even if they would in most cases
be able to retrieve the context from the internet and/or merge it in before
storing the resulting JSON for later processing. A server could also use
that method to express its inability to retrieve context documents due to
firewall issues to process JSON-LD documents that are submitted to it,
possibly reducing the number of instances where clients submit JSON-LD
documents that contain external contexts. Neither of these requirements
would change the actual algorithms for processing the JSON-LD, but they may
still increase interoperability.

I would be satisfied if the following passage in Section E,

    "The profile parameter may be used by clients to express their
preferences in the content negotiation process."

was modified to something like:

    "The profile parameter MAY be used by clients to express their
preferences in the content negotiation process. If the profile parameter is
given a server SHOULD return a document that is structured based on the
profiles in the list which are recognized by the server."

I also have one minor editorial change to another sentence in Section E:

    "When processing the "profile" media type parameter, it is important to
note that its value is contains one or more URIs and not IRIs."

should be:

    "When processing the "profile" media type parameter, it is important to
note that its value contains one or more URIs and not IRIs."

Thanks,

Peter