Re: Link relation type to link to discover LDP

Hi Greg,

>> 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?

The hydra:search triple says "I can search this dataset through …".
Its subject is thus the dataset.

The triple you have in mind (if I understand correctly) needs to say:
"this is a Triple Pattern Fragments interface",
so the subject should be the TPF interface, not the dataset.
Which is something we don't have as a resource currently.

> 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?

No, because the above description says that the IRI template
is used to search the dataset. And thus not to generate a JPG.

> 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?

The hydra:search predicate lets a client know with certainty
that it gets back those triples of the dataset that match the supplied triple pattern.
So as far as the "data" part is concerned, we are covered.

The client does not know at present what "metadata" and "controls" it will get back.

> 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.

Ah alright, this seems to be the basic point then.

My interpretation of "?x hydra:search ?y" is:
"if you perform the request ?y,
 you will get back those elements of ?x
 that match the parameters you supply to ?y".

Your interpretation seems to be:
"you can send these parameters to the server".

Unfortunately, there's not much in the spec to support either interpretation.
I'm basing my interpretation on this mail:
https://lists.w3.org/Archives/Public/public-hydra/2014Feb/0151.html
But maybe we need the more specific filter property (which does not exist yet):
https://github.com/HydraCG/Specifications/issues/45

> 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.

True, but what they all should have in common
(by the interpretation I have of hydra:search)
is that they return the matching elements of the dataset.

So you don't know what metadata or controls to expect,
but you do know what kind of data to expect.

>> 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?

You would need the SPARQL spec for that.
Just like the current TPF response also needs the RDF spec
to define what subject, predicate, and object are.

> 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.

Alright. Would you agree that hydra:search
at least allows a client to expect matching triple back?
If not, would hydra:filter be appropriate?

Is knowing that you will matching triples back sufficient,
or would you also need to know that you will get count metadata
and TPF controls back?

Would you have a (can be vague) idea on how to model this information?

>> 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?

But does it really need to know this type?
I think it's sufficient for a client to know what it can do,
which is what hypermedia controls provide.

Best,

Ruben

Received on Wednesday, 17 June 2015 19:53:42 UTC