[Oslc-Automation] action metadata at resource type (shape) level
Martin P Pain
martinpain at uk.ibm.com
Wed Jul 16 06:21:11 EDT 2014
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: 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
From: Anamitra Bhattacharyya <abhattacharyya at us.ibm.com>
To: oslc-automation at open-services.net,
Date: 15/07/2014 20:31
Subject: [Oslc-Automation] action metadata at resource type (shape)
level
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
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
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-automation_open-services.net/attachments/20140716/5fda9c59/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-automation_open-services.net/attachments/20140716/5fda9c59/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-automation_open-services.net/attachments/20140716/5fda9c59/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-automation_open-services.net/attachments/20140716/5fda9c59/attachment.gif>
More information about the Oslc-Automation
mailing list