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 <[email protected]> To: John Arwe/Poughkeepsie/IBM@IBMUS, Cc: [email protected], "Oslc-Automation" <[email protected]>, [email protected] 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: [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 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
