Re: Link relation type to link to discover LDP

On Jun 17, 2015, at 12:53 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
>> 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

Ah. So this does seem like something that’s been confusing the conversation. Does your understanding of hydra:search imply that it couldn’t be used to also implement your vision of more fragments than just TPF (e.g. APIs that are more complex than just triple patterns, up to and including full SPARQL endpoints)? Your interpretation seems like it would conflict with those more complex APIs, which might be why I assumed the other interpretation.


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

OK. Given your interpretation, I’m beginning to understand how you’ve been seeing this. I’d be interested to see a sketch of how you think that might work for something like SPARQL, though, because I’m having trouble thinking about extending your interpretation to something with that level of complexity.

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

I honestly have no idea. Can you link to something in the spec that should make me think that? The definition of hydra:search in the spec is a bit sparse on semantics.


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

Again, I’m not sure. This is running up against my long-running trouble determining how much separation there is between Hydra and TPF. Since TPF is the first API using Hydra, it’s seemed to me that there might be some unwritten assumptions like this that will need to shake out as both specs continue to develop.

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

I hadn’t given that much thought, because my assumptions and initial interpretation led me to believe that it was only through the combination of Hydra *and* typing information that would lead to being able to use the API successfully. Because if you don’t have the typing information, modeling all of the minutiae of TPF is probably an enormous challenge.

This feels like a similar problem to asking if you could model the syntactic rules of hydra:ExplicitRepresentation in RDF instead of just having it be a definition in the spec and using hydra:ExplicitRepresentation as a stand-in for those rules. If I create my own VariableRepresentation for a new API, but there’s no way to encode all the rules that the new representation entails, then clients are still in a position of needing to know about my spec to use the API, right?

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

As I think we’re starting to agree, there may be various paths to the same goal here, but getting there purely through hypermedia controls and more metadata still requires a lot of work.

thanks,
.greg

Received on Wednesday, 17 June 2015 20:17:05 UTC