Re: concerns about hydra:mappings (ISSUE-30)

>> There are two issues that need to be solved. The first is
>> serialization, e.g.,
>> 
>>   [] a hydra:IriTemplate ;
>>       hydra:mappings [ a hydra:IriTemplateMapping ;
>>               hydra:property foaf:maker;
>>               hydra:variable "author" ],
>> 
>> We have to add something like hydra:serialization hydra:IRI,
>> which would then specify a way of mapping entities into values.
>> IRIs are not all that interesting; literals are.
>> Maybe we could just reuse xsd:integer and so on.
> 
> Hmm... I'm not sure I follow. This would just be a restriction of the value
> range, right? If we decide to do something like that on SupportedProperty,
> we could use that solution for both. Serialization is, IMO, the wrong
> term—unless I misunderstood you.

What I meant is, we need to say how the author makes it into the URL.
So for instance:

    http://example.org/{?issue}

Given http://example.org/issues/4676 as the IRI of the author, does this expand to

    - http://example.org/?issue=4676
    - http://example.org/?issue=isu:4676   (assuming @prefix isu: <http://example.org/issues/>)
    - http://example.org/?issue=http%3A%2F%2Fexample.org%2Fissues%2F467
    - http://example.org/?issue=%3Chttp%3A%2F%2Fexample.org%2Fissues%2F4676%3E

In this last option, %3C and %3E are angular brackets < and >.
Now you might wonder why I would want to put angular brackets there.
The reason is that there are cases where you want to differentiate between URIs and literals;
e.g., there is a difference between <http://example.org/issues/4676> and "http://example.org/authors/issues".

So the problem really arises when we want to pass in literals as well.
Given the value "16"^^xsd:integer that needs to make it somehow into this pattern. We have:

    - http://example.org/?issue=16
    - http://example.org/?issue=%2216%22
    - http://example.org/?issue=%2216%22%5E%5Exsd%3Ainteger
    - http://example.org/?issue=%2216%22%5E%5Ehttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer
    - http://example.org/?issue=%2216%22%5E%5E%3Chttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer%3E

Of course I'm deliberately complicating matters here, but how does a client which one to choose?
The first one is the most logical, but doesn't allow to distinguish between IRIs and literals.

> That might be a solution. Unfortunately, it is a quite complex one... e.g. I
> don't really like how they are represented (sp:path1, sp:path2, etc.). I
> think a list would be more adequate.

Absolutely. But it accounts for less cases.
However, it would be acceptable to have a simple solution for common cases,
and no or a more complicated one for uncommon cases.

> Is that something Hydra has to be concerned with? Isn't it the application
> that needs to take care of this? Maybe you have a simple example
> illustrating where it is important!?

It depends on the design goals.
But we have to be consistent in this with relation to hydra:property.

Given the earlier use case

  [] a hydra:IriTemplate ;
      hydra:mappings [ a hydra:IriTemplateMapping ;
              hydra:property foaf:maker;
              hydra:variable "author" ],

there is no way to know what foaf:maker is about.
What role will it play in the template?
Maker of what?
Will we get things this person has made?
Or the profile of the person that made the current thing?

If we can't answer those questions,
maybe foaf:maker isn't useful.
Or put differently: what question does "hydra:property foaf:maker" answer?

> My assumption till now was that an application simple passes a
> set of key-value pairs to a function to expand the IRI template.

Fair enough, but what does hydra:property do then?
Also, how to pass those values?

> It seem as
> you would like to pass a graph or a specific IRI in a graph to a function
> and let it figure out how to find the key-value pairs from there.

I would be interested in knowing
a) how the values have to be specified
b) how the values relate to the current resource
c) how the values relate to the requested resource

Best,

Ruben

PS I have some use cases indeed; will contact you privately first in order not to confuse the list.
If the cases are helpful, I will post them.

Received on Thursday, 6 February 2014 18:43:39 UTC