RE: concerns about hydra:mappings

On Tuesday, January 28, 2014 6:32 PM, Ruben Verborgh wrote:
> 
> Dear all,
> 
> I have three concerns about hydra:mappings I'd like to discuss with
> you.
> 
> I've tried to adapt the example of IriTemplateMapping [1].
> My use case needs two parameters, so what we get is this:
> 
> {
>   "@context": "http://www.w3.org/ns/hydra/context.jsonld",
>   "@type": "IriTemplate",
>   "template": "http://api.example.com/issues{?author,topic}",
>   "mappings": [
>     {
>       "@type": "IriTemplateMapping",
>       "variable": "author",
>       "property": "foaf:maker"
>     },
>     {
>       "@type": "IriTemplateMapping",
>       "variable": "topic",
>       "property": "hydra:freetextQuery"
>     }
>   ]
> }
> 
> According to http://rdf-translator.appspot.com/, this translates to the
> following Turtle:
> 
>     [] a hydra:IriTemplate ;
>         hydra:mappings [ a hydra:IriTemplateMapping ;
>                 hydra:property <foaf:maker> ;
>                 hydra:variable "author" ],
>             [ a hydra:IriTemplateMapping ;
>                 hydra:property hydra:freetextQuery ;
>                 hydra:variable "topic" ] ;
>         hydra:template "http://api.example.com/issues{?author,topic}" .
> 
> My concerns are the following.
> 1) In the Turtle version, you can see that "mappings" is a misnomer;
> this should actually be "mapping".
> There can be one, there can be multiple, but the argument is not a
> list, so it should be singular.
> This is a more general Hydra issue, which I will address in a separate
> mail.

OK, this has turned into ISSUE-25 in the meantime.


> 2) The range of hydra:property is currently undefined (in the text, not
> in the schema);

That's a bug in the JavaScript rendering these definitions then. I've filed
ISSUE-29 and will look at it when I touch the spec the next time (which
should be shortly).


> I think this should be updated to:
> - Domain: hydra:IriTemplateMapping
> - Range: rdf:Property

"property" is also used with SupportedProperty (and might be useful for
other things in the future). Thus I didn't set its domain.


> Note also how "hydra:freetextQuery" translates to the correct URI,
> while "foaf:maker" does not, but that's probably a mistake on my side.

Yep, you need to define the "foaf" prefix in your context. Otherwise a
JSON-LD processor interprets it as a URI scheme. The simplest thing you
could do is to change your context to

  "@context": [
    "http://www.w3.org/ns/hydra/context.jsonld",
    { "foaf": "http://xmlns.com/foaf/0.1/" }
  ]



> In general, I think it's important to emphasize in 5.2 that the value
> is a URI, and not a string; I didn't get this during the first pass.

Good point.


> 3) How should a client pass the value in the template?
> Given the example above, ?author maps to foaf:maker.
> But what value should be put into the URL?
> The URI of the maker, that person's full name, or only last name and
> initial?

That's a general problem I would say.. especially if you use schema.org
data.


> And in any of those cases, how do we communicate that?

Good question, at the moment there's no way to communicate that. It relies
implicitely on the property's range which in this case is foaf:Agent. Thus,
the most reasonable thing would be to user the maker's URI.


> Right now, we cannot say "the label of the foaf:maker".
> And then again, which maker are we talking about?
> Is it the result resources which have that foaf:maker as property?
> If it is, that definition doesn't work with hydra:freetextQuery.
> Of course, I understand we don't want to go to deep,
> but I am actually implementing this use case now:
> the client has data and sees this hydra:IriTemplateMapping.
> How can it translate this data into an actual HTTP request?
> Seems like a basic question that Hydra should be able to answer.

Hydra is silent on this. It kind of assumes as input a set of key-value
pairs where the keys are properties and values are scalars (which includes
IRIs). Nesting etc. doesn't really work in such a case.

I don't have a general solution for these issues yet. In principle, we could
do the same things as we do with SupportedProperty (in fact it might even
make sense to make IriTemplateMapping a subclass of SupportedProperty). Do
you have a proposal on how to address the issues you outlined? 

In any case, I've raised ISSUE-30 [2] for this.

 
> [1]
http://www.markus-lanthaler.com/hydra/spec/latest/core/#templated-links
[2] https://github.com/HydraCG/Specifications/issues/30



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 3 February 2014 18:56:05 UTC