Re: [oslc-core] JSON-LD of compact resources

[John Arwe <johnarwe@us.ibm.com>]

This draft is confused/ing.

1: R vs C(R)

If I have a resource identified by the URI R, and it has a corresponding core:Compact resource identified by the URI C(R), then there is just no way that "GET R" should *ever* be returning the representation of C(R) and status code 200, which section 5.1 allows.  209 or 3xx, fine.

It's debatable (since R != C(R) ) whether or not the "Prefer compact" approach is even within the envelope of what Prefer is for: "The Prefer request header field is used to indicate that particular    server behaviors are preferred by the client, but not required for   successful completion of the request."  If the client requests a representation of R, and (via prefer compact) the intent is that it receives another resource entirely (C(R), versus some different subset of the state of the resource identified by the request-URI, i.e. R), *at the HTTP level* only the draft 209 status code or the existing 3xx codes allow returning C(R).

I think you would be within all the specs if it was written differently, e.g.

If 209 (or 3xx)

- Must preference-applied, Must Location, response body must be a representation of C(R)

If 200

- Must provide link header corresponding to the triple R, compact, C(R)

Once you state that R and C(R) are different resources, you lose any claim to be able to say that GET R returns 200 and representation C(R), *regardless* of preferences.  This is different from the RFC's return=representation cases where HTTP says that "a" representation [of something] is returned, and the preference expresses [of what] ... e.g. 201 responses.  The [of what] for 200 is well-defined in HTTP already, preferences don't get to rewrite that.

2: Media types

If you use generic media types ... application/json, application/ld+json ... then a server satisfies the media type contract by returning ANY valid JSON or JSON-LD, respectively.  If the client expects it to have any specific content, it is outside the bounds of the media type registration: the server asserted it's generic, nothing else.  If you want the server to assert that it's YOUR kind of JSON/LD, you need something more (profile response header seems to be the vogue in IETF, and would be usable here), or your own media type.  I'm guessing in this case that the profile URI would be the URI identifying a resource shape.... presumably the one in your spec.

------------------

As another alternative to 1, you might consider RFC 6570.  Let the server expose a URI template for its compact resource URIs.  As a Link header for the general case, and possibly as a core predicate for containers/their members to cover the common case where all the container's members have a common template (so one URI, whose content can be cached, just like we've discussed for slimming down JSON-LD representations generally).

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario