Reconsidering template mappings

Hi

I intended to include this in my reply to the ISSUE-30 [1] call for
consensus but I figure it would be a bit off-topic.

The thing is I think that this issue is trying to answer the wrong question.

Let's take a step back and analyze what are the semantics behind a
template mapping and more specifically the property. The documentation
says "Each IriTemplateMapping maps a variable used in the template to
a property", But what does it mean that it maps a variable to a
property? Andreas wrote on GitHub "My view: The IRI of the foaf:maker
is the value which should be passed.". So there is a property
foaf:maker and it's value will be passed as the parameter. But
property of what subject? In that given example it probably means
makers of issues. But how does the client choose one? These are more
important questions IMO.

With the above in mind I think that the mapping should map to a type
(class or datatype) rather than a property. This way it could even be
possible to instruct the client how to produce a parameter value in
cases where they aren't created by the user.

Below is the original example changes. I extended it here to show a
more complete example and removed irrelevant parts.

{
  "template": "http://api.example.com/issues{?author,topic,maxAge}",
  "mappings": [
    {
      "variable": "author",
      "type": "foaf:Agent"
    },
    {
      "variable": "topic",
      "type": "hydra:FreetextQuery"
    },
    {
      "variable": "maxAge",
      "type": "xsd:gDay"
    }
  ]
}

This way it is clear that topic is any string, maxAge is a duration
declared in days and author is an IRI of a foaf:Agent

Still however the client does not know how to choose a foaf:Agent for
the author parameter. Traditionally a HTML page could include a static
list to choose from. Or some javascript code to fill an autocomplete
box.

There are of course multiple ways to empower the client. One could be
to supply the client with another free-text search template, which
would return users or whatever. Or the server could include a
predefined SPARQL quesy, which would execute against an endpoint by
using the SERVICE pattern.

This way hydra would fulfill the code on demand REST constraint. How
would you feel about extending Hydra with such concepts?

Regards,
Tom

[1] https://github.com/HydraCG/Specifications/issues/30

Received on Wednesday, 16 July 2014 19:26:24 UTC