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

On Monday, February 10, 2014 11:23 AM, Ruben Verborgh wrote:
> Consider the following scenario:
>     /issues{?author}
> If a client knows that `author` is a string, it will not try put an IRI
> there.
> If the client doesn't know that, it might pass a IRI (instead of the
> author's name).
> The server then will then not find any issues by an author named
> "http://example.org/authors/35".

Well, the underlying all of this is that the client and the server have some
shared understanding of the used domain concepts (and of course also Hydra).
If both agree on what the value space of a specific property is, then it
wouldn't really be a problem.

The problem we have here though is slightly different as you might want to
include the last name of the author instead of its IRI. Currently, there's
no way to express this directly. Hydra currently assumes that the client
"flattens" all the data to simple key-value pairs. How that's done, is
currently unspecified.



> >> 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.
> 
> Could you give an example of that?
> Then we can verify whether all these questions are answered.

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.


> >> 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.
> 
> But you can't just map a variable to a property. What is this property
> about?
> http://xmlns.com/foaf/0.1/maker" is only meaningful if I know to what
> it relates.
> 
> Let me illustrate that.
> "foaf:maker ex:Pete" is as meaningless as
> - foaf:primaryTopic ex:Pete
> - schema:attendee ex:Pete
> - schema:performer ex:Pete
> - dbprop:influence ex:Pete
> - rdf:type
> - owl:sameAs ex:Pete
> - .
> In any of the above cases, the predicate is virtually meaningless

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. That's very similar to the situation where you want to
create a resource. You send the predicate/object pairs and the server then
assigns that thing an identifier.


> because all people on earth have made something, attended something,
> influenced someone.
> Just connecting a predicate doesn't do anything. There is only meaning
> when there is a subject.
> So having the property without subject doesn't add any semantics.
> 
> As a consequence, if we only express what property a variable name maps
> to,
> we might as well have said nothing. Tuples have no meaning: triples do.

I disagree. Tuples, aka key-value pairs are often (but not always) enough.


> >> Fair enough, but what does hydra:property do then?
> >
> > It unambiguously defines the keys in the key-value pairs.
> 
> So not really unambiguously; the subject is still unbounded.

The *key* is unambiguously identified.


[...]
> >> 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.
> 
> 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. The request to the resource has to
be self-descriptive in order for the server to be able understand it. So the
client expresses his intent in the message it sends to the server. Whether
the server is able to fulfill the request or not, you don't know. You'll
find it out by looking at the response. Of course you have some expectations
as to the result of an operation but that's it.


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 10 February 2014 21:18:57 UTC