Discussion:
Logical grouping of subset <Query> elements
Erik Mogensen
2015-05-21 23:48:13 UTC
Permalink
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:

<Query searchTerms="example" role="subset" title="A1" custom:foo="A1"/>
<Query searchTerms="example" role="subset" title="A2" custom:foo="A2"/>
<Query searchTerms="example" role="subset" title="B1" custom:foo="B1"/>
<Query searchTerms="example" role="subset" title="B2" custom:foo="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

<Query searchTerms="example" role="subset" title="A1" custom:foo="A1"
group="A"/>
<Query searchTerms="example" role="subset" title="A2" custom:foo="A2"
group="A"/>
<Query searchTerms="example" role="subset" title="B1" custom:foo="B1"
group="B"/>
<Query searchTerms="example" role="subset" title="B2" custom:foo="B2"
group="B"/>

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-
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.
DeWitt Clinton
2015-05-22 01:51:56 UTC
Permalink
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
Post by Erik Mogensen
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
<Query searchTerms="example" role="subset" title="A1" custom:foo="A1"/>
<Query searchTerms="example" role="subset" title="A2" custom:foo="A2"/>
<Query searchTerms="example" role="subset" title="B1" custom:foo="B1"/>
<Query searchTerms="example" role="subset" title="B2" custom:foo="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
<Query searchTerms="example" role="subset" title="A1" custom:foo="A1"
group="A"/>
<Query searchTerms="example" role="subset" title="A2" custom:foo="A2"
group="A"/>
<Query searchTerms="example" role="subset" title="B1" custom:foo="B1"
group="B"/>
<Query searchTerms="example" role="subset" title="B2" custom:foo="B2"
group="B"/>
Now the UI can group the As together under the heading "A", and group the
Bs together under the heading "B".
A1
A2
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-
--
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
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.
Erik Mogensen
2015-05-22 11:03:42 UTC
Permalink
Post by DeWitt Clinton
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-
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.
Erik Mogensen
2015-05-22 12:29:32 UTC
Permalink
Post by DeWitt Clinton
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

<Url
template="http://example.com/search?q={searchTerms}&related={semantic:related?}"
.../>
<Url template="http://example.com/people?q={searchTerms}"
rel="http://a9.com/-/opensearch/extensions/semantic/1.0/taxonomies" />
<Url template="http://example.com/geonames?q={searchTerms}"
rel="http://a9.com/-/opensearch/extensions/semantic/1.0/taxonomies" />

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:

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

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:

<Url
template="http://example.com/search?q={searchTerms}&related={semantic:related?}"
.../>
<Url template="http://example.com/people?q={searchTerms}"
rel="http://a9.com/-/opensearch/extensions/semantic/1.0/taxonomies"
*semantic:label="People"* />
<Url template="http://example.com/geonames?q={searchTerms}"
rel="http://a9.com/-/opensearch/extensions/semantic/1.0/taxonomies"
*semantic:label="Places"* />

...

The Query elements from a search response:

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

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-
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.
Erik Mogensen
2015-05-26 13:04:28 UTC
Permalink
Post by Erik Mogensen
The result contains a number of <Query role="subset"/> elements,
<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
Canada (111) NZ (222)
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"/>
<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"/>
<facet:Group title="People"/>
<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"/>
...
</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
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/opensearch.
For more options, visit https://groups.google.com/d/optout.
Loading...