History   View   Links to this page 2013 August 20 | 01:28 pm

Time: 11:00AM Eastern US

Agenda

Minutes

Attending: Michael Fiedler, Paul McMahan, Steve Speicher, John Arwe, Charles Rankin

  • Primary topic was the relationship proposal
    • produces/produced
      • Does “produced” always mean the produced resource is eligible for cleanup? MF opinion: No - it is simply indicating the primary resource produced by this execution.
      • This is somewhat of a slippery slope. Obvious overlaps with contributions.
      • Arwe: I can see some limited utility in weeding out plans that don’t do what I want, e.g. to make a selection dialog have a better signal:noise ratio. I’m quite skeptical that it would allow completely headless (no human) selection however, unless we’re already dealing with implementation specificity in the client (and at that point, “why are we here [Automation WG] at all?”). It’s not the goal of the standard to cover every possibility completely; it’s to provide an 80-20 common base for implementations to build on an generic clients to use (the latter possibly with additional knowledge of some extensions).
    • Proposed links
      • Do they belong in the plan? or in the result? It is not really this automation plan which we are reverting or defining a sequential/parallel relationship. It is the specific result of a specific request, which would include parameters from the Request’s creation.
      • Arwe: Names conflict with Core’s draft Link Guidance; should not include type of the linked-to resource in the predicate name, but should note it in the desc. Suggestion: remove the resource type from the name and then it can be used anywhere, e.g. in plans or resources.
      • Arwe: reversion should be a naked post to the reversion object, no RPC-ish parameter; and it should be on the Result, not the Plan. MF: Need to re-visit this - specific proposal? Did not capture the full context here. Also conversation around putting the reversion link on a contribution in a result.
      • Sequential/parallel relationships might be actively bad; scope creep. Taking automation into the full topology discussion and it might not belong there. Implications for scheduling implementations should be a consideration. There are (plenty of) existing standards for workflow modeling, and even more proprietary approaches.
      • oslc_auto:relatedAutomationPlan … once we conform with link guidance by removing the type from the name, why is this needed vs using an existing generic relationship like dcterms:related ? What breaks without it?
      • Reification alternative: Core guidance is to Avoid Reification except in extreme cases.
    • Problem with all automation plans
      • An issue for headless scenarios today is that I, as a consumer, have no way of telling what a plan does just given an automation plan resource. I always have to have special knowledge of the implementation to understand which one does what I want, since there are no standard plan names.
  • Workgroup business
    • Next meeting: 22 August. John Arwe will chair. Mike Fiedler will cancel existing invite and expect a one-off from John Arwe.