Re: Fwd: Hydra and Shapes

Hi Holger

I've also been thinking about using SPIN on the client. In addition to constraint validation I was also thinking about using spin:constructor to allow the client to initialize a state of a new resource. Even better the server can hand out "personalized" CONSTRUCTS to individual clients. I think SPIN on clients can be a best so far realization Roy Fielding's Code-on-demand REST contraint. 

But please correct me if I'm wrong, AFAIK executing SPARQL is necessary but it's not enough to fully appreciate SPIN. And it's a shame that after all those years TopBraid's is probably the sole SPIN implementation. At least I haven't seen any other yet.

Sorry for going off topic here anyway...

Tom

November 25 2014 2:23 AM, "Holger Knublauch" <holger@topquadrant.com> 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.
>
> 
> Cheers,
> Holger

Received on Wednesday, 26 November 2014 15:30:21 UTC