[Oslc-Automation] Availability Spec review - my feedback - OSLC Actions - thread 2 Availability definitions:

[John Arwe]

MP> Availability Condition (AC) being a separate resource
TF> So in my opinion the AC for an AR is at the moment the actual 
condition/ state of this resource. 

That seems unpersuasive, even given that you expect perhaps to add 
historical "views" later (those could be just linked as separate AR [sic] 
resources, for example).
I thought you were in a situation where different implementations 
potentially hosted separately might have different ACs for the same AR, 
which more clearly drives a requirement for a separate resource in my 
mind.

TF>  The dcterms:created can still be used for example in the case where 
the service provider updates the actual condition only at a specific 
interval, e.g. every 10 minutes.
TF>  The dcterms:created then holds the timestamp of the last update.

Well, if "last update" is the intended semantic then dcterms:modified (not 
:created) is more likely to be the right term.  Otherwise (if you used 
:created) you'd be forcing all providers to delete and then create a new 
AC, meaning at the very least there would be timing windows where clients 
could observe zero ACs on an AR, vs "exactly one" in the table.

MP> I'm not sure dcterms:contributor is the best relation ...  The one 
thing that is in there is the link to AutomationPlans via the 
dcterms:contributor link. However, we don't describe how to know which 
plans do what. I propose that, as mentioned in a meeting a while back (I 
presume you already had the draft written by that stage), instead of 
linking to Plans via that predicate, we use oslc:action
TF> My intention ...is to use this link to an Automation Plan, that can 
change the state/ condition of an AR

Sounds, minus the desire to use Automation Plans (which is an 
implementation detail IMO), exactly like CM 3.0's scenario for Actions 
http://open-services.net/wiki/core/Actions-2.0-Scenarios/
If you want your change-state operation to be discoverable by UIs, that's 
another scenario on the same page.
oslc:action seems like a better fit.  See 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/






Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140514/27e2fc60/attachment-0003.html>