RE: Link relation type to link to discover LDP

Extremely interesting discussion. I'm a bit late to the party but let me
chime in on a few things. I picked a couple of things (I hope I included
enough context to keep them understanble) from the thread and try to respond
in a single mail instead of spamming all of you with multiple mails.


On 16 Jun 2015 at 12:37, Kjetil Kjernsmo wrote:
> On Tuesday 16. June 2015 11.48.23 Ruben Verborgh wrote:
>> Does that clarify the mechanism?
> 
> Not really. :-) So, there are other requirements of TPFs that aren't
> expressed, like the requirement that TPFs will have metadata (i.e. the
> cardinality of the pattern expressed with void:triples) and the control
> information.

This are requirements for a server to get the "TPF compliant" label. Clients
can discover this at runtime.

> So, by using this interface, you don't know if you will get a TPF, or
> something else.

Correct, but it doesn't really matter IMO. The client will see if the
metadata is there or not in the response. It may even decide to proceed
without the metadata - which is possible but makes it much less efficient.
 


> On Jun 16, 2015, at 3:37 AM, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
>> 
>> On Tuesday 16. June 2015 11.48.23 Ruben Verborgh wrote:
>>> As a human, here is how you know it.
>>> If you visit a fragment (like http://fragments.dbpedia.org/2014/en),
>>> you see "Query DBpedia 2014 by triple pattern".
>>> So this tells you that the three fields listed below it
>>> will act as a filter on the dataset.
> 
> I still feel like I'm missing something. As a human, all that "Query
> DBpedia 2014 by triple pattern" tells me is that I either need to
> already know what "querying by triple pattern" means (already be
> familiar with TPF) or I have to Google the term and learn about the
> TPF API spec.

That's a good observation!


On 16 Jun 2015 at 14:21, Ruben Verborgh wrote:
> Ah, that was not intended. The sentence "Query DBpedia 2014 by
> triple pattern" is supposed to be self-describing. I.e., somebody
> arrives at the page, and "query by triple pattern" makes them
> understand that they can fill out a triple pattern and that this
> will be used to query the dataset. It could be that they need to
> Google "triple pattern", but that notion is independent of the TPF
> spec.
>
> Can we make this sentence more clear?

Maybe we can clarify it by saying something along the lines of

   Query the [DBpedia 2014] dataset by subject, predicate, and/or object

instead of "Query DBpedia 2014 by triple pattern"? The most accurate
description would likely be something like

   Filter the triples making up [DBpedia 2014] by subject, predicate, and/or
object

This is where hydra:filter comes into play, btw.


On 16 Jun 2015 at 20:24, Gregory Williams wrote:
> However, I don't find any reference to hydra:variableRepresentation
> in the TPF spec. I thought that would mean that it uses the
> BasicRepresentation, but the description of the syntactic rules in
> the TPF spec sound more like the ExplicitRepresentation (it includes
> type and language information, for example). But the Hydra spec's
> text regarding both BasicRepresentation  and ExplicitRepresentation
> is different from the TPF rules. For example, the Hydra
> representation rules don't seem to talk at all about how to encode
> variables, while the TPF spec gives the option of an empty string,
> or a SPARQL-style value starting with "?".

Oh, somehow I missed that completely.


On 16 Jun 2015 at 22:22, Ruben Verborgh wrote:
> I wonder if we could add this to the Hydra Core Vocabulary's
> ExplicitRepresentation (even though variables are not in RDF 1.1)?

No. I think we should address this differently, i.e., remove variables from
TPF. Variables just make sense if they are bound to something. We don't bind
them to anything. We just ignore them when filtering the dataset. As such,
they should simply be omitted.


> OK. So to simplify my thought experiment, let's say that I create an
> API that's identical to TPF except in requiring that variables use the
> ?var form instead of an empty string. That doesn't seem to conflict
> with the BasicRepresentation/ExplicitRepresentation rules, but still
> makes the API differ from TPF.

It would conflict with the Hydra spec as ?var would be interpreted as the
string "?var" and (likely) no triple would match.


On 16 Jun 2015 at 22:22, Ruben Verborgh wrote:
> Alright, that case is indeed underspecified.
> You would need to use a different hydra:variableRepresentation though,
> in the (currently unspecified) assumption that ExplicitRepresentation
> allows both empty and ?x notations.

It doesn't. And I don't think it makes any sense to change that. It also
wouldn't be that straightforward as we would need some way to distinguish
between the variable ?x and the string "?x".


On 16 Jun 2015 at 20:24, Gregory Williams wrote:
> Nothing in the hydra:search example in the TPF spec indicates to me
> that a client would be able to know what data it should expect back.

It's not clearly defined, you are right. The assumption is that you get a
view of the resource it is attached to that filter by the specified
parameters (well, my assumption anyway). If you want to also describe what
is returned, you'd need to resort to a hydra:Operation.


On 16 Jun 2015 at 22:22, Ruben Verborgh wrote: 
> Hmm, the spec is indeed vague about this.
> Discussions we had on the mailing list about search
> seemed to imply that hydra:search filters a collection by the given
> properties.

Correct. As you later mention we also planned to introduce a more specific
property hydra:filter to make this more explicit.


On 16 Jun 2015 at 22:22, Ruben Verborgh wrote: 
> To summarize, I see the following action points:
> 
> 1) clarify variable syntax of ExplicitRepresentation

-1

> 2) require TPF interfaces to use ExplicitRepresentation
> 3) better describe hydra:search (provided my understanding is correct)

+1

> 4) clarify that other variable representations are possible

Yes.. but we should also make it clear that that's discouraged as they hurt
interoperability.


On 17 Jun 2015 at 22:58, Ruben Verborgh wrote:
> On 17 Jun 2015 at 22:16, Gregory Williams wrote:
>> 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.

I haven't thought much about this yet but it might still be possible to use
hydra:search for that. hydra:freetextQuery goes in the same direction.. and
that's actually the reason why hydra:search is so weakly defined and why we
discussed the more strictly defined hydra:filter.


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

You could definitely define an operation that takes a SPARQL query as
expected input for instance.


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

The framework to describe something like that should be in the core
vocabulary. But you are right, the concrete concepts like "SPARQL query"
etc. should be defined elsewhere.


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

Yep, that's the general idea. Think of hydra:filter like a parametrized
S(PAR)QL query

   SELECT * FROM ___ WHERE arg1 = val1 AND arg2 = val2 AND ....

 whereas hydra:search is more like the fuzzy queries found in web search
engines.


Cheers,
Markus



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 21 June 2015 14:33:55 UTC