RE: Fwd: Hydra and Shapes

Hi Holger,

and welcome to the list.

On 19 Nov 2014 at 06:34, Holger Knublauch wrote:
> 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.

It really looks as we share the same vision then..


> 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

Yep.. and the thing that makes this particularly "funny" is that Hydra and
OSLC Resource Shapes were both presented in the same session at LDOW2013 [3]
:-) Unfortunately, however, there haven't been concrete efforts to
collaborate till now.


> 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

Cool! Thanks for taking the time to create and sharing that.


> "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'm including the discussion you already had with Ruben here:

On 20 Nov 2014 at 04:17, Holger Knublauch wrote:
> On 11/20/2014 3:04, Ruben Verborgh wrote:
>> Simplicity really, and scope.
>> Also, this is something that OWL can do; after all, the properties are
>> still "properties" in the RDF sense, so everything that applies to RDF
>> also applies here.
> 
> I guess this will need to be clarified some more. Yes, until now OWL and
> RDFS were the main vocabularies to represent something like
> "constraints". But as we all know, OWL and RDF Schema are really not
> designed for that purpose, but are rather languages to infer new triples
> under the open world assumption, not to constrain assertions in a closed
> world sense. The Shapes group will produce some vocabulary for closed
> world checking, and the interpretation of that vocab will arguably be
> much closer to what average developers would expect. So, while you may
> currently rely on OWL/RDFS due to lack of alternatives, I see Shapes as
> a better alternative to the Hydra/LDF use cases.

I couldn't agree more. In fact, IME this fundamental different is the thing
non-RDF experts, i.e., almost all (web) developers struggle most with. OWL
has an extremely steep learning curve and even if you master it, it was not
really intended to be used this way but to infer new triples as you say -
yeah, the Schema in RDF Schema doesn't help either :-) So, in Hydra we
really wanted to create the simplest possible solution which *looks
familiar* to developers... it should feel intuitive to them.


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


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


> 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

Right.. and I think being able to describe/define a constraint in an
unambiguous, machine-processable way instead of just falling back to natural
language is *very* valuable.


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

+1


> It is apparent that the Shapes group will produce such a high-level
> vocabulary.

That's my understanding as well.

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

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


> All these thoughts prompted me to sign up for this community to see if
> we can somehow join forces.

I sincerely hope we'll find a way to do so.


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

Understood


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

Thanks a lot for reaching out Holger! Let's see what we can achieve
together.. our visions at least seem to be already quite closely aligned.


Cheers,
Markus


> [1] http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#Property
> [2] http://topbraid.org/spin/spinhydra
[3] http://events.linkeddata.org/ldow2013/#programme


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 24 November 2014 22:24:19 UTC