John, The tables are informal, but IMHO they should be aligned with the semantics of resource shapes. [1] At present, the semantics of resources shapes is also somewhat informal. I started to formalize their meaning by defining a corresponding SPARQL ASK query for each type of constraint. The ASK query would run on one or more graphs, depending on the constraint. For example, occurrence constraints involve a single graph, whereas read-only involves two - the before and after state.
Here's my interpretation of the tables: 1. Read/only - this applies to properties that cannot be changed by the client in a PUT. (your 1a) Some of these properties might be write once by the client at creation time, or they might be maintained by the service. If they are present in the PUT then they must be equal to the current value. This eliminates the burden of removing them from a GET response. 2. Occurs one-or-many - this means the property is always present (your 2c) 3. Both representations are valid (your 2b) That being said, there will always be server limitations, so a server has the right to refuse a request that violates size or time constraints that are unstated anywhere in an OSLC spec. [1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource Regards, ___________________________________________________________________________ Arthur Ryman DE, Chief Architect, Reporting & PSM IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: John Arwe <[email protected]> To: [email protected] Date: 04/13/2012 11:47 AM Subject: [oslc-core] what is the actual intent of resource definition table columns? Sent by: [email protected] Three independent threads (including a discussion in Automation yesterday) converged on the same Core section yesterday. I feel a bit like Alice in Wonderland on days like this, but once more into the looking glass... [1], under the "Defining OSLC Properties" heading, lays out the information we see in resource definitions, including the subject columns. It does not explicitly define the semantics for all of them however, which has led people to conflicting interpretations of the spec prose. More importantly from the perspective of some adopters, it does not lay out explicit testable compliance requirements on client and/or server implementations. While I'm providing specific examples below to show how this causes problems, I think we need to keep to the subject question and NOT attempt to answer all individual questions below now (perhaps we revisit those when/if text addressing the asserted need is drafted, as evidence of sufficient coverage). Neither Steve Speicher nor I could find anything in Core providing a more rigorous treatment after a good faith, but by no means exhaustive, search. While not all the interpretations below are equally likely, it is "pretty hard" to find anything those interpretations actually violate in Core specs, and some alternatives are opposing. Example 1: read/only. Interpretation 1a: This is "the client's view", i.e. the server MAY change the value but clients MUST NOT. Raises questions of "does client that constraint apply to POST-create", i.e. is this really trying to be "write-once"? What about a client performing a GET/add triple/PUT flow, does this require the client to remove the r/o property values (supplied by the server GET response) before sending the PUT request (even if the r/o values have not changed)? Interpretation 1b: R/O itself is nonsense (incoherent, if you prefer) - if it's truly read-only (implicitly: to all parties) then it can *never* have a value, so it's useless. Example 2: occurs one-or-many. Interpretation 2a: Both a client and a server MUST be capable of accepting a representation containing 30K triples using the predicate. Or 30 billion. [else: non-compliant] Interpretation 2b: A server MUST be capable of storing a representation (POST-created, PUT, PATCH) containing 30K triples using the predicate. Or 30 billion. [else: non-compliant] Interpretation 2c: A server MUST reject a representation containing zero of those triples, and MUST NOT produce such a representation itself. Interpretation 2d: A server MAY accept/store a representation containing zero of those triples, and MAY produce such a representation itself. Example 3: representation = Either Interpretation 2a: A server MAY be capable of storing a representation (POST-created, PUT, PATCH) containing the in-line resource as an object. Interpretation 2b: A server MUST be capable of storing a representation (POST-created, PUT, PATCH) containing the in-line resource as an object. [else: non-compliant] [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#OSLC_Defined_Resources Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
