Fw: [Oslc-Automation] schema.org Actions & OSLC Actions

[Martin P Pain <martinpain@uk.ibm.com>]

Regarding the OSLC Actions spec discussed
in the previous core meeting, I've been made aware that we have some overlap
with actions defined on schema.org.

I've copied my observations (as sent
to the open-services.net OSLC Automation WG) below, which summarises:

"I think our target use cases are
different enough to warrant different approaches... So I don't propose
we change anything, I just wanted to make other people aware of this in
case they wanted to propose any changes in light of the similarities."

Martin
OSLC Automation WG & TC Chair

----- Forwarded by Martin
P Pain/UK/IBM on 24/09/2014 13:53 -----

From:      
 Martin P Pain/UK/IBM@IBMGB
To:      
 oslc-automation@open-services.net
Date:      
 24/09/2014 13:21
Subject:    
   [Oslc-Automation]
schema.org Actions & OSLC Actions
Sent by:    
   "Oslc-Automation"
<oslc-automation-bounces@open-services.net>

---

My attention has been drawn to the fact
that schema.org has defined RDF types (and presumably predicates, but I
can't work out the URIs for them) for use in JSON-LD to describe actions
in a similar way to what OSLC Actions is attempting to do: http://schema.org/docs/actions.html
(and in case you don't have the OSLC link: http://open-services.net/wiki/core/Actions-2.0/)

Google supports schema.org actions for embedding actions in e-mails: https://developers.google.com/gmail/actions/reference/one-click-action

A few observations:

• If they have types & predicates that we are duplicating, we ought to consider whether we ought to or not.
• It appears to be aimed solely at JSON-LD, not [other forms of] RDF.
• The input/output parameters look distinctly non-RDF.
• It is designed for flexibility of the people/systems creating the data (to make it easy to construct the data to embed it in e-mails, webpages, etc) not the systems that parse it - which is the opposite of the focus of OSLC, as OSLC data is not designed to be embedded in other documents but be used as a REST API format. (That's not to say that we couldn't define a profile of it).
• The schema.org and Google pages seem to use a different property as the equivalent of our "oslc:binding" property - the schema.org docs use "target", which is either a URI or an object of type "EntryPoint", but the Google link above uses "handler" with an object of type "HttpActionHandler".
• If we wanted to re-use this instead of the Action type we have already defined, I expect we would want to define a subtype of EntryPoint or a type of handler that corresponds to Automation Plans and delegate UIs.

I don't have the energy or the motivation to change things now. I think
our target use cases are different enough to warrant different approaches.
(I just wish I'd done better research and come across this myself sooner...)
So I don't propose we change anything, I just wanted to make other people
aware of this in case they wanted to propose anything in light of the similarities.

Martin 

P.S. The latest changes to schema.org actions appears to have been pushed
by Google and applied in April this year: http://www.w3.org/wiki/WebSchemas/ActivityActions
 and  http://blog.schema.org/2014/04/announcing-schemaorg-actions.html
P.P.S. I think we also have some overlap with Hydra: http://www.w3.org/community/hydra/
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@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