Re: Fwd: Hydra and Shapes

On 11/24/14 8:20 PM, Holger Knublauch wrote:
> 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.

And in rdfstore.js [1] you have such an engine. Next step, testing it 
out on the aforementioned engine :)

[1] https://github.com/antoniogarrote/rdfstore-js

-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this