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

On Monday, February 17, 2014 10:04 PM, Ruben Verborgh wrote:
> >> hydra:freetextQuery.
> >
> > What does that mean? Map a IRI template variable to
> > hydra:freetextQuery? No
> > subject would have that property so a) wouldn't work, but probably
> > you mean something else anyway.
> 
> It would mean that x matches the freetextQuery y.
> Or if you wish, we could have:
> 
> <x> hydra:matchesQuery <y>.

Isn't that (sligthly) inconsistent with the strict model you proposed? Or do
you look at it as a triple which just isn't materialized?


> > The result of dereferencing /?blockbuster=true could now be defined
> > to be (document POV)
> >
> > </?blockbuster=true> hydra:member </hanks> .
> >
> > Because if you'd go and dereference /hanks you would find a property-
> > value pair ex:blockbuster true (even though it's subject isn't /hanks).
> 
> Okay, but this is very, very vague.

It's simple, but not vague IMO


> Hanks has played in non-blockbuster movies too.

Sure, does that matter? It's the same as with full text search.. there are
probably other words there as well.


> Hilton might have dated an actor how played in blockbuster movies.

Right. If that information would be in the representation at /hilton it
would be included in the result following that model. In my example, that
information wasn't there though.


> And I'm serious about that last example,
> because nowhere we've said that the path length is bounded to one or
> two.

That's why I initially called this "document-based search" to describe its
functioning.



> So why would a client expect
>    Hanks ==starredIn==> Forrest Gump ==hasStatus==> blockbuster (2
> hops)
> to be a match, but not
>    Hilton ==knows==> Charlie_Sheen ==starredIn==> Wall Street
> ==hasStatus==> blockbuster (3 hops)

I think the explanation above clarifies it. If /hilton would contain the
information above, it would be included in the result set.


> That would be quite arbitrary

Just as arbitrary as a Google search is in principle :-P


> (and the reason I'd still argue that ex:blockbuster doesn't carry a lot
> of meaning in this case).
> 
> > I find that to be quite useful but I also see how you probably would
> > like to restrict it in certain scenarios as you suggested.
> 
> > Does this clarify it? Does it make any sense to you?
> 
> Yes, I see the two scenarios, thanks!
> 
> I'd be strongly in favor of supporting them both:
> i.e., being able to say that a property _directly_ applies to elements
> of the resulting collection resource,
> and being able to say that it doesn't directly apply to the elements
> themselves.
> 
> (And, in the latter case, perhaps say how it does apply then, maybe
> through property paths.)

I think realizing this the other way round would be easier, i.e., the
generic solution (aka document-based) looks at all property-value pairs in a
representation (ignoring the subjects). The specific solution looks just at
the properties in specific locations. If you want it to be on the subject
itself, you have a property path of length 1.

Another thing we need to clarify is what using multiple properties means.
Are they combined using ANDs or ORs? I would argue that setting it to ANDs
is the most useful choice (you can emulate ORs by doing multiple queries). I
would also say that Hydra, at least the core vocabulary, should stop there.



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 18 February 2014 18:28:08 UTC