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

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

Also true.
I think we should at least enable well-behaving clients to do the right thing.

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

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

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

+1

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

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

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

>> a) how the values have to be specified
> 
> In other words, the lexical representation thereof in the expanded IRI
> template.

Yes.

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

It does depend on the context, but how?
See above: either we specify that or the property is meaningless.

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

Best,

Ruben

Received on Monday, 10 February 2014 10:24:05 UTC