Re: removing hydra:search

On 02/14/2014 11:36 AM, Ruben Verborgh wrote:
>> I see hydra as a way to define affordances and yes HTML forms are the analogy.
> OK, but the big difference is: you understand English labels and legends; machines don't.
> This is why map the properties to URIs.
> But that alone is insufficient: to what subject/context must these properties be applied?

Definitly, this is one of the major challenges hydra must cope with.
>> I cannot, however, follow it in the case of search as described.
>> There is no concept of a search form in HTML (especially not in association with a collection).
> Not in the HTML specification, but it is a very common use case.
> We can make sense out of search forms; machines can't.
>
>> The reason why some people seem to agree (that's at least the feeling I have) that we
>> should remove these operations is their weak semantics.
> Which is why I'm in favor of giving hydra:search stronger semantics:
> http://lists.w3.org/Archives/Public/public-hydra/2014Feb/0120.html

Yes, I've followed this post because In my current work I have to deal 
with exactly
the question. I'm stretching the scope of this POST a bit I know, but I 
can't help myself,
I have to write this:
I think there are two extremes with regard to features of search-like 
operations:
1.) Simple property based or full text based search
2.) Basically SPARQL based on a resource (a resource or a collection 
thereof can be seen as mini graph and I could sparql it)

If we make hydra:search more like 2.) then I think it's not even named
adequately because this is not 'searching', this is 'querying'.
Maybe we should forsee two or more operations in that case.

>> If you use a dedicated operation from a different vocab such as schema.org's
>> `https://schema.org/AcceptAction`, you can offer the client an affordance
>> which is semantically richer.
> But that set is finite.
> I'd love to express as much as possible on a generic level.
>
> Searching is common, but I don't want an IssueSearch,
> ActorSearch, FriendSearch, FreeTextSearch…
> If we give the correct semantics to hydra:search,
> it can be used for a very wide range of common tasks.

That would be a very pitiable development if we end up like this
but I have reasonable hope that this will not happen if I look
at the popularity of LD and Vocabs meanwhile.
I make a different example which will shed a more positive light on a 
diversity of search operations:

- SparqlQuery
- FullTextSearch
- Filter

The good thing is that this is possible with the freedom to introduce
new operations, so for me it's also ok to keep the operation,
I just wanted to make my points clear.

>
>> The question is whether we want to try to forsee which afforances will be ever be required
> No, we can't… but we can be generic to some extent.
>
>> I think the variety of real-life requirements for operations is too high,
>> including for search, so that we should define operations in or outside hydra merely
>> as inspirational examples.
> But then Hydra is completely useless to any client I'd like to make.
> Then it's just a way of decorating form fields with properties.
> RDFa can do that.

I will pick up this topic in my answer to Markus' post.

>
> Best,
>
> Ruben

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