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

> The word that worries me a bit is the "they". Let's say we have a collection
> of actors. Each actor appeared in a couple of movies of which each has a
> "blockbuster: yes/no" property. A query template like
> 
>  /actors?blockbuster={blockbuster}
> 
> to get the actors that appeared in a blockbuster wouldn't work in that case.
> As there's "blockbuster" is on "Movie" and not on "Actor". Is that what we
> want? Do we need to define a mechanism to describe such a use case?

That's indeed an issue, it was one of the reasons for my initial mail,
and where I was going with the SPIN vocabulary).

The thing here is that the subject of the triple is not defined yet.
Basically, we have the choice between:
a) the subjects are the elements of the collection ("Actor")
b) the subjects are "related" to the elements of the collection ("Movie starring actor")
Clearly, a) is most strictly defined;
and b) is so loosely defined that we basically cannot infer anything.

This is why I'm strongly in favor of a).
At least this allows a client to know the meaning of the properties it sends.
Then, the tuples become triples, because the subject is defined.

That means that cases such as actor?blockbuster= wouldn't be possible to define.
This is what I meant with “tuples” earlier: “blockbuster” doesn't have a meaning
(even if it has a URI), because the subject is unknown/undefined.
I wouldn't worry about that; there's nothing to do *anyway* in that case.
Unless 1) you define a property starsInBlockbuster and define it with OWL;
or 2) you express the relationship using property paths (à la SPIN).

Note that we might want to use hydra:search exclusively for b),
and create a subproperty hydra:propertySearch for a),
with the more specialized meaning that it searches direct properties.

>  The items in the collection are queried by the specified
>  property-value pairs.
> 
> Is that too fuzzy in your opinion?

Unfortunately, a client can do nothing cool with that loose relation.
(It's basically my case b).
We could keep the fuzzy thing for hydra:search,
but I'd definitely need a non-fuzzy hydra:propertySearch then.

Best,

Ruben

Received on Thursday, 13 February 2014 10:13:03 UTC