Re: Link relation type to link to discover LDP

On Jun 16, 2015, at 5:21 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
> Hi Greg/Kjetil,
> 
>> 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.
> 
> 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?
> 
>> But that won’t teach me about the specifics about, e.g., how TPF requires the RDF terms to be syntactically encoded...
> 
> This is part of the Hydra Core Vocabulary, which is a prerequisite for clients:
> http://www.hydra-cg.com/spec/latest/core/#templated-links

OK. So part of this is my misunderstanding that the rules for syntactic encoding are specified by the core hydra spec.

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 “?”.


Also, as a separate issue, both specs might do well to discuss RDF 1.1 semantics where literals always have a datatype. If you want to continue supporting syntactic forms without the ^^ syntax for xsd:strings, that should be mentioned explicitly. Similarly, the rules for literals with languages should explicitly ignore the rdf:langString datatype, as this will be implied by the @lang syntax.

>> This does nothing to "explicitly explain to the client what TPF is". It only uses hydra to describe that the API has three parameters that correspond to RDF subjects, predicates, and objects, and how to stuff those into a URL template.
> 
> …and that the dataset can be searched by these parameters (hydra:search).
> 
> Which is everything the TPF interface does really.
> 
>> Consider what would happen if I decided I wanted to create a new API that was similar to TPFs, but had a different way to express the triple pattern.
> 
> This would then not use the default hydra:variableRepresentation
> which is assumed for hydra:IriTemplate.

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.

Basically, it seems like you want tools to identify TPF APIs simply by their use of hydra and then by duck-typing based on the API parameters instead of just making it explicit. Is there a reason to *not* add a type triple here? Simply to avoid having to iterate over all of the API parameter mappings to verify that it’s a TPF API, explicit typing would seem like a win.

>>> 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. 
> 
> Agreed that TPF responses currently do not express
> that their will be a) count metadata and b) a TPF control.
> 
> I didn't express that because the client can see it in the current response.
> But indeed, the client has no way to assume that if
> it uses the form, it will also get count metadata and a TPF control.
> However, it will know that it gets the data that corresponds to the pattern,
> by definition of the hydra:search predicate.

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. I still believe that it would be trivial to create a new API that differed from TPF, but that shared the same hydra:search data.


>> Even worse, the rules for encoding the URL for this API are different than those for TPF:
> 
> Then the IriTemplate should use a different hydra:variableRepresentation ;-)

Is the intent here that those are the only two options? The hydra spec says, "The serialization of an IriTemplate's variables can be described by setting the variableRepresentation property to BasicRepresentation or ExplicitRepresentation.”


thanks,
.greg

Received on Tuesday, 16 June 2015 18:24:31 UTC