- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Tue, 16 Jun 2015 04:10:16 -0700
- To: Ruben Verborgh <ruben.verborgh@ugent.be>, Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Cc: public-hydra@w3.org
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. Or, I suppose, I could click around and try to infer what the API does by looking at the results. But that won’t teach me about the specifics about, e.g., how TPF requires the RDF terms to be syntactically encoded...
>>
>> As a machine, you can know it as follows. This is what you get:
>>
>> <http://fragments.dbpedia.org/2014/en#dataset> hydra:search [
>> hydra:template "http://fragments.dbpedia.org/2014/en{?subject,predicate,object}";
>> hydra:mapping
>> [ hydra:variable "subject"; hydra:property rdf:subject ],
>> [ hydra:variable "predicate"; hydra:property rdf:predicate ],
>> [ hydra:variable "object"; hydra:property rdf:object ]
>> ].
>>
>> Note how this snippet says exactly the same:
>> "The dataset DBpedia 2014 can be searched by subject, predicate, object”.
>> So we explicitly explain to the client what TPF is,
>> not needing any explicit reference to (and implicit understanding of) the TPF spec.
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. All of the TPF-specifics are hidden in the text of the TPF spec, though. For example, all the rules about how to syntactically encode the RDF terms when filling in the URL template:
- use raw IRI values
- use only double quotes for literals
- use ^^ syntax for datatypes, but do not wrap the datatype IRI with < and >
- variables can be an empty string, or start with a ?
As far as I can tell, there is no way to relate those rules written in the TPF spec to a hydra API discovered on the web by looking only at the metadata and/or hypermedia controls.
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. Let’s say that all three parameters should be expressed as regular expressions instead of either constant terms or variables. My hydra:search might look EXACTLY the same as your TPF version, but the APIs are clearly different. And there doesn’t seem to be any way to tell the difference unless you want to start using NLP to parse the title or description literals.
>>> Is there any indication that the controls I’ve gotten back are TPF, and not some other sort of hypermedia API that happens to also require RDF-based subject, predicate, and object arguments?
>>
>> Yes, the hydra:search predicate does this.
>> It explains that the subject/predicate/object fields
>> are used to filter the dataset (and not for something else).
As described above, I don’t believe this is true.
>>
>>> Especially since the TPF hydra:mapping uses properties that are not TPF-specific (rdf:subject, rdf:predicate, rdf:object), it seems strange to me that there’s no sort of extra typing information that identifies the API as specifically a TPF API.
>>
>> The connection happens with the hydra:search predicate.
>> The genericness of the rdf:* properties are intentional,
>> because this ontology defines these precise concepts.
>>
>> 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.
>
> So, by using this interface, you don't know if you will get a TPF, or
> something else. For example, you could have
>
> <#dataset> hydra:search [
> hydra:template
> "http://example.org/sparql?query=CONSTRUCT%20WHERE%20%7B%20{%3Fsubject}%20{%3Fpredicate}%20{%3Fobject}%20.
> %20%7D";
> hydra:mapping
> [ hydra:variable "subject"; hydra:property rdf:subject ],
> [ hydra:variable "predicate"; hydra:property rdf:predicate ],
> [ hydra:variable "object"; hydra:property rdf:object ]
> ].
>
> Please excuse me if the URI pattern is invalid (I haven't gotten around to
> read that spec yet), the point is to illustrate that 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.
Even worse, the rules for encoding the URL for this API are different than those for TPF:
- Variables have to be SPARQL syntax here, and cannot be the empty string
- Numeric/boolean shorthand syntax is acceptable for literals
- Single-quoted literals are acceptable
- Long-quoted literals (""" and '’') are acceptable
- Datatyped literals must wrap the datatype IRI with < and >
- Blank nodes are allowable in the subject and object positions
If you don’t know about those differences, you might not even get back the RDF results you want (and you almost certainly won’t get back the metadata and controls). You’ll just end up producing an invalid SPARQL query and get back an HTTP error.
.greg
Received on Tuesday, 16 June 2015 11:10:41 UTC