Re: Solid Community

Hi all,

> How Hydra positions itself in this new scenario? Should we start considering implications and possible integrations? What do you think?

I’m strongly involved with the Solid project,
and have been involved more closely with Hydra in the past.

So let me give my personal opinion on the intersection
(disclaimer: not the opinion of Solid nor Inrupt).


First of all, there is already a natural connection.
Given that Solid is about publishing Linked Data,
we can put a Triple Pattern Fragments API on top of Solid
in order to query that Linked Data.
And TPF, as you might know, uses Hydra.
This combination was made here:
https://github.com/solid/solid-tpf



Second, Solid currently has a couple of places
where we need to send extra information to the client,
and we currently do that in (sometimes custom) HTTP headers.
One example is WAC-Allow, which we use to communicate
what permissions the user has on the resource.
I’ve never been a big fan of that.
I rather would want us to reply in quads (instead of triples),
and include such metadata in the non-default graph.
That would basically be the equivalent
of a webpage with a <main> for the actual content
and <aside> for things about it.
Such an <aside> could then contain hypermedia controls in-band.
This would be very useful for read/write Linked Data.


Third, forms and shapes are very important to Solid.
We are not using Hydra for that currently,
but shapes are philosophically closely related to forms.
So there are opportunities there too.


Fourth, given that Solid encourages competition between data providers
(https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/#apps-become-views-p-5).
one way they can differentiate themselves
if by offering different API features than their competitors.
Such features could be advertised with Hydra
(https://ruben.verborgh.org/articles/web-api-ecosystem/).

Best,

Ruben

Received on Thursday, 11 October 2018 18:56:33 UTC