W3C home > Mailing lists > Public > public-vocabs@w3.org > May 2014

RE: potentialAction for Classes?

From: Jason Douglas <jasondouglas@google.com>
Date: Wed, 21 May 2014 19:26:09 +0000
Message-ID: <CAEiKvUDAmDH-RpZjfrW_+d68LN-qUz6wb_2aQTHP=U9ZYd1HDA@mail.gmail.com>
To: markus.lanthaler@gmx.net, holger@topquadrant.com, public-vocabs@w3.org
On Wed May 21 2014 at 12:18:13 PM, Markus Lanthaler <
markus.lanthaler@gmx.net> wrote:

> On Wednesday, May 21, 2014 11:06 AM, Jason Douglas wrote:
> > You can do that.  The movie review site example toward the end of the
> > announcement spec is an example:
> >
> > https://www.w3.org/wiki/images/1/10/PotentialActionsApril11.pdf
>
> IMHO this is different. It defines an "endpoint" which is able to process
> ReviewActions. This is not the same as allowing bugs to be marked as being
> resolved by modifying their state.
>
>
> > The challenge is that not all bugs are resolvable.  Only bugs from the
> > same database that exist and are open.  That's why it's generally
> > simpler to state on the bug itself what actions it supports.  For
> > example, when I resolve the bug, you can return that it's no longer
> > resolvable but is no re-openable.
>
> True.. but introducing a (proprietary) subclass like ResolvableBug and
> associating the action to that class is very cheap.
>
>
> > One way to strike a better balance is to only refer to the action
> > specifics (including its EntryPoint, etc.) by reference on the bug
> > instances.  Then you're only saying the supported actions and not
> > repeating the action metadata.  You're limiting to processors that can
> > fully dereference objects and re-compose the graph LOD-style, though.
> > Some are limited to one page at a time.
>
> Yeah, that's also a quite elegant solution but unfortunately it doesn't
> really work with the current design as the EntryPoint is associated to the
> action and not vice-versa.


Why does that matter?  (and you can use the reverse)


> When you implement a RESTful Web API you want to modify the bug by
> POSTing/PUTing to its URL and not to the URL of some other resource
> (EntryPoint).
>

The design of schema.org/Action is not prescriptive about whether
EntryPoints are RESTful are not.  You can re-use the resource URL if it
is... or have a generic service urlTemplate if it's not.

-jason


>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
> > On Tue May 20 2014 at 10:58:35 PM, Holger Knublauch wrote:
> > Has there been any discussion around whether it would make sense to
> > allow potential actions for all instances of a class, so that modelers
> > don't need to repeat the same details over and over again? An example
> > use case would be a page listing bugs in a bug tracker. Each bug would
> > have an action to mark it as "resolved". If I understand the current
> > design, the web page would need to include individual Action entries for
> > each bug item, even if they differ with just a single ID. I believe it
> > would be great if this information could be captured once, e.g. via a
> > property "potentialInstanceAction" attached to the type of those bug
> > items, where the urlTemplate is parameterized with a field from the
> > instances.
> >
> > Cheers,
> > Holger
> >
>
>
Received on Wednesday, 21 May 2014 19:26:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:41 UTC