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

Sorry for the delay Ruben 

On Thursday, February 06, 2014 7:43 PM, Ruben Verborgh wrote:
> 
> >> 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".

OK, I got it now.


> 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%2F20
> 01%2FXMLSchema%23integer%3E
> 
> Of course I'm deliberately complicating matters here, but how does a
> client which one to choose?

Yeah, good question. I think it also depends on where we want to move the
smartness. Since you probably have to deal with buggy clients anyway, I
think it might make sense to move it to the server. That doesn't mean
however that we shouldn't specify it.


> The first one is the most logical, but doesn't allow to distinguish
> between IRIs and literals.

Which might not always be necessary.. but you are right in principle.


> > 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.

I'd say the question is whether we can make the simple solution simple
enough.


> > 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?

That's defined by the context in which the IriTemplate is being used I'd
say. If you, e.g., attach an operation to the IriTemplate it should answer
those questions.


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

It answers the question: To which property is this variable mapped? A
variable is simply an arbitrary string. A property, on the other hand, is
unambiguously identified by its IRI.


> > 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?

It unambiguously defines the keys in the key-value pairs.


> Also, how to pass those values?

Yeah, that's a good question. We have to define how to use an abstract RDF
value (typed literal, language-tagged string, IRI).


> > 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

In other words, the lexical representation thereof in the expanded IRI
template.


> b) how the values relate to the current resource

IMO that depends on the context in which the IRI template is used. I'm not
sure we can specify that generally. Or do you think we could? If so, how?


> c) how the values relate to the requested resource

They are part of its IRI, i.e., they help to identify it. If the response is
RDF, you might or might not find them in it.



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 9 February 2014 14:00:12 UTC