Re: removing hydra:search

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

> 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

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

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

Best,

Ruben

Received on Friday, 14 February 2014 10:36:42 UTC