RE: ISSUE-11: Remove predefined operations from the core vocabulary

On Wednesday, April 23, 2014 12:58 AM, Gregg Kellogg wrote:
> > PROPOSAL: Remove all *ResourceOperations by replacing them with their
> > schema.org counterparts CreateAction (CreateResourceOperation),
DeleteAction
> > (DeleteResourceOperation), ReplaceAction (ReplaceResourceOperation). As
> > Schema.org now has a more or less complete Action model, describe in
more
> > detail how it can be used with Hydra.
> >
> > https://github.com/HydraCG/Specifications/issues/11
> 
> It seems to me that schema Actions are a bit different than Hydra
Operations. 

Unfortunately, they are indeed.


> Sub-classes of Operation define method/expects/returns and so-forth, while
the

Not subclasses, instances thereof.


> schema Action classes define the content of the messages. 

That depends on how you use them. There are also "potential actions". They
describe a potential activity. IMO, an (HTTP) Operation is a potential
activity.


> In this case, it seems to make more sense to use the Action class as
> the value of expects. For example:
> 
> :SportsTeam a hydra:Class;
>    hydra:supportedOperation [
>      a hydra:Operation;
>      hydra:title "Express interest in something"@en;
>      hydra:description "Indicate if you like something."@en;
>      hydra:expects schema:LikeAction;
>      hydra:method "POST";
>      hydra:returns schema:UserLikes;
>    ] .
> 
> schema:LikeAction a hydra:Class;
>   hydra:supportedProperty schema:agent, schema:object . # schema:object
may be
> redundant, as it could be inferred to be on the URL to which the message
is posted.

You can certainly send a LikeAction but that really feels to much like RPC
to me. Also, if a client want's to like something, it would need to look
into expects to find the operation. That's not very explicit IMO. I would
like to find an operation of a certain type, what it expects is, till I
found it, secondary. I can then figure out if I have all the needed data to
invoke that operation.

Of course, in this example, you could use LikeAction as both expects and the
type of the operation.


> You would then know to POST a message containing select properties of a
> schema:LikeAction, and perhaps get back a schema:UserLikes representation,
which would
> have been added to a collection containing specific property
relationships, such as
> :interestCollection.

The question is how you find that specific operation. Currently, you look
for operations of a specific type and not for operations that *expect* a
specific type of data. In a very simple API, both ordering a product (think
1-click order) and saving it to a wishlist could expect a Product. The
consequences would be quite different though.


> It may be that only schema:UpdateAction, and descendants, are appropriate
for updating
> and deleting, and everything else is a kind of create, in which case, only
the method
> property is really needed, and all operations are simply hydra:Operation.

I disagree. See above. Both of those operations could be implemented with a
POST (add to wishlist of course also with a PUT).


> An alternate way to perform this operation might be to do a
schema:AddAction on the
> collection and have schema:object reference a schema:UserLikes instance
included along
> with the message. This could also be done as an operation on the
:interestCollection
> property, but I have to say that the distinction eludes me.

Yes, you could do that as well. I personally would like to a stronger typed
operation to really know what's happening if I invoke it.


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 24 April 2014 15:04:23 UTC