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

On Tuesday, February 11, 2014 12:09 PM, Ruben Verborgh wrote:
> 
> > 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?

Honestly, I don't know yet.


> Or could we use another vocabulary for that?
> (Maybe we should check integration possibilities.)

If there's one, why not.


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

I'm not sure whether there's a necessity to make this explicit respectively
how explicit we wanna make it. We can try to define the hydra:search
property in a fuzzy-enough way to not run into the complexities of generic
query languages. I'm don't know how feasible that's it, i.e., how much we
can improve the current description

   "A IRI template that can be used to query a collection"

Do you have any ideas?


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

That depends on how strictly you see that. It might also return things that
are the primary topic of things Pete made. So not directly the things Pete
made.


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

See above


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

I think we have to do something, I'm just not sure yet what.


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

You could provide a hint with "returns", couldn't you?


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

There are a number of mechanisms you can use to reduce that risk. You can
first try to GET that resource and check if it is the thing you expected.
You can of course also leverage other information that's available.. the
operation type, the "returns" hint, the fact that the IRI template is the
value of a hydra:search property on a hydra:Collection etc.

Talking about this stuff too abstractly doesn't bring us far I think. We
should try to come up with examples, define what the client knows and what
it doesn't know, define what information the server provides, and finally
check if the client can achieve its goal with that combined information.
Sounds easier than it is, I know :-)


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 11 February 2014 19:16:09 UTC