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

On Wednesday, February 05, 2014 6:50 PM, Ruben Verborgh wrote:
> >> Right now, we cannot say "the label of the foaf:maker".
> >> And then again, which maker are we talking about?
> >> [.]
> >> 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'm afraid we can't be silent on this if we want this to work.
> Surely, it's quite a can of worms to open, but we have to;
> if left unspec'ed, there's no way for such interactions to happen
> reliably.
> 
> > Do you have a proposal on how to address the issues you outlined?
> 
> 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.


> The other issue is relating properties to items.
> This is something I solve in RESTdesc with quantification;
> for that, I had to leave the RDF model, which is not what we want here.
> 
> I guess we would somehow need to explain the property path.
> Continuing the example, in case the label of that person is necessary,
> instead of hydra:property, we'd need to explain where to obtain that
> label.
> Maybe SPIN can help out here? (http://spinrdf.org/sp.html)

You mean the SPIN version of SPARQL property paths
(http://www.w3.org/TR/sparql11-query/#propertypaths)?

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.


> Maybe there's an additional third issue:
> how whatever properties we send relate to the response we get.

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


> I realize Hydra doesn't aim to solve everything (especially the third),
> and that's fine.
> But passing parameters is a basic thing which we need to get right;
> otherwise, correct invocations of parametrized things are not possible.

Hmm.. maybe collecting a number of concrete use cases and examples would
help to formulate requirements. It sounds as you have already a couple of
them in mind. My assumption till now was that an application simple passes a
set of key-value pairs to a function to expand the IRI template. 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.


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 6 February 2014 17:11:32 UTC