[oslc-core] what is the actual intent of resource definition table columns?

[Arthur Ryman]

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 <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
04/13/2012 11:47 AM
Subject:
[oslc-core] what is the actual intent of resource definition table 
columns?
Sent by:
oslc-core-bounces at open-services.net



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
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net