W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Re: Question about implementing triple pattern fragments client

From: Ruben Verborgh <ruben.verborgh@ugent.be>
Date: Wed, 21 Jan 2015 13:19:50 +0100
Cc: public-linked-data-fragments@w3.org, Kjetil Kjernsmo <kjetil@kjernsmo.net>
Message-Id: <3266293D-A6AA-4EA0-8EDA-A94D61EBF523@ugent.be>
To: Gregory Williams <greg@evilfunhouse.com>
Hi Greg,

>> You're right. How about making it a SHOULD in the spec,
>> detailing the reason (i.e., only needing controls)?
> Yes, Iíd be very happy to see the spec recommend paging (and mention potential pitfalls if implementations chose not to do paging).

Likewise; tracked in issue 92: https://github.com/HydraCG/Specifications/issues/92

> Understood. What Iíve been trying to communicate, though, is that the spec leaves a lot of choices to the implementation, without discussing the impact of those choices.

That's a very good remark.
Even if the spec leaves options open, it should explain the consequence of the choices.

>> Note the similarity with SPARQL query <form>s, which are also not specíed.
> I donít understand the comparison here. Could you explain?

The original point was: should we have a resource with only a hypermedia control?
My reply to that was: sure, that's possible, and we don't even need to spec it.

The SPARQL Protocol spec explains how to build a query request,
i.e., which key/value pairs to use in the query string etc.
The spec doesn't say you should (or shouldn't) create a <form>
that enables users to execute such a query easily.

In practice, all SPARQL endpoints I know provide such a form.
This illustrates that a control-only resource is possible
without explicitly needing to specify it.

>> (Since the TPF spec is, as far as I know, the first spec for a hypermedia API,
>> we are obviously still learning here. An editorial review is in progress BTW.)
> Yes, understood. And I hope my feedback is taken as trying to help that process, not just complain.

Certainlyófor any learning process, feedback is crucial. So thanks for that!

> My suggesting a separate API for accessing triple counts was a suggestion for a possible way to deal with problems that occur without paging, though Iíll admit it isnít the nicest solution. My problem (and proposed solution) essentially goes away if the spec recommends paging (and if work on query execution using TPF talks about what happens if paging isnít used).

Yes, I agree that paging is vital, and the spec should recommend it. Good catch.

>>> Iím afraid I wasnít very clear about my concern here. The NOTE in section 3.6 talks about what the server should do when it receives various requests from a client. It gives two example URLs that seem like they should reference the same resource, the first with "?s=a&page=3Ē and the second with "?page=3&s=aĒ. The text doesnít indicate where those URLs came from. Weíre left to assume that they originated with the server, but intuitively the server should have only generated one of those (either that or the server implementation is order-agnostic with respect to the query parameters).
>> This paragraph is supposed to mean:
>> ensure the IRI you use to describe the fragment with in your representation
>> is exactly the same IRI through which the fragment was requested.
> If thatís all youíre trying to say, then I think weíre in agreement (on both the intended point and the desire for a simpler example).

+1, tracking this in https://github.com/HydraCG/Specifications/issues/93

Thanks for your valuable input, and please keep it coming!
I will notify when issues 92 and 93 are resolved.


Received on Wednesday, 21 January 2015 12:20:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 January 2015 12:20:22 UTC