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

> Hydra currently assumes that the client
> "flattens" all the data to simple key-value pairs. How that's done, is
> currently unspecified.

And would it be Hydra's task to specify this?
Or could we use another vocabulary for that?
(Maybe we should check integration possibilities.)

> An example would be a collection that contains things that have a foaf:maker
> property. Now, if the IRI template that's the value of hydra:search contains
> a foaf:maker property it would be reasonable to assume that you can query
> the collection by the entries' foaf:maker property.

Makes sense.
Is there a way/necessity to make this explicit,
or does the fact that foaf:maker is used with hydra:search
imply that the collection contains things with a foaf:maker property?

In the latter case, we should mention this somewhere.

> Is it? What if you take the things above and wrap them in brackets:
> 
> [ foaf:maker ex:Pete ]
> 
> You know there's something whose maker is ex:Pete, but you don't know that
> things identifier.

May I conclude from this that the template identifies all things that have Pete as a maker?
(i.e. SELECT ?thing WHERE { ?thing foaf:maker ex:Peter. })

So given the template

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

Does this _always_ mean
"the resource identified by the instantiated template is restricted to things made by Peter"?

That would be interesting and meaningful, but then we could/should spec it.

>>> 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.
>> 
>> So there is no way to know in advance?
>> And what if it is a POST request?
> 
> I'm not sure I understand your questions.

So I'm still desperately looking to attach meaning to the tuple :-)
I really want to know, this foaf:maker thing and the object I'm passing to it,
how will it be used?
Like you say, I can inspect the response, and "might or might not find them";
however, I'd rather know in advance whether they are expected to be in there;
otherwise, I'm just firing requests in the hope of finding something.

That can be dangerous with unsafe requests such as POST requests.
Being unsure if something happens and then executing a POST request
only to find out that something did or didn't happen, can be irreversible.

Best,

Ruben

Received on Tuesday, 11 February 2014 11:09:10 UTC