> but but but... the object of both triples is identical: <plans/1/future-stop>
I misread your question. The triples you have there are not what are in the example. The example has: <plans/1/results/67890> oslc:action _:b0. _:b0 oslc_auto:executes <plans/1/future-stop>. I don't know if that changes the answer. I think the following would be making a wrong assertion: _:b0 oslc_auto:executesAutomationPlan <plans/1/future-stop>. as it could be argued (although perhaps not true technically) that the following is a valid expectation: _:b0 rdf:type oslc_auto:AutomationPlan. when that is not true, but the following is true instead: _:b0 rdf:type oslc:Action. _:b0 rdf:type oslc:TeardownAction. Does that make sense? > I was not stumping for removal BTW Your question revealed a can of worms to me that I hadn't previously seen. I know you weren't suggesting removal, but you found a valid problem that I don't see value in fixing. :) Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint chair E-mail: [email protected] Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU "Oslc-Automation" <[email protected]> wrote on 29/01/2014 13:46:49: > From: John Arwe <[email protected]> > To: [email protected], > Date: 29/01/2014 13:47 > Subject: Re: [Oslc-Automation] OSLC Actions: Action for resource > that does not yet exist: worked example > Sent by: "Oslc-Automation" <[email protected]> > > > Should { <plans/1/results/67890> , oslc_auto:executes > , <plans/1/future-stop> } be > > { <plans/1/results/67890> , > oslc_auto:executesAutomationPlan , <plans/1/future-stop> } > > in 2 places? > > > It's one action pointing to another action, so I didn't use > executesAutomationPlan as it's not pointing to an AutomationPlan. > Other than that it's semantically very similar. > > but but but... the object of both triples is identical: <plans/1/future-stop> > so either the second one is making a false assertion (which is > possible in general but not what we'd want in an example showing > 'the right way'), or your answer is wrong. > > The only other issues is do we need to add something so that > future extensions can prevent consumers that are used to the "no > configuration needed" case as the only option from using future > A non-normative note warning that future specs might introduce this > case seems friendly. > I was not stumping for removal BTW, just in effect noting that just > because a dialog is offered does not mean that the request Requires > more config. The dialog could just offer to change the template- > supplied values ("defaults"?), and if the user does nothing aside > from submit then the dialog made no net changes. I'm fine with > reluctant removal. > The rest seems fine in concept, I'll read the updates "later". > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > _______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
