- From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Date: Wed, 19 Feb 2014 00:07:54 +0100
- To: public-hydra@w3.org
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