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

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

So what I mean is
?x hydra:matchesQuery "hilton".
similar to
?x foaf:name "Paris Hilton".
where hydra:matchesQuery means that some relevant attribute of any ?x
matches the query "hilton".

For stricter queries, this would have to be placed on a property.

>> Okay, but this is very, very vague.
> 
> It's simple, but not vague IMO

"Vague" for me means that it is unclear what this property applies to.
Yes, it applies to some object that is somehow related to the result,
but the "some" and "somehow" are thus vague to me.

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

So if the model is extended later, it would suddenly match?

I think it would be reasonable to assume, in the case of blockbuster,
that it would only show actors who have been involved in blockbuster movies
(and not happen to have dated somebody who did.)
That's an expectation we have… can we convey that expectation to machines?

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

But this couples your search results to your document's representation structure?

GET /hilton

:Paris_Hilton :gender :Female.
:Paris_Hilton :hasParent :Richard_Hilton.
:Paris_Hilton :hasParent :Kathy_Hilton.
:Richard_Hilton :gender :Male.
:Kathy_Hilton :gender :Female.

would mean that

/actors?gender=Male

could contain :Paris_Hilton?

>> That would be quite arbitrary
> 
> Just as arbitrary as a Google search is in principle :-P

Yes, but then there's a human behind the controls to interpret.
Machines can't do that amount of interpretation.

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

Fair enough—the direction doesn't really matter to me.

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

I agree on that; let's not try to solve all combinations of boolean operators.

Cheers,

Ruben

Received on Tuesday, 18 February 2014 19:11:35 UTC