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 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. 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. - 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). 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. - I don't see any way to link them reliably in the case where Plan and Result come from different providers, using current Automation means. I think we also had implementation cases where the Request and Result came from different providers (potentially separated by queueing and delegation), which Does Not Help at all. "without" + adding the MUST support AP implementation type seems like the minimum that Could work, so I'm tempted to start there and say any improvements in robustness/reliability are implementation extensions. Which is vaguely unsatisfying. 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? The scoping problem is solved there at least. Not all implementations would necessarily have the information available that early, but for those that do the consumer could build the full stop request "immediately" upon receipt of a representation of the Automation Request if it so desired. Implementations wishing to have fully reliable matching could also assign a proper URI (possibly hash URI) to the Action, once there is a Request with matching scope... given that, consumers would have zero doubt that they got the intended Action. Once blank nodes are allowed as Actions, there is just no reliable way to match, best anyone could do is duck-typing it. (Wild thought, again requiring that a single provider own the Plan and Results) we could also say that the requestURI on the Plan is a URI *template* (RFC 6570), which through some Jedi mind trick we know how to resolve fully (perhaps using the final request parameters... inputs + outputs... as input name/value pairs to resolve the template). This quickly gets too complex again. Net: I do see how some particular implementations could accomplish this. I do not see how it can be done using Automation alone by *all* the implementations I remember us discussing in the past as being either permissible or real. Simply too many degrees of freedom in the general case. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
