Re: Understanding linked data fragments

Hi Nathan,

> One thing that is currently unclear to me, despite having read the specs multiple times, is exactly what problem "Linked Data Fragments" are solving, other than to simply provide a standardized hypermedia-enabled grouping format for a subset of returned data, its metadata and hypermedia controls.

There are two documents, each with a specific purpose.

– Linked Data Fragments is a conceptual view to capture the characteristics of Web APIs to Linked Data.
It does this by focusing on the type of responses you can receive from a server (= fragments).

—The Triple Pattern Fragments specification details a low-cost hypermedia API to Linked Data.
It responds to triple patterns, and returns a paged response.

These documents thus focus on server-side interfaces.

> Ruben's publications have talked about LDF as being a middle-ground solution to the impracticality of analyzing data dumps versus the heavy server load inflicted by SPARQL queries, but I'm having trouble deriving from the specification the actual mechanism by which LDF provides a querying solution.

So the Triple Pattern Fragments spec proposes a server-side solution:
“you can provide this interface on your server with low cost”.

Additionally, this interface has been chosen so that it enables clients to do interesting things efficiently. In particular, the combination of triple patterns and count metadata allows for efficient BGP execution. However, this is only one of the things this interface enables; other things can be done with it, too.

The query algorithm as such is not part of the specification, because there are many possibilities (of which I've implemented two: http://linkeddatafragments.org/publications/). There is also no need to spec such algorithms, because clients do not need to be compatible with each other. We do spec servers, because they need to be compatible with clients.

> I imagine that if LDF were merely describing a unified metadata/hypermedia/data response format

This is indeed what Triple Pattern Fragments are.

> then there would not be talk of it providing a querying solution, as this would be a problem left up to the server software implementor.

To the *client* software implementor?

We do talk of it as a querying solution, because it _enables_ querying, with lost cost for the server.

> Is the idea to provide cacheable preconstructed responses to common queries using the LDF format, with the hypermedia links to other LDF documents, thus providing the mechanism by which the entire query result can be iterated over?

Responses don't have to be preconstructed (but they can be). The use case you describe is indeed one possibility.
In the case of Triple Pattern Fragments, those "common queries" are triple-pattern queries.

> If I may offer feedback on the specification, a picture speaks a thousand words. Some kind of diagram, or simple example architecture illustrating how LDF is supposed to work from a client-server perspective, would go a long way toward facilitating a better understanding of the LDF concept.

Good point; now tracking this in https://github.com/HydraCG/Specifications/issues/98.
In the meantime, the pictures on the frontpage of http://linkeddatafragments.org/ might help.

> If my question is too large, I'm not out to waste anybody's time

Not at all—please keep asking until you are sure you fully understand. If you think that things were unclear or confusing in the specification, or gave you the wrong impression, please let us know. A good understanding of Linked Data Fragments and Triple Pattern Fragments is important to adoption. (With regard to this: did the abstracts of the two specs help, or not?)

Best,

Ruben

PS You're welcome to use the public-linked-data-fragments@w3.org list for LDF questions. At the moment, it redirects to public-hydra, but this might change at some point (and some people might have filters to receive one or the other).

Received on Thursday, 5 February 2015 09:41:58 UTC