[oslc-cm] [Oslc-Automation] Some comments on Actions spec (most from CM perspective)
Martin P Pain
martinpain at uk.ibm.com
Thu Jan 30 13:00:32 EST 2014
<oslc:StateTransitionAction>
a rdfs:Class ;
rdfs:subclassOf oslc:Action ;
rdfs:comment "A type of oslc:Action that, when executed, moves the
context resource through a finite- or infinite-state-machine transition."
;
rdfs:seeAlso oslc:targetState ;
.
Would that have value?
I'm not 100% sure it does, as the property's definition may give enough.
However, I'm not sure how explicit the property should be about Actions.
<oslc:targetState>
a rdfs:Property ;
rdfs:comment "The intended (domain- or provider-dependant) value of a
resource's (domain-dependant) 'state' property after some (future, present
or past) process, transition or change." ;
rdfs:seeAlso oslc:StateTransitionAction ;
.
This made me thinkg of oslc_auto:desiredState, so I went and checked that,
but that has a very Automation Request-specific description:
Used to indicate the desired state of the Automation Request based on
values defined in the automation specification and, optionally, by the
service provider. It is expected that this will be a resource reference to
a definition of a valid automation request state on the service provider.
The Actions-specific version of oslc:targetState would be:
<oslc:targetState>
a rdfs:Property ;
rdfs:comment "The intended (domain- or provider-dependent) value of a
resource's (domain-dependent) 'state' property after the
oslc:StateTransitionAction that this property is on is successfully
executed." ;
rdfs:seeAlso oslc:StateTransitionAction ;
.
To me, what would feel like best maintenance of the vocab would be to
change oslc_auto:desiredState to have the first description that I gave
oslc:targetState above (as that seems to be a more general version of the
existing desiredState description), and then use oslc_auto:desiredState in
Actions. Then we would have purpose for oslc:StateTransitionAction (as it
defines the state-machine type of actions) and not duplicate the "expected
state" kind of property, by having the oslc_auto:desiredState property's
description being generic, not tying it to a particular subject type.
John & Steve, what's your take on this?
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: martinpain at uk.ibm.com
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" <oslc-automation-bounces at open-services.net> wrote on
30/01/2014 17:38:46:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Cc: oslc-cm at open-services.net
> Date: 30/01/2014 17:39
> Subject: Re: [Oslc-Automation] Some comments on Actions spec (most
> from CM perspective)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> I'd say that's spec text and a resource shape, not a *type*
> definition. Which is fine, just different.
> By "type* definition" I mean the definition of the vocabulary term
> oslc:StateTransitionAction: I mean what you'd find in its RDFS
> description. I sure hope I don't find anything about *:targetState
> in there, except perhaps a seeAlso link. What I should find is how/
> when/where/not to use it, regardless of any other terms that I mix
> it together with.
> Then (if I was in a minimalist state of mind, which is where this
> threadlet started), I'd compare the type definition for :Action and :
> StateTransitionAction, and ask if there was any clear meaningful
> distinction. If not, why two instead of one? or zero? (although
> for the last question I at least could formulate what seems to me
> like a reasonable answer).
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Tivoli OSLC Lead - Show me the Scenario
>
>
>
>
> From: Martin P Pain <martinpain at uk.ibm.com>
> To: John Arwe/Poughkeepsie/IBM at IBMUS,
> Cc: oslc-automation at open-services.net, "Oslc-Automation"
> <oslc-automation-bounces at open-services.net>, oslc-cm at open-services.net
> Date: 01/30/2014 12:27 PM
> Subject: Re: [Oslc-Automation] Some comments on Actions spec
> (most from CM perspective)
>
>
>
> > Turning it around: if I have some action Foo that I want to expose,
> > I would hope that the type definition would tell me whether or not I
> > should be using oslc:StateTransitionAction amongst the types.
>
> What would you make of this sort of definition?
>
> An resource (action) of type oslc:StateTransitionAction MUST contain
> an oslc:targetState predicate set to the value that the context's
> "state" property will be changed to by executing this action.
> Actions of this type, if successful, MUST change the object of the a
> triple, whose subject is the context resource and whose predicate is
> the "state" predicate defined by the resource's domain, to the value
> stated in the action resource, as part of a state machine[1][2]
> (which MAY be finite or infinite). Consumers MAY list all
> oslc:StateTransitionActions from a particular context together, for
> example in a drop-down list, as the list of valid states that this
> context resource may go to in its state model.
>
> [1] http://en.wikipedia.org/wiki/Finite-state_machine
> [2] http://en.wikipedia.org/wiki/State_transition_system
>
> (Of course, if making this general, we might want to make it
> explicit in the data what the state predicate is in the context
> resource, which might allow multiple state machines per resource as
> different actions could refer to different "state" predicates. This
> then makes it more complicated than the CM example as it currently
stands.)
>
> 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: martinpain at uk.ibm.com
> Find me on: [image removed] and within IBM on: [image removed]
>
> [image removed]
>
>
>
>
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
>
> 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
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140130/1b08b0f3/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140130/1b08b0f3/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140130/1b08b0f3/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140130/1b08b0f3/attachment.gif>
More information about the Oslc-Cm
mailing list