Hello Anamitra, Thank you for your email - sorry for the delay in getting it approved on the list.
1) You are correct that oslc:action is associated with the resource instance. 2) Looking at the Automation 2.1 convergence specification just now I realised that we did not have a definition for the oslc_auto:futureAction predicate. So I have proposed a draft definition here: http://open-services.net/pipermail/oslc-automation_open-services.net/2014-July/000780.html With this proposed defintion of oslc_auto;futureAction, I believe it would make sense within that definition to use that predicate on the type or resource shape to point to actions that may be available on resources of that type/shape. (However, this is just my individual opinion - I'd appreciate other working group members weighing in too). (The only two issues are: (1) no spec defines that behaviour - it would be your own product's reuse and interpretation of the vocabulary, and (2) the term "future" in the predicate name is not as accurate as it could be. As the specs are still not finalised there might still be scope for renaming the predicate and adding that definition - although we'd probably want that to be in the Action spec, so then we might want the predicate to change namespace too, which is all starting to sound like a very large change for so late in the process. However, none of this stops your product using the term like this.) On the other hand, defining a new predicate (e.g. spi:instanceAction, or if the WG defines it, oslc:instanceAction) which defines the meaning "an action that may exist on instances of this type/shape" would be another valid approach. 3) One other thing to bear in mind is: do you really need to know the actions at design time? I don't know the specifics of how your app is written, but thing to consider is just to allow the mobile app to list all the actions available on a given resource instance and allow the user to select any of them. RDF is capable of including multiple translations for a property, so you can provide the name in multiple languages at run-time, and there's nothing to stop you reusing oslc:icon to point to an icon to display with the button.There may be good reasons for wanting to tie the list of actions down at runtime, but it's worth considering whether you need to or not. 4) Looking at your examples, it look slike you want to know how to execute the actions at design time, not just which actions are available to execute. There is nothing in the spec at the moment that allows you to do that - there is no explicit support in there for URI templates (as used in your example). The intention of oslc_auto:futureAction was to link to oslc:Action resources that have zero oslc:binding properties - and that the binding information is only provided on the executable actions (in this case, that would be the ones on the instances). So to follow that intention, your example for the resource shape would not contain the binding predicate: <oslc:ResourceShape rdf:about=" http://localhost:7006/maximo/oslc/shapes/oslcwodetail";> <spi:instanceAction> <oslc:Action> <oslc:usage rdf:resource=" http://jazz.net/ns/ism/smarter_physical_infrastructure#WorkOrder-changeStatus "/> <rdf:type rdf:resource="http://open-services.net/ns/core#Action"/> <dcterms:description rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"; >Action to change status of the Work Order resource</description:title> <dcterms:title rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"; >changeStatus</dcterms:title> </oslc:Action> </spi:instanceAction> <oslc:property> <oslc:Property> and your example for the binding for the action on the instance would contain all the binding's properties (as the spec requires it to anyway): <http:HttpRequest rdf:about="http://localhost:7006/maximo/oslc/action /oslcwodetail/changeStatus"> <http:requestURI rdf:resource=" http://localhost:7006/maximo/oslc/os/oslcwodetail/12345/changeStatus"/> <http:mthd rdf:resource="http://www.w3.org/2011/http-methods#POST"/> <http:httpVersion>1.1</http:httpVersion> <http:body rdf:resource=" http://localhost:7006/maximo/oslc/actionshapes/oslcwodetail/changeStatus";> <oslc:finalStatusLocation rdf:resource=" http://www.w3.org/2011/http#StatusCode";> </http:HttpRequest> </rdf:RDF> Do you need to know at design time which interaction pattern to expect on the actions on the instances? Or can you design it just to only be able to use actions that provide the resource shape that you are interested in? (In this case, that looks like either the "HTTP request with Resource Shape to describe the request body" pattern or "HTTP request with fixed body"). 5) And finally, a small point: the Actions specification suggests that you identify what the action does by using an rdf:type value In your examples you use oslc:usage. So to follow that suggestion your actions (both on the resource shape and instance) would start: <oslc:Action> <rdf:type rdf:resource=" http://jazz.net/ns/ism/smarter_physical_infrastructure#WorkOrder-ChangeStatus "/> <rdf:type rdf:resource="http://open-services.net/ns/core#Action"/> See: http://open-services.net/wiki/core/Actions-2.0/#Types-of-actions 6) Also, if you were to use oslc_auto:futureAction (or follow the same pattern), then your action on the reosurce shape would require a URI: <oslc:ResourceShape rdf:about=" http://localhost:7006/maximo/oslc/shapes/oslcwodetail";> <spi:instanceAction> <oslc:Action rdf:about=" http://localhost:7006/maximo/oslc/shapes/oslcwodetail/changeStatus";> (Apologies if I get the RDF/XML wrong - I'm more familiar with Turtle). ... And then the action on the resource instance would point to that action with the oslc_auto:executes predicate: <oslc:action> <oslc:Action> <oslc:binding rdf:resource="http://localhost:7006/maximo/oslc/ action/oslcwodetail/changeStatus"/> <oslc_auto:executes rdf:resource=" http://localhost:7006/maximo/oslc/shapes/oslcwodetail/changeStatus"; /> (And the client would use this to know which of those actios on the resource shape this instance action related to. Sorry for the long email - hopefully there's something useful in there. Feel free to ask more questions (including "why would you do it like that?"), and let us know if you still believe the way you were intending to do it was better than what I've suggested here. To my knowledge you are the first implementors of this, so your experience in implementing it is very helpful in validating (or invalidating) the desicions taken previously, and making improvements to the spec if needed. Thanks, Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel OASIS Open Services for Lifecycle Collaboration - Automation technical committee 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 From: Anamitra Bhattacharyya <[email protected]> To: [email protected], Date: 15/07/2014 20:31 Subject: [Oslc-Automation] action metadata at resource type (shape) level Sent by: "Oslc-Automation" <[email protected]> Hi I am looking into implementing the OSLC Actions specification for the Maximo/Tririga product suite - primarily for consumption by our Mobile clients which currently use the OSLC API to interface with the Maximo/Tririga systems. One of the major requirements for our Mobile architecture is to be able to introspect the metadata for resource actions to design the mobile apps corresponding to the actions. In our user case a resource type (say WorkOrder) will have a global list of possible actions - each action associated with some condition/authorization metadata which determines the resource states this action is valid. At design time the client (say Mobile App Designer) would need to introspect the resource type metadata (say OSLC shape for the resource type) to discover the possible list of actions ( for the resource type) - this will be used by the designer to generate application artifacts that will consume the said actions. At run time the device would introspect the resource representation to determine if the action is valid for this resource state - which will be used to hide/show the said action app artifacts (say a button). Now as I look into the current specification for OSLC Actions - 2 things stand out 1. The oslc:action property is associated with the resource instance - and not the type. For our use case - we would need the action metadata available at the type level - say ResourceShape. 2. the metadata part for the actions are attached to the oslc:bindings predicate -->http:HttpRequest resource type. We would need to use some predicate like spi:instanceAction (or oslc-automation:futureAction) in the shape document like below <oslc:ResourceShape rdf:about=" http://localhost:7006/maximo/oslc/shapes/oslcwodetail";> <spi:instanceAction> <oslc:Action> <oslc:binding rdf:resource="http://localhost:7006/maximo/oslc/ actionmeta/oslcwodetail/changeStatus"/> <oslc:usage rdf:resource=" http://jazz.net/ns/ism/smarter_physical_infrastructure#WorkOrder-changeStatus "/> <rdf:type rdf:resource="http://open-services.net/ns/core#Action"/> <dcterms:description rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"; >Action to change status of the Work Order resource</description:title> <dcterms:title rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"; >changeStatus</dcterms:title> </oslc:Action> </spi:instanceAction> <oslc:property> <oslc:Property> .... <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:oslc="http://open-services.net/ns/core#"; xmlns:spi=" http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"; xmlns:spi="http://www.w3.org/2011/http#";> <http:HttpRequest rdf:about="http://localhost:7006/maximo/oslc/ actionmeta/oslcwodetail/changeStatus"> <!--http:requestURI rdf:resource=" http://localhost:7006/maximo/oslc/os/oslcwodetail/{id}/changeStatus"/--> <http:mthd rdf:resource="http://www.w3.org/2011/http-methods#POST"/> <http:httpVersion>1.1</http:httpVersion> <http:body rdf:resource=" http://localhost:7006/maximo/oslc/actionshapes/oslcwodetail/changeStatus";> <oslc:finalStatusLocation rdf:resource=" http://www.w3.org/2011/http#StatusCode";> </http:HttpRequest> </rdf:RDF> As you can notice - http:requestURI - which is marked in the spec as Exactly-One - would be something that we would have no need of at this "blue-print" stage. Also I would like to hear any comments on the choice of predicates that we have for replacing spi:instanceActions. I am not sure if oslc-automation:futureActions is the right one for this - but will like to hear back from the group. I would rather not come up with our own - if there is something already defined for the same purpose. Our runtime resource representation would have the oslc:action array property which would look like below <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:oslc="http://open-services.net/ns/core#"; xmlns:spi=" http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"; xmlns:spi="http://www.w3.org/2011/http#";> ...... ...... <oslc:action> <oslc:Action> <oslc:binding rdf:resource="http://localhost:7006/maximo/oslc/ action/oslcwodetail/changeStatus"/> <oslc:usage rdf:resource=" http://jazz.net/ns/ism/smarter_physical_infrastructure#WorkOrder-changeStatus "/> <rdf:type rdf:resource="http://open-services.net/ns/core#Action"/> </oslc:Action> </oslc:action> ....... </rdf:RDF> And the corresponding HttpRequest resource as below (note that we only need the requestURI - as rest of it has already been provided in the shape document) <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:oslc="http://open-services.net/ns/core#"; xmlns:spi=" http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"; xmlns:spi="http://www.w3.org/2011/http#";> <http:HttpRequest rdf:about="http://localhost:7006/maximo/oslc/action /oslcwodetail/changeStatus"> <http:requestURI rdf:resource=" http://localhost:7006/maximo/oslc/os/oslcwodetail/12345/changeStatus"/> </http:HttpRequest> </rdf:RDF> Let me know if this use case makes sense - its driven by the 2 step model that we follow - 1>design time (introspection, artifact generation stage) and 2>runtime (actual usage). thanks Anamitra _______________________________________________ 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
