[Oslc-pm] shouldn't ems:observes have a Representation or Either

[John Arwe]

I'm fine with this change.
Where the inline/resource distinction really matters is (1) on update (2) 
for client complexity.

(1) inline (which core defines as using blank nodes) means the resource 
(here: the observation) has no constant unique identifier [heads tilt]. 
Blank nodes do have unique identifiers, but they are only valid within the 
context of the document they occur in.  The same blank node ID could be 
re-used in two separate documents, and the resources identified in each 
document might have absolutely no relationship to one another.  In the 
extreme case, I could use a constant string + a sequence number assigned 
by the serializer for each document (pretty much guaranteeing collisions). 
 So when you want to update the contents of one, it's harder because you 
cannot directly "point at" (identify) what it is you want to update.

(2) client complexity: if a generic resource reference is allowed, then a 
client has to be prepared to dereference it to find out what's in there. 
Smart implementations like ITM's will return the "extra" triples on the 
original request, optimizing out the "extra" fetches.  Updates are easier 
since there is a persistent unique identifier (inverse argument of the one 
above).


Best Regards, John

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20121029/d0e3625d/attachment-0003.html>