Re: Linked Data Fragments: Web-scale querying

Hi Luca,

> But imho as a community we have to strike a balance
> between how much boilerplate we can put on developers hands
> and how much automation we can achieve with that.

We can use libraries to avoid boilerplate.

An HTML form is the standard way
to represent hypermedia controls in HTML.
Parsing an HTML form is straightforward;
if Hydra becomes the (de-facto) standard way
to represent hypermedia controls in RDF,
then parsing it will also be straightforward.

Right now, the snippet I posted is probably perceived
as a collection of triples; they can be hard to grasp.
However, once libraries allow such snippets to be viewed
as just hypermedia controls (which they represent);
it will be as easy as an HTML form.

> So in a way, the extra automation comes with a cost because
> you're asking data-providers to provide extra information that would
> otherwise be somewhat useless if you're not an automated hypermedia client.

That's correct and I'm asking that on purpose.
The alternative is that those data providers can only be used
by clients that are hard-coded for that task. Far less attractive.

Linked Data Fragments are about building servers
in a way that enables intelligent clients.
The Turtle representation of basic LDFs have been purposely designed
to have automated hypermedia clients as consumers.

Everybody is free to build servers that serve other representations;
however, one cannot expect autonomous clients to use those servers
if controls are not provided. That's why Basic LDFs do provide those.

> I think that the fact that basic LDF supports metadata is extremely
> important, but perhaps there can be a way to define some implicit
> metadata in the "basic LDF standard"?

If such implicit rules should exist, API access would be limited
to only those few clients that have these rules hard-coded.

In contrast, any client that can parse hypermedia controls
can access basic Linked Data Fragments.

> Otherwise I can just call my
> service an LDF (very close to basic LDF) and forget about the
> formalities, but it probably won't work with a basic LDF client right?

It wouldn't. And it wouldn't work with a hypermedia client either.
Your service would need a specifically written client to work,
and that's exactly what I want to avoid.

> I'm just wondering if there's a way that we can be less formal but
> still achieve a good balance between automation and usability.

It's not formal; that's just the RDF way to describe hypermedia controls.
Put a library on top of that and you can access those controls transparently.
Alternatively, you can retrieve the HTML representation and use the form.

In short: I'm not providing a hard-coded URL contract
but instead a self-descriptive hypermedia mechanism
in order to serve more clients than just hard-coded ones.

Best,

Ruben

Received on Friday, 21 March 2014 20:29:16 UTC