>> "The provider can return an OSLC Error resource to indicate to the consumer that the query will not succeed as constructed." > There should be some more explicit way to determine what properties are present, e.g. via a ResourceShape.
I sense an underlying difference of opinion on clients' responsibilities, that might have knock-on implications for providers. Or maybe it's "how should I read 'can'?" Resource shapes are optional today. So telling even the best-intentioned clients to rely on them for this/any purpose will leave gaps. By the same token, requiring all clients to write the code to introspect providers in order to get predictable results has its own issues. There is a barrier-to-entry issue (raising the lower bar if we do this), and metadata (resource shape/etc) issues like availability (is it even present, given that it's optional) and durability (I can upgrade an implementation between client requests, so does a client have to re-introspect before each request in order to get predictable results?) I'm sure we'll see, over time (even the near-er term) cases where existing clients are pointed at new providers where (due to bad/incomplete doc, etc) there is a mismatch in capabilities. I read "can" as a MAY, without the potentially confusing "normative caps" occurring in informative text. It sounds to my ears Arthur like you'd prefer to either remain silent or impose something whose spirit is MUST/SHOULD NOT return an error result. I think we need to allow providers wishing to do so the flexibility to indicate the provider Knows For Sure that the client's request semantics could not be carried out (because that provider never exposes the properties being queried for). By your arguments on SPARQL OPTIONAL, it sounds like a 4xx response would not be a good choice for that indication ... and that agrees with my intuition. I am going to be after the flexibility to introduce something in the future; a Warn header being the current front-runner in my head (and then clients can decide whether or not they check for it), but I'm not particularly attached to the mechanism. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
