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

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

> I think the case where the 
> provider returns a JSON representation that looks like a compact 
> resource - but isn't - is practically zero. 

Based on the resource shape in the draft
spec, it's exactly one.  All properties are optional so every JSON
object satisfies the shape.

You're right in the sense that clients can choose to rely on duck-typing: if it has the properties the client cares about, then treat it as a compact resource's representation.  In that case the server assertion adds only (1) ability for the client to have a higher level/quicker test (2) some level of social expectation of who's at fault in cases where the two fail to interop because the client's expectations about the properties are unmet.  If the server serves "random" JSON, and it didn't assert anything else, interop will fail but (to a neutral third party) there's no reason to think either side needs to change; that might be resolved via other social means however - if the server's manufacturer also asserts that it supports the OSLC specs, assigning fault is easier.

On a separate point, fine to say "if the client obtains the URI via a rel=compact link header", but when doing so you also need to consider the else path.  If someone hands me a URI as a URI, how do I know (by interacting with it) that it identifies a compact resource (and what "the other" "most related" i.e. uncompact one is)?

Best Regards, John

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