Re: Fwd: Hydra and Shapes

Tomasz,

this is pretty much what we have implemented in our Graphity Linked
Data processor: https://github.com/Graphity/graphity-client
We use SPIN constraints to validate input data and constructors to
define structure of class instances.

Loading of the remote ontology by the client is not implemented yet.
It is already advertised by the server however -- notice the Link
header:

curl -i -H "Accept: text/turtle" http://linkeddatahub.com/?offset=0&limit=20

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: "c5c6a514889c25e1"
Link: <http://graphity.org/gp#Space>; rel='type'
Vary: Accept
Content-Type: text/turtle
Content-Length: 2209
Accept-Ranges: bytes
Date: Wed, 26 Nov 2014 16:27:54 GMT
X-Varnish: 1895156200
Age: 0
Via: 1.1 varnish
Connection: keep-alive


Martynas
graphityhq.com

On Wed, Nov 26, 2014 at 4:29 PM,  <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
>
> 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 16:30:43 UTC