[1] appears to say that your "not really useful" result is the minimum that a consumer should expect. I do not read the words as written to preclude a provider from providing additional triples in addition to this, but the spirit it suggests to me that the minimum is "right". So if you are a client worried about interoperability with a range of implementations, that's what you'd have to limit yourself to. In case the original framers think the intent was to actually prohibit anything beyond the minimum, here are the key phrases I pick out: - MAY... to enable clients to retrieve only selected property values [does sound like a prohibition on extra triples] - ...lets you specify the set of properties to be included in the response. [included, rather than something more limiting, sounds less prohibiting] - ...to include those properties [include again] Nowhere is a MUST NOT visible.
wrt CBD, since OSLC is not using OWL at all today, does not seem especially well bounded -- boils down to "give me all the guts of all blank nodes and reified statements, recursively", which seems fairly far away from the use case I think oslc.properties is intended for, namely allowing clients to tightly control the response size. So I'm with Arthur on that one. [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up#Selective_Property_Values Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
