Re: Fwd: Hydra and Shapes

On 11/26/14 10:29 AM, tomasz@t-code.pl wrote:
> 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

Tom

We (OpenLink Software) are co-sponsors and supporters of SPIN. It will 
be supported in Virtuoso as part of our SPARQL VIEWs endeavor. Workload 
has perpetually delayed this implementation, but its coming for sure.

A Javascript based RDF data manager with SPIN support is also a major 
piece of the puzzle re. smart actionable webby-payloads (based relation 
semantics expressed using RDF) .

Kingsley
>
> 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
>
>
>


-- 
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