- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 16 Jun 2015 14:21:50 +0200
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: Kjetil Kjernsmo <kjetil@kjernsmo.net>, public-hydra@w3.org
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 > 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. >> 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. >> this is encodes a >> single triple pattern SPARQL query, that will return a SPARQL RDF result >> according to the SPARQL Protocol, but it would probably not return >> metadata and control information, that a TPF should. That's true. I didn't perceive this as a problem yet, i.e., the client can just use the form and see what it will GET for metadata and controls (again, for data, it knows). It seems more simple to GET it than to explain that. > 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 ;-) Best, Ruben
Received on Tuesday, 16 June 2015 12:22:21 UTC