Re: potentialAction for Classes?

Sooner or later this use case asks for a query language that allows 
developers to define pre-conditions for those instances where an Action 
can be applied to. This must already be encoded *somewhere on the 
server*, e.g. in the logic that returns the "Resolve-this-Bug" action 
for instances of Bug where the status = Open. It would be awesome if 
this idea could be taken further and the logic to select valid actions 
be encoded in a format that can also be used client-side. Would be 
another step into a more declarative way of software development. The 
potential action would then be attached to the Bug class, and a 
schema:filter clause would return true for certain instances. In our own 
software stack (TopBraid) we employ SPARQL expressions, i.e. anything 
that would usually appear in a FILTER statement in SPARQL, with 
pre-bound variables pointing to the instance that is being filtered. I 
guess for and JavaScript clients it would need to be a 
JSON-friendly expression language.

Sorry for thinking out loud, and I guess we don't want to over-engineer 
this either so that clients don't need a complex engine before they can 
do anything useful. Yet associating static objects and classes with 
*behavior* sounds like a very powerful step in the evolution of this 
data model. Some of you will know this from the SPIN framework in RDF, 
where rules and constraints are attached to classes, allowing software 
to operate on smart, self-describing objects.


On 5/22/2014 5:17, Markus Lanthaler 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:
> 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. 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).
> --
> 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 23:49:06 UTC