Re: Fwd: Hydra and Shapes

Hi all,

since this is my first message to this community, a brief intro. I am a 
developer at TopQuadrant, working on the TopBraid product line. 
By-products of this work were SPIN and similar languages. More info at

I am also member of the W3C RDF Data Shapes WG but do not speak on their 
behalf - whatever I write here is just my personal opinion, unless 
stated otherwise ;)

I bumped into Hydra via pointers from Phil Archer, and think this 
technology (together with Linked Data Fragments) is very interesting for 
the future web architecture and software development in general. I have 
always believed that there are benefits in not just publishing and 
sharing data between applications, but also to enrich that data with 
metadata that can be used to execute, display, edit, transform that 
data. Get extra bonus points if this metadata itself is represented in 
the same form, i.e. as linked data. I find a lot of the design ideas in 
Hydra resonate well with this vision, from Linked Data to Linked Objects.

The bits that overlap most clearly with the goals of the RDF Data Shapes 
WG seem to be the way that properties are defined. Compare 
hydra:SupportedProperty with Resource Shapes [1], which is one of the 
input specifications of the Shapes group. Both can be represented in 
SPIN using Templates, and I have yesterday added a small SPIN library 
for Hydra [2]. Hydra's supported properties currently only have a 
"required" flag, and I wonder why it doesn't have a more general concept 
of min/max cardinality and the value type/range to support additional 
constraint checking. The SPIN template currently only evaluates the 
"required" flag.

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 
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. Users of Hydra would not necessarily 
have to use SPARQL directly, but they could instantiate SPIN templates 
that encapsulate a SPARQL query. These templates are Linked Data 
resources and clients can look up what they mean, and what SPARQL query 
needs to be executed. I can imagine that such a template library 
(including something like SupportedProperty or its Resource Shapes 
equivalent) would be of shared interest. It is apparent that the Shapes 
group will produce such a high-level vocabulary.

Another feature of SPIN is a simple rule language, based on SPARQL 
CONSTRUCTs. Assuming a client-side SPARQL engine exists, it would be 
possible to define input forms that update one field depending on 
changes to another field (e.g. switch currency when country changes). 
All this would be done declaratively, feeding generic engines and 

All these thoughts prompted me to sign up for this community to see if 
we can somehow join forces. Again, I am not speaking on behalf of the WG 
here, and the WG may very well not agree on using SPIN as an input 
technology. We have just started, and input from this community would 
certainly be welcome. If you would like to contribute specific user 
stories to the WG, feel free to send them to me and I can integrate them 
into the group's Wiki.

Sorry to be very brief on all this, I can surely elaborate.



On 11/18/2014 22:00, Ruben Verborgh wrote:
> Dear all,
> We were mentioned on the Data Shapes list.
> Best,
> Ruben
> Begin forwarded message:
>> From: Anastasia Dimou <>
>> Subject: FYI Fwd: Hydra and Shapes
>> Date: 18 Nov 2014 12:58:30 GMT+1
>> To: Ruben Verborgh <>
>> But surprisingly no one replied last evening.
>> Bests,
>> Anastasia
>> -------- Forwarded Message --------
>> Subject:	Hydra and Shapes
>> Resent-Date:	Mon, 17 Nov 2014 04:05:55 +0000
>> Resent-From:
>> Date:	Mon, 17 Nov 2014 14:03:09 +1000
>> From:	Holger Knublauch <>
>> To:
>> I just added a user story for Hydra
>> This is a W3C community group with 100+ participants, working on what
>> appears to be an overlapping problem space to ours. Their vocabulary
>> includes the notion of "supported properties" which may align with
>> oslc:property, owl:Restriction etc. Like our own WG, this effort is
>> still evolving, so I am wondering whether it makes sense to try to
>> coordinate efforts towards an alignment between vocabularies before
>> things diverge into parallel universes...
>> Holger

Received on Wednesday, 19 November 2014 05:37:03 UTC