Re: Link relation type to link to discover LDP

On Jun 17, 2015, at 8:18 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
> To start with the "how" part: do you have suggestions?
> For instance, I could imagine something like:
>    <> a ex:TriplePatternFragment.
> But such a triple does not say something about the entire API
> (and I don't know how to refer to “the entire API” in RDF,
> because this API consists of all of its resources).
> Perhaps a concrete suggestion could make it easier to argue.

How is this any different from the question of where you place the hydra:search triple?


>> But you still think that using a custom variable representation should be the one and only way that a client should identify the sort of API that is being described? Do you believe that no two APIs should ever share the same set of parameters and variable representation rules?
> 
> Certainly not.
> It is my intention that the API communicates in RDF:
> “you can search the dataset by triple pattern”.
> 
> That way, if another API does something different with the same input,
> clients will recognize and interpret that.
> For instance, another API might say
> "you can generate a JPEG with this triple pattern” (just saying).
> 
> Do these APIs share the same representation and parameters? Yes.
> Are their descriptions the same? No, because the second API cannot state
> that it will search a dataset by triple pattern.

OK, play this out with me, then. In what specific way would the control RDF differ between the TPF API and the “generate a JPG with this triple pattern” API?

<http://example.org/example#dataset>
    void:subset <http://example.org/example?s=http%3A%2F%2Fexample.org%2Ftopic>;
    hydra:search [
        hydra:template "http://example.org/example{?s,p,o}";
        hydra:mapping  [ hydra:variable "s"; hydra:property rdf:subject ],
                       [ hydra:variable "p"; hydra:property rdf:predicate ],
                       [ hydra:variable "o"; hydra:property rdf:object ]
    ].

Could this be a valid control description for the JPG API?


>> Because this is exactly the sort of case that causes duck typing to fail.
> 
> But duck typing should not be used to find out what type something has.
> I.e., “it quacks like a duck, so it must be a duck” is a fallacy,
> but “this thing supports quacking, and I just want to quack” works.

Which seems like a failing proposition if the thing that quacks actually turns out to be a JPG of a duck instead of the actual duck! :)


> And this is what I believe intelligent clients should do. I imagine a dialog:
> S: Here are my hypermedia controls.
> C: Aha, I can search the dataset by triple pattern, that's what I wanted.


But in the TPF vs. JPG example, what you want almost certainly ISN’T just “search the dataset by triple pattern”, but “search the dataset by triple pattern AND get back the corresponding triple pattern fragment.” If you can’t tell with any certainty what to expect back from the API, what good is it to a client?

> or
> S: Here are my hypermedia controls.
> C: Aha, I can generate a JPEG with the triple pattern, I don't want that.
> 
> Whether or not the first interface is TPF or something more advanced
> is really orthogonal to the fact that the client wants to search by triple pattern.

Like I said above, I think you have to consider both what the API allows you to search by, and also what you’re going to expect back from the API. There could be lots of APIs that have the same “search by triple pattern” API “signature” that all return their results in different or unexpected formats.


>> But "you can search by triple pattern” doesn’t imply everything that TPF *is*. Otherwise you wouldn’t need a 3500 word spec to define it.
> 
> The spec is for implementers, to ensure that clients of this interface don't need the spec :-)
> (At least that is my aim.)
> 
>> I’m suggesting that clients will need to understand TPF anyway, if they intend to use the API successfully. 
> 
> It really depends what type of client it is.
> If it is a SPARQL evaluator like client.linkeddatafragments.org, sure.
> If it is a generic Hydra client, less so.
> 
> My vision of future APIs is one without specs.
> I.e., a client asks a server: what do you have?
> The server says: “you can execute SPARQL queries
> with up to 2 triple patterns and 1 filter”.

OK. How do you identify “SPARQL” in that response from the server in a way that doesn’t reference the SPARQL spec?


> That seems so much more flexible and interesting than
> ”I implement the SPARQL-API-2TP-1F spec”.

I wouldn’t consider that typing information. The type here is some sort of SPARQL API, while the description of that API would include a description of the API just as you suggest: “you can execute SPARQL queries with up to 2 triple patterns and 1 filter”.

I’m not suggesting that the typing information makes the hypermedia controls irrelevant. Only that they ought to exist along with information about what sort of API it is. That doesn’t necessarily have to be an rdf:type triple, but I have not yet seen an example that would allow me to write a client that could confidently predict whether it will get a triple pattern fragment back from an API request after seeing the just the metadata and hypermedia controls.

> When there is only one interface, like TPF,
> it's hard to argue this point. But as more features arrive
> (and we are working on that), I think this changes.

Funny. That’s the exact reasoning why I think the typing information is critical. When TPF is the only API using hydra, you can just assume that it’s TPF. But if there end up being lots of hydra APIs, and you have a tool that sees a Link Relation URL and dereferences it and finds hydra metadata and controls, how do you recognize that it’s TPF and not something else that just looks similar to TPF?


thanks,
.greg

Received on Wednesday, 17 June 2015 19:28:23 UTC