Re: Question about implementing triple pattern fragments client

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.

Best,

Ruben

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