RE: removing hydra:search

Sorry for having been absent for a couple of days.. I'm kind of running out
of time with my dissertation--but that's another story :-)


On Wednesday, February 12, 2014 6:57 PM, Thomas Hoppe wrote:
> Slightly offensive question:
> We are about to drop `hydra:CreateResourceOperation` and the like
> (I don't repeat the pros/ cons here).
> Isn't it inconsequent to keep hydra:search then?!
> For me the same arguments for removing the aovementioned
> operations apply equally to search or do I miss something?

You could look at it that way, yeah. But I wouldn't put hydra:search in the
"Operations bucket". Instead, I would put it in the "Collections bucket".


On Friday, February 14, 2014 11:36 AM, Ruben Verborgh wrote:
> On Friday, February 14, 2014 10:34 AM, Thomas Hoppe wrote:
> > I see hydra as a way to define affordances and yes HTML forms are the
> > analogy.
> > 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.

Indeed. "search" is a standardized link relation [1] but unfortunately these
link relations have not really been defined with an RDF-based model in mind
(we could argue about that, but please let's not :-)) and they don't have an
agreed URL to be used with. So, hydra:search simply represents the
IANA-defined "search" relation in the very specific context of Hydra to be
used with Hydra IriTemplates.


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

Yup. As I already said, at the time when I designed Hydra roughly 2 years
ago actions in schema.org didn't exist yet and there were no signs of them
being introduced. There was also no other vocabulary that could have been
used to illustrated how the concept of operations is intended to be used.
Now we have actions in schema.org and can safely point to them instead.

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

I agree with Ruben. Especially in the context of Hydra Collections it is
highly useful IMO.


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

Exactly. We shouldn't even try to foresee them. We should, however, also not
forget that we need to provide some valuable features to convince people to
adopt Hydra. We could, e.g., also eliminate Collections, Errors
(StatusCodeDescriptions returned at runtime) completely. But we would lose
quite some functionality that almost every developer would have to reinvent
himself. That hinders interoperability. If we find concepts/functionality
which applies to countless APIs, I think we should include them in Hydra. I
believe hydra:search is such an example.


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

Right. We won't be able to model everything in all its details but we have
to provide some basic building blocks developers can build on. In the "worst
case" (if it still works, it's actually the best case), clients can fall
back onto Hydra's generic semantics.

So, summarized, I'm clearly -1 on removing hydra:search at this stage. That,
however, doesn't mean we shouldn't try to improve, we certainly have to.


[1] http://www.iana.org/assignments/link-relations/link-relations.xhtml


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 17 February 2014 17:59:10 UTC