[Oslc-Automation] Advertising actions on the Result from the Plan

Thu Oct 17 08:26:54 EDT 2013

> > Looking at http://open-services.net/wiki/automation/Exposing-
> arbitrary-actions-on-RDF-resources/#Advertising-actions-on-the-
> Result-from-the-Plan , some comments. 
> 
> > Without the parameterised plan: 
> 
> > - there's not enough here for a client to know it is capable of 
knowing 
> > how to invoke the future Action. Automation would have to add that 
> > requirement; i.e. that the action on the result MUST at least support 
> > the Automation Plan implementation type, using the current terms. If 
we 
> > do so, not much practical difference between these two options that I 
> > can see. 
> 
> The automation wiki page says "If a provider is providing Actions 
> for consumption by Automation consumers.... It MUST include one 
> AutomationPlan implementation of each action." - so we already have 
> that requirement. 
> Having said that, replying on the spec for this information is 
> subject to the same problems as if the actions spec said "it's 
> always POST" rather than encoding that in the data - namely, lack of
> extensibility. 

Martin, the page text you cited (the MUST) is equivalent to saying that 
the example given under
> > Without the parameterised plan: 
is non-compliant as it stands.  I'm content to not pursue that subtree 
further if you're happy with the MUST.  The presence of the "without" 
example I assumed was either (a) already consistent with the proposal as 
it exists or (b) an implicit assertion that it (the without example) 
should be Made Valid by changing the rest of the proposal, if needed, or 
(c) any inconsistency was a mistake I introduced in the process of 
separating "core to be" content from automation content, which is 
equivalent to (b).

> > - the Result might offer multiple Actions, with duplicate rdf:type 
sets, 
> > some supporting the Automation Plan implementation type and others not 

> > supporting it. I'm allowing, for example, that the Plan and Result are 

> > owned by different providers, which is a case I remember at least one 
> > implementation saying they had; the Result provider could offer a stop 

> > action (that the Plan provider somehow knows about - how, I don't 
care) 
> > and a second stop action implemented by a third provider. This seems 
> > like a stretch, but if the Result provider allows updates (put/patch) 
> > that add actions, there you are. We don't have to solve that, but if 
> > there's an option that clearly does/not it would be useful to keep in 
> > mind. 
> 
> If those duplicate actions are semantically equivalent, they should 
> be multiple requests on a single action. 

I was not assuming that multiple providers MUST patch at the "add request" 
level, although they MAY.  The current "if you have multiple requests, 
then they MUST be equivalent" structure is a one-way implication, not a 
bidi equivalence relation, so it allows what I had in mind (for good or 
ill ;-) ).  The simplest implementation for that case is to just Patch in 
another Action; depending upon the Patch format, and whether or not the 
existing Action resource to be extended is a blank node (as currently 
allowed) or not, patching to add a request might not be possible (some 
proposed patch formats cannot handle blank nodes).

> Then as long as one of 
> those Requests uses the AutoPlan impl type, we're fine - the 
> minimal-implementation consumers just identify and use the AutoPlan 
> one. 

agree

> The PUT/PATCH to add actions is interesting - using the spec 
> as-is they would have to identify if any of the existing actions are
> semantically equivalent, which would be difficult. 

I attempted to cover this base by saying that the types were identical. 
The type set is the only I know of to decide equivalence; I went for the 
trivially equivalent case (equality).

> But if they're 
> adding an action onto an AutoResult, then they ought to be subject 
> to the Automation profile of Actions anyway, which would require an 
> AutoPlan implementation of the Action. 

All the "normal" cases, I'd agree.

I do have other cases in mind, where (because a new provider arrives to 
manage an "environment" - imprecise general sense of that word) a set of 
commands "suddenly" becomes available for entire classes (types) of 
resources.  Basically, the provider can add its actions to any resource 
meeting its criteria (which boils down to a query + put/patch loop over 
The World)... whatever it considers "under management".

We'll just have to be sure that spec text constrains it as you desire.  I 
don't see any special need to help the case above by complicating the very 
Automation-specific case of a Plan advertising (future) actions on 
Results.

> > With the parameterised plan: 
> 
> > - the "orchestration composition time" problem I think is that the 
> > requestURI value is unknown on the Plan. Reusing core:Action with 
> > requestURI 0:1 (or 0:0) seems right to solve that. 
> 
> I don't understand what you mean. It sounds like you're talking 
> about "without the parameterised plan". Are you saying we don't need
> to allow for a parameterised plan? I'm happy to leave it out of the 
> spec, as long as we think we have a reasonable chance of adding it 
> in later if someone comes up with the need later (which feels very 
> unlikely at this point). 

I was forgetting the context that this usage is fully constrained by 
Automation to Require an automation plan implementation, so I wandered 
into the CM-style.

Your response does make me think that you have assigned a very specific 
meaning to 'parameterised' in your mind that I do not share.  I just read 
past that, treating "with" == (a), "without" == (b), i.e. just treated 
those as differentiation between two alternatives, so maybe I missed some 
deeper meaning.

Given that we agreed that the first example is inconsistent with the 
proposal though (the MUST not being satisfied), I'm surprised that you say 
it's ok to drop "With the parameterised plan".  As you can probably tell 
from the preceding, I thought you meant simply that "without" would be 
dropped as inconsistent with the spec.

