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

n Apr 24, 2014, at 8:03 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> 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.

/me nods

>> 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.

This is important to distinguish from a potential action, for which the class forms a template for a message IMO, and a completed action, as would appear on an activity stream, for example. In my case, I don't necessarily see the need to represent completed actions, as much as the updated state of resources that comes about as a result of the action. They may be suffering from too many perspectives, otherwise why have CommentAction, Comment, and UserComments classes?

>> 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.

Or you could use UserLikes in both cases.

I think your point argues that the action should either be bound to the property the client would like to interact with (schema has none for "like", I've used :interest to describe variations on the like/hate spectrum), or on the collection referenced by the property. I see these two as being pretty similar, but defining it on the property doesn't require first dereferencing the collection to get it's type, and therefore the operations it supports.

>> 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.

We seem to be drowning in a sea of possibly interpretations. I think some swim-lane like use cases would help clarify this. Certainly, when considering using a Hydra-based API to implement a client, I need to understand how I use the API to identify and perform interactions that support my particular use cases, and this could help flesh out the simple path.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
>

Received on Thursday, 24 April 2014 17:25:48 UTC