Re: Fwd: Hydra and Shapes

On 11/25/2014 8:23, Markus Lanthaler wrote:
> On 19 Nov 2014 at 06:34, Holger Knublauch wrote:
>> I also believe that Hydra clients could benefit from the ability to
>> handle additional constraints, e.g. to validate user input on forms such
>> that startDate must be before endDate. From how I understand Ruben's
> Definitely but the question (and I think the Data Shapes WG will face the
> same) is where to draw the line. It also depends a lot on what the primary
> use case for a technology is. For Hydra it is the description of Web APIs to
> allow smarter (semi-)automated clients. If something doesn't provide clear
> advantages for that, it is more or less out of scope - at least for the
> Hydra Core Vocabulary. The example you describe above illustrates this quite
> nicely. Being able to specify that a startDate must be before an endDate is
> quite straightforward, but will that (without lots of other knowledge) help
> an automated *client*? Probably not that much. The story obviously looks
> much different if the intention is to use this information to render a UI
> that is then operated by a human (but humans are actually smart enough to
> understand this "relationship" without a lot of additional metadata).

I think it will be perfectly possible to automatically verify checks 
such as endDate > startDate on a JavaScript client. Here is how it would 
work:

1) Client receives a resource in JSON-LD and wants to display an edit form
2) ... looks up the rdf:type/@type of that resource: schema:Event
3) Client can look up the definition of schema:Event and will learn (in 
.ttl)

schema:Event
     a rdfs:Class ;
     spin:constraint [
         a shape:OrderedPropertyPairConstraint ;
         arg:property1 schema:startDate ;
         arg:property2 schema:endDate ;
     ] ; ...

4) If that shape:OrderedPropertyPairConstraint is widely agreed to 
represent things such as startDate < endDate then the client can display 
that info to the end user as annotations to the form, and check this 
info in the input fields.

5) If however the client doesn't know anything about 
shape:OrderedPropertyPairConstraint, it can go the web and look up its 
definition, which would be something like

shape:OrderedPropertyPairConstraint
     a spin:PropertyPairConstraint ;
     spin:constraint [
         a spl:Argument ;
         spl:predicate arg:property1 ;
         spl:valueType rdf:Property ;
     ] ;
     spin:constraint [
         a spl:Argument ;
         spl:predicate arg:property2 ;
         spl:valueType rdf:Property ;
     ] ;
     spin:body [
         sp:text """
                 ASK WHERE {
                     ?this ?property1 ?v1 .
                     ?this ?property2 ?v2 .
                     FILTER (?v2 <= ?v1) .
                 }
             """
     ] ;

etc. which provides detailed instructions for a *generic* client on 
which SPARQL query to execute to verify that the current instance 
(?this) fulfills its constraints. This means that if a client-side 
SPARQL engine exists, and the input form provides data binding with a 
client-side Graph model, then the client can understand constraint 
templates that it has never seen before.

>
>
>> work, it is probably only a matter of time before there is a SPARQL
>> engine implemented in JavaScript, and this would mean that clients could
>> process complex SPIN constraints.
> What kind of clients do you have in mind? Browser-like clients or
> (semi-)automated ones?

See above.

>  From the discussions we had on this list in the past, there would be huge
> interest for something like that. I personally see heaps of applications for
> that. I do not think that such "advanced features" belong in the Hydra Core
> Vocabulary but I would fully support the creation of other, specialized
> vocabularies to support this functionality. That being said, people could of
> course also simply use SPIN for this. Do you have a simple prototype (web
> app) that leverages this?

We use SPIN server-side only, as part of the SPARQL Web Pages 
infrastructure that we use in all TopBraid products. For example, this 
validates a form when the user hits enter. A client-side version of that 
should work as described above, assuming that a JavaScript SPARQL engine 
exists.

Cheers,
Holger

Received on Tuesday, 25 November 2014 01:22:57 UTC