Re: Hydra and Shapes

Hi Holger,

Welcome to the list!

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

I personally think that shapes would be a more advanced way;
i.e., Hydra's properties cover the basic use cases,
shapes would allow to describe much more advanced responses.

> 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

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.

> From how I understand Ruben's work, it is probably only a matter of time before there is a SPARQL engine implemented in JavaScript

Hey, hey, we have one ;-)
Still working on some features, but test it here: http://client.linkeddatafragments.org/

> Users of Hydra would not necessarily have to use SPARQL directly, but they could instantiate SPIN templates that encapsulate a SPARQL query.

Yes. The benefit of the Triple Pattern Fragments approach
is that clients execute the queries; hence, the query language is not fixed.

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


Here's my two cents:


One interesting application of shapes is for the description of custom APIs.
“Linked Data Fragments” is about *all* possible APIs to Linked Data; i.e.,:
- a SPARQL endpoint offers Linked Data Fragments whose selector is a SPARQL query;
- a data dump offers a Linked Data Fragment of the entire dataset;
- a triple pattern fragments interface offers fragments whose selector is a triple pattern.
And in between all those options, there are many more possible interfaces:
http://www.slideshare.net/RubenVerborgh/querying-datasets-on-the-web-with-high-availability/45

I imagine querying as a dialogue between a client and a server:
- client: What do you have?
- server: I offer this dataset as triple pattern fragments.
- client: *splits the query it wants to solve in the available fragments*

So basically, I expect to see interfaces that offer totally custom fragments,
for instance, fragments that look like this:
    { ?concept a skos:Concept; skos:broader ?other. }
You could interpret the above as
“an API call for broader concepts of the given concept”.

And those APIs… we could describe them using shapes!

What we'd then have is a client that's able to execute queries over arbitrary APIs;
and this works, because the fragments offered by the API are self-descriptive.
This self-descriptiveness already exists with triple pattern fragments
(http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/#controls),
thanks to the Hydra Core Vocabulary.

So yeah, I think… shapes + Hydra Core Vocabulary + LDF = match made in heaven.

Best,

Ruben

Received on Wednesday, 19 November 2014 17:05:29 UTC