Charles, Thanks for "kicking it up a notch" on this important topic. Treating each parameter as a blank node makes sense to me.
At the risk of splitting hairs, I tend to think of parameters as being required in relation to a particular automation plan instead of having an intrinsic "requiredness" on their own. For example, in a single RDF model you might have different automation plans that use the same parameters. The parameters might be required for one plan but not for the other. So whether or not a parameter is required for a particular plan could be conveyed via the relationship name instead of a literal property of the parameter itself. For example, the following model describes two automation plans. They use the same parameters, but they are optional for one plan (indicated by "hasParameter") and are required for the other (indicated by "requiresParameter"). @prefix oslc_auto: <http://open-services.net/ns/auto#> . @prefix dcterms: <http://purl.org/dc/terms/> . _:b1 a oslc_auto:AutomationParameter ; dcterms:title "ipaddr" . _:b2 a oslc_auto:AutomationParameter ; dcterms:title "hostname" . [] a oslc_auto:AutomationParameter . <http://foo.com/automations/plan1> a oslc_auto:AutomationPlan ; oslc_auto:requiresParameter _:b1 , _:b2 ; dcterms:title "plan 1" . <http://foo.com/automations/plan2> a oslc_auto:AutomationPlan ; oslc_auto:hasParameter _:b1 , _:b2 ; dcterms:title "plan 2" . Best wishes, Paul McMahan Rational Quality Manager From: Charles Rankin/Austin/IBM@IBMUS To: [email protected] Date: 01/16/2012 06:35 PM Subject: [Oslc-Automation] Definition of "parameter" Sent by: [email protected] At the last workgroup meeting there was some discussion about whether we should define what is on the other end of a "parameter" property or leave it up to implementations. I'd like to revisit that discussion. I'm of the opinion that we should provide a minimally useful definition that implementers could extend if necessary. One of the key scenarios that we want to enable with this first version of the specification is the "execution" scenario [1]. I'm concerned about the viability of this scenario without having a minimally useful definition of parameters. To that end, I'd like to take a stab at an initial representation for others to throw darts at. My RDF-Fu is weak, so please be kind. :) There are at least two different parameters in question. One is on an Automation Plan and provides the name and constraints on possible input values. The other is associated with Automation Requests and Automation Results and represents the mapping of a specific value to a specific named parameter. For lack of better names, I'm going to call the former a Parameter Definition and the latter a Parameter Instance. Let's start with the Parameter Definition. To provide a minimally useful Parameter Definition I think we need at least two pieces of information (possibly represented as three pieces of data). The first is simply the name of the parameter. The other is an indication of whether the parameter must be specified in order for the automation to be successfully executed. One mechanism for this is to indicate a "default value" to be used if none is provided. The presence of this also provides some potentially useful information to those looking at an Automation Result, as they can see if the value provided was different than the default. It isn't clear to me that the absence of this data necessarily means that the parameter is required. To that end, another option is to have a "required" property that indicates whether the parameter must be specified. Without further ado. let's take a stab at how this might look ( in Turtle). @prefix ap: <http://somewhere.com/oslc-automation-provider> . ap:plan1 oslc_auto:parameter _:parm1 . ap:plan1 oslc_auto:parameter _:parm2 . ap:plan1 oslc_auto:parameter _:parm3 . _:parm1 foaf:name "must_have" . _:parm1 oslc_auto:required oslc_auto:required_yes . _:parm2 foaf:name "might_have" . _:parm2 oslc:defaultValue "some value" . _:parm2 oslc_auto:required oslc_auto:required_no . _:parm3 foaf:name "may_have" . _:parm3 oslc_auto:required oslc_auto:required_no . The first definition indicates there is a required parameter with a name of "must_have". The second definition indicates there is an optional parameter with a name of "might_have", which if no value is specified a default value of "some value" will be used. The third definition indicates there is an optional parameter with a name of "may_have", which if no value is specified, no default value will be provided. The information needed to define a Parameter Instance is a little less than for a Parameter Definition. All that is required is the name of the parameter and the value of the parameter. While these could be specified as direct "name=value" strings, I think it is better to separate the name from the value. So, an Automation Request specifying information for the plan above, might have parameters as such. @prefix ap: <http://somewhere.com/oslc-automation-provider> . ap:req1 oslc_auto:parameter _:parm1 . ap:req1 oslc_auto:parameter _:parm2 . _:parm1 foaf:name "must_have" . _:parm1 rdf:value "here you go" . _:parm2 foaf:name "may_have" . _:parm2 rdf:value "more information" . This indicates that there are two parameters specified one with a name of "must_have" and corresponding value of "here you go", and another with a name of "may have" and a corresponding value of "more information". A few more thoughts/questions before I finish. 1) I did not specify any type for the Parameter Definition default value or the Parameter Instance value. Pragmatically, I think the only viable choice is String. I'm not sure if we should spec that or leave it up to the discretion of implementers. 2) I did not attempt to support the ordering of parameters. I don't believe there are any likely target systems where that would be required, but thought I'd mention it in case anyone else knew of a case where it might be necessary. 3) Given the distinction above between a Parameter Definition and a Parameter Instance, should we name the properties in Automation Plan differently than in Automation Request and Automation Result or keep it "parameters" and let the context be sufficient? That's enough for now. Have at it. :) [1] http://open-services.net/bin/view/Main/AutomationExecutionScenario Charles Rankin Rational CTO Team -- Mobile Development Strategy 101/4L-002 T/L 966-2386_______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
