Re: Link relation type to link to discover LDP

Hi Greg,

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

Yes, it seems that hydra:search would be too limited for those cases indeed.

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

I also have trouble with that actually :-)
I don't think the Core vocabulary is currently sufficiently expressive to express such constraints.

Maybe this would also not be the job of the "Core" vocabulary,
and we need some other vocabulary to express this.

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

There's not much more than https://github.com/HydraCG/Specifications/issues/45
to go on at the moment.

The proposal for hydra:filter would enforce the strict semantics
that I am currently (correctly or not?) giving to the hydra:search predicate.
And hydra:search would then be more liberal (but how?).

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

Just a note here: as the interface is now,
nothing can (nor should be) assumed about metadata/controls
that you get back when you use the triple-pattern control.

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

That is a very good observation indeed, we've already seen this
with hydra:variableRepresentation and hydra:search thanks to this discussion.

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

Yes, that seems a fitting comparison!
Hard to say what the right balance is at this point.

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

I agree. It's an ambitious goal, but it feels like the right path in the long term.
And as you remarked above, with TPF being the first Hydra API,
it's hard to find the right balance of what to be explicit about and what not.
So we need more APIs with Hydra Core, that's for sure.

Our plan at my research group is to release
two independent features for LDF the coming months.
Maybe this will help the decision process of some things.

In any case, this thread has highlighted some issues we need to address,
which I will make time for the coming time.

Best,

Ruben

Received on Wednesday, 17 June 2015 20:58:55 UTC