potentialAction for Classes?

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

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.

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.

-jason


On Tue May 20 2014 at 10:58:35 PM, Holger Knublauch <holger@topquadrant.com>
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
>
>
>