As we seemed to be agreeing on the usefulness of this being common/reusable, I have added a section for the oslc:StateTransitionAction rdf:type value to the Core Actions spec [1].
I have also added a section to the Automation 2.1 spec wiki page to track changes we want to make to the vocab [2], and put the proposed new description for oslc_auto:desiredState there. If John & Steve could have a quick review that would be great. [1] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Resource.3A-StateTransitionAction [2] http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Appendix-D.3A-Changes 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 30/01/2014 18:40:43: > From: John Arwe <[email protected]> > To: [email protected], > Cc: [email protected] > Date: 30/01/2014 18:40 > Subject: Re: [Oslc-Automation] Some comments on Actions spec (most > from CM perspective) > Sent by: "Oslc-Automation" <[email protected]> > > I like fewer terms (one desired state)... the resource shape (aka > resource definition table text) is where the "is likely to be an X" > should live. That's domain-specific, so it does not pollute the > vocabulary term's definition. > Domain CM reusing a Domain!=CM term might cause some "ick, it's a > cross-domain dependency" knee-jerk reactions, but if we're > comfortable re-using DC then Automation is no different in > principle, i.e. while we might hate cross-domain SPEC dependencies, > we should be completely comfortable with cross-domain VOCABULARY re-use. > I tend to split the difference on the descriptions; I've seen in > many contexts that when we try to be completely generic, the result > is incomprehensible to anyone not in That Meeting(s), so I add an a > specific concrete example (clearly marked as such) alongside it. I.e. > <oslc_auto:desiredState > > 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. It is expected that > this will be a resource reference to a definition of a valid state > on the service provider. For example, in the OSLC Automation domain this is > used to indicate the desired state of the Automation Request based > on values defined in the OSLC Automation specification and, > optionally, by the service provider." ; > rdfs:seeAlso oslc:StateTransitionAction ; > . > 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