> If you're saying that we don't know the requestURI for the 
> parameterised plan, my intention of allowing parameterised 
> actionOnResult plans is to allow clients with provider-specific 
> knowledge to insert the context for the action as an AutoRequest 
> parameter value. In other words, instead of giving the context-
> specific requestURI and AutoPlan URI that will be in the Result's 
> Action, we provide a contextless requestURI and AutoPlan URI, with 
> the context provided by the parameter. The provider-specific 
> knowledge is required to know how to find the value of that 
> "context" parameter, and which parameter it should be the value of. 
> As I said, I'm happy to leave this out of the spec, especially due 
> to this provider-specific knowledge being required. 

Feels like a weak form of violent agreement.
But at this point I'm wary of false agreement, so perhaps today's call is 
a better venue to synch up.

> There is a separate case for when the action has required parameters 
other
> than the context... that's a whole other problem. That's not the 
> problem I was trying to address here.
> 
> > - dcterms:identifier is only going to be useful if both Plan-Action 
and 
> > Result-Action are somehow known to come from the same Provider, which 
> > Automation does not guarantee (tolerable) but also does not give the 
> > client any iron-clad always-available way to know (less attractive - I 

> > don't think we Require oslc:serviceProvider links). 
> 
> Does the same dcterms:identifier value explicitly mean different 
> things from different providers? 

http://dublincore.org/documents/dcmi-terms/#terms-identifier  says 

Definition: 
An unambiguous reference to the resource within a given context.

Has Range: 
http://www.w3.org/2000/01/rdf-schema#Literal

The "given context" is usually interpreted as "service provider" in OSLC 
specs, although I'm not sure that is explicitly rendered anywhere.
So while the value MAY be the same across multiple providers, there are no 
guarantees.  Absent a guarantee, I don't see how it can be useful for 
Automation clients in general.

> As the provider of the Result 
> really should know about the Plan, it can perhaps pull those 
> identifiers from the Plan provider. 

Again: we had 2.0 discussions about implementations where the Results were 
created by separate providers through delegation (imagine an orchestrator 
queueing up Requests, and a separate pool of workers pulling them off and 
creating the Results), IIRC.  I believe this is what led to the Result > 
Request linkage instead of the other direction, in fact.

So "can", yes.  "must", no.

> This would likely need provider-
> specific logic to know which identifier to use, but if the Plan 
> provider is advertising actionOnResult in this case then it would 
> have to have Result-provider specific knowledge to know that the 
> actions will be available anyway. So as long as it doesn't 
> contradict dcterms' definition of dcterms:identifier to say that 
> they can be used to match actions even across providers (ONLY 
> between a Result and its Plan when they are on different providers),
> I don't believe there's a problem here. They would check the 
> identifier between the Plan and the Result, and not have to know if 
> they are on the same provider or not. 

Plan (provider A) semantic Stop, identifier= 2314
Result (provider B) semantic FreeTheWhales, identifer= 2314
Result (provider C) semantic Stop, identifier= 2314
Since identifiers are used by each provider without coordination, this is 
a valid state.
Reading your criteria, it sounds like both Results match A's Plan, but the 
semantic of B is wrong.
If you try use Result > reportsOnAutomationPlan (since that's required) 
and say that if the identifier *and* the provider URIs match then you've 
found what you're after, then Maybe you have something reliable.  Given 
that I cannot be sure that the Action on the Result comes from the same 
provider as the Result itself, it's not clear.  Given the earlier 
discussion about patching, it's not even the Action identifier but a (not 
spec'd, today) Request identifier you'd need.

Which all sounds kind of ornate given how simple it sounds in natural 
language.

Last night I concluded what we're really struggling after here is a search 
key; to be unique across providers, a URI.  Maybe we add a(n optional) 
link to Requests, and just search on that?

> 
> > It really wants to 
> > be a URI, but it seems likely that (ala requestURI) the correct URI 
(to 
> > the Result-Action of interest, which is inherently scoped to 1 
request) 
> > cannot be reliably known from the Plan (which is scoped to 0:n 
Results). 
> > In cases where the resource context is supplied outside the request 
URI 
> > (e.g. in a fixed body), I can see a URI working. 
> 
> My feeling on this is that we have a URI - it's the value(s) of 
rdf:type. 
> So one option would be to say that separate actions on the 
> AutoResult MUST have distinct value sets for rdf:type (possibly only
> applying this requirement in the case of the action being advertised
> through actionOnResult). If the provider has two actions that map to
> core:StopAction, then they must define their own type for each of 
> them (in addition to Action and StopAction) to differentiate them. 
> In other words, they give this action a URL that applies to both its
> parameterised and non-parameterised forms, and include that in the 
> rdf:type values.

Certainly works, modulo that I'm fairly certain I don't understand the 
final sentence given my ambiguity as to your intended meaning for 
"parameterised".  But the rest is perfectly reasonable, so I'm betting 
they're equivalent as "In other words," suggests.

> Do either of my comments about dcterms:identifier or rdf:type above 
> help give robustness/reliability to this case?
> 
> > I wonder out loud: if the Result-Actions (as in the "with" option, 
fully 
> > fleshed out with the final requestURI) were linked via actionOnResult 
from 
> > the Request, would that satisfy the scenario? .... 
> 
> No, as even the Request is not created when the orchestration Plan 
> is authored. And as the orchestration Plan may be executed multiple 
> times (possible even concurrently in different environments managed 
> by the same provider) there may be multiple Requests existing over 
> time, so even fixing the "don't execute on Request creation" 
> 'problem' wouldn't make this work. 

This is useful, since it eliminates possibilities.  Do make sure it's 
captured in the scenarios if you would.  I know I won't remember it 6 
months from now.

I will be updating the automation/core drafts in the hour preceding the 
meeting, unless that will cause contention with someone else.

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-automation_open-services.net/attachments/20131017/6223aa75/attachment-0003.html>