Logical grouping of subset <Query> elements

Erik Mogensen

unread,

May 21, 2015, 9:37:06 PM5/21/15

to opens...@googlegroups.com

Hi!

When providing <Query role="subset"> elements, we have a need to put certain such Query subsets together into logical groups.

Say we have a query and there are four subsets, each a value to the "custom:foo" parameter: A1, A2, B1 and B2:

now our UX people want to group the As and the Bs, and provide a header for the As and the Bs.

I don't want them to infer grouping based on the title or even the value of "custom:foo". At the time of making these Query elements, the server knows very well which ones belong together, and even what they "are" so it would be useful for the OpenSearch response to say something about which ones belong together. Say, for example, a "group" attribute

Now the UI can group the As together under the heading "A", and group the Bs together under the heading "B".

A:

A1

A2

B:

B1

B2

Clients showing subset queries in a UI would be suggested that if there are many Query elements, that the group attribute MAY be used to show related Query elements together under the heading of the group attribute. The group attribute doesn't help with e.g. an icon, but we could ignore that for now.

Does this sound like somehing useful? Have I missed a draft that solves this problem?

--

-mogsie-

DeWitt Clinton

unread,

May 21, 2015, 9:52:17 PM5/21/15

to opens...@googlegroups.com

Hi Erik,

Your 'group' attribute looks like a great solution to the problem. To make it valid XML, just stick it in a namespace.

Cheers,

-DeWitt

--
You received this message because you are subscribed to the Google Groups "OpenSearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensearch+...@googlegroups.com.
To post to this group, send email to opens...@googlegroups.com.
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.

Erik Mogensen

unread,

May 22, 2015, 9:50:10 AM5/22/15

to opens...@googlegroups.com

On Friday, May 22, 2015 at 3:52:17 AM UTC+2, DeWitt Clinton wrote:

Hi Erik,

Your 'group' attribute looks like a great solution to the problem. To make it valid XML, just stick it in a namespace.

Yeah, we will probably do that. It's probably not essential enough to make it into the OpenSearch spec; but maybe as an extension?

--

-mogsie-

Erik Mogensen

unread,

May 22, 2015, 9:50:10 AM5/22/15

to opens...@googlegroups.com

Your 'group' attribute looks like a great solution to the problem. To make it valid XML, just stick it in a namespace.

In fact, this grouping doesn't make much sense outside of the custom extension; if there are "datetime" extension is used, clients can infer a lot of grouping themselves.

The real issue was in fact with using the semantic extension, which might want a small change. The semantic extension allows Query elements that specify that results must have some relation to a concept; and my real need is to be able to provide different groups of such Query elements, pertaining to which taxonomy the (additional) facet comes from.

A complete example:

An OpenSearch description document uses the Semantic extension, as follows

I perform a search for "xyzzy" and ignore taxonomies for now (people and places), ending up with the URI

http://example.com/search?q=xyzzy&related=

The result contains a number of <Query role="subset"/> elements, indicating that I can "drill down" into the search results in various ways:

The need I have is in essence to show the people subsets separately from the geonames subsets, preferably with a nice label:

Places:

Canada (111) NZ (222)

People:

Jon Snow (333) Ringo Starr (444)

I've come to the conclusion that what's really needed is a way to link a subset to a particular taxonomy from where the added search term comes from, and my suggestion is (I'll skip the gory details) to add a semantic:label to the <Url> elements that describe the various taxonomies, and re-use that label in the <Query> elements:

OpenSearch description:

...

The Query elements from a search response:

A generic client would be able to present the different types of drill-downs in a "pretty" fashion, by using the labels as prefixes and/or to group the different types of subsets.

--

-mogsie-

Erik Mogensen

unread,

May 26, 2015, 9:06:44 AM5/26/15

to opens...@googlegroups.com

On Friday, May 22, 2015 at 3:50:10 PM UTC+2, Erik Mogensen wrote:

The result contains a number of <Query role="subset"/> elements, indicating that I can "drill down" into the search results in various ways:

<Query role="subset" searchTerms="xyzzy" semantic:related="urn:example:geonames:Canada" title="Canda" totalResults="111" />
<Query role="subset" searchTerms="xyzzy" semantic:related="urn:example:geonames:NewZealand" title="NZ" totalResults="222"/>
<Query role="subset" searchTerms="xyzzy" semantic:related="urn:example:people:JonSnow" title="Jon Snow" totalResults="333"/>
<Query role="subset" searchTerms="xyzzy" semantic:related="urn:example:people:RingoStarr" title="Ringo Starr" totalResults="444"/>

The need I have is in essence to show the people subsets separately from the geonames subsets, preferably with a nice label:

Places:
Canada (111) NZ (222)
People:
Jon Snow (333) Ringo Starr (444)

The grouping should perhaps not be based on an additional attribute on each Query element of the response, but rather rely on the document order of the various subset Query elements, and a custom element in-between these already quite natural (document order) groups.

So instead of "semantic:label" a simple new element could be used to say that "the following elements are of a particular type of facet". (A bit like the "<h2>" element of HTML indicates (to some degree) that the following paragraphs have something to do with this):

<feed>

...

<facet:Group title="Places"/>

<facet:Group title="People"/>

...

</feed>

An earlier proposal I helped out on [1] placed the subset inside a custom element, but I think that's a bad idea because it hides the Query elements from those who don't understand the extension. The OpenSearch specification states: "Clients that encounter unrecognized foreign markup should continue to process the document as if the markup did not appear." — but it doesn't specify if clients should process children of unknown elements (like HTML) or not (like Atom); I have interpreted it as _not_ processing children it doesn't understand. In any case, Atom has the processing model of "must ignore" — so wrapping the Query elements in foreign markup is out of the question.

The (as of yet ficticious) <facet:Group> element would have a processing instruction that indicates that the following opensearch:Query elements (until the next Group element or the end of the current tag, e.g. </feed>) should be presented together under the heading from the "title" attribute.

--

-mogsie-

[1]: http://tihlde.org/~erlenha/draft-hamnaberg-opensearch-filter-00.html

Reply all

Reply to author

Forward