Re: removing hydra:search

Aggregated response:

1.) I'd care about my diss and continue afterwards ;)

2.) I agree that you can see search from both perspectives.

3.) I also consider search 'useful' of course, I just wanted to
discuss about consistency and for me it's still not quite comprehensible
to keep search but drop basic CRUD operations but it's ok for me,
no heart feelings here.

Thomas

On 02/17/2014 06:58 PM, Markus Lanthaler wrote:
> 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 Tuesday, 18 February 2014 23:16:52 UTC