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

On Thursday, April 24, 2014 7:25 PM, Gregg Kellogg wrote:
> >> 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

In Hydra, at least, it doesn't "form a template for a message". The
operation's type(s) convey the semantics of the operation. That's all. The
template for the message is specified in hydra:expects


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

Because the Action subtree didn't exist yet when UserComments was
introduced. But yeah, I think I agree that currently Actions appear to be
used for too many things at the same time in Schema.org. I say appear
because there's very little guidance or explanation.


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

Sure. Looking at UserComments, however, I would consider it a bit of a
stretch to say that such an operation is also "The UserInteraction event in
which a user comments on an item". The definition of CommentAction fits much
better: "The act of generating a comment about a subject."


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

In fact, they are equivalent, yeah. Following your reasoning, the downside
of associating it with the property is that if you get a direct link to the
collection, you wouldn't know what you can do with it. You can address both
issues by including enough information in both representations.


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

Yeah. In the end, this is much more a "social problem" than a technical one
I would say. It depends on how people will use this feature and how they
interpret it. We should provide clear guidance as to how we propose it to be
used but we shouldn't make it impossible to be used in different ways.


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 27 April 2014 15:59:01 UTC