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

On Thursday, February 13, 2014 11:12 AM, Ruben Verborgh wrote:
> 
> > 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.

Which doesn't mean that it's useless. In fact, most similar technologies I'm
aware of (OpenSearch, Elasticsearch etc.) do use exactly that approach by
default.

 
> This is why I'm strongly in favor of a).

How would you, e.g., realize a full-text query using 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).

It depends on how you look at it. That's probably controversial now but if
you look at it from a resource representation (aka document) POV it does
make a lot of sense, IMO anyway. You query the representations based on
property-value pairs and return the URLs that can be used to retrieve those
representations. You look at it more from an RDF point of view in which you
just look at the resources themselves in an (I would argue) abstract manner.
Both have value depending on what you are trying to achieve and as you say
it is possible to have both.


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

That indeed sounds like a good idea to me. What do other people think about
this proposal?


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

That would work for me


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 17 February 2014 18:27:55 UTC