Was "RS 20120208 Search": We didn't have this meeting, but had some exchanges by email
Doodle vote for discussion on Search
TODO: add Conf links below

General Questions (Vlado)

My understanding is that the following important questions were not settled on the prev call re Search: Austin, could you please also think about them and participate?

Additional FRs

• Currently we have type, technique, material, agent, place, time.
• "from place" and "from agent" are different FRs, although in the abstract they use the same word: they have different range/thesaurus, one is completed hierarchically, they are defined differently over CRM
• FRthing.docx defines a large number of FRs (TODO Vlado: write overview)

What to search for

Task to decide (Dominic) RS-363

• Currently we search for top-level objects. Are we going to search for objects other than artworks?
  • such as People, Places, Events...? We do not have data for such objects at present (other than their
• Search through sub-objects such as Events (eg "give me objects that were at Auction in Holland between 1600-1700")
  At top level we always search for objects, but inside we can branch off and look for FRs of a sub-object.

Unify FTS and FR search

• Seems obvious: if we have one and a second search, should be able to use them together

Unify Search and "Search to Link"

Vlado: I think "Search to link" should work the same as Search. Currently there's no faceting after search, so it won't work well if there are many results.
Jana: "Link" is a popup, will there be enough space? We've had no UI design for this, so we need design from BVA

Fields

• Facets: same as the FRs
• Display: shorter (less info) than the facets. Decided by Austin RS-289

Query Structure

What grammar/connectives are needed

• Currently we have AND between FRs and OR between multiple values.
  • Do we need AND/OR in other places (e.g. "(type is vase OR place is China) AND material is teracotta"). Austin to decide.
  • Austin: we could need NOT (e.g. "paintings from Rembrandt that are NOT in the Netherlands")
    Another way of describing NOT would be using the facets (but I think this could be complicated).
    Vlado: facets wont't work since:
    1. you'd have to select all places outside Netherlands but since data may change, that's an open set
    2. faceting is operation on the result set (post search)
• Dominic (in his spec): want AND, OR, NOT (but doesn't describe in what scope, i.e. whether general parenthesized groups are needed)
• Vlado: we must recognize that we are building a graph pattern since the target is SPARQL not SQL.
  We should rethink the whole Query Structure concept based on this observation!
• Vlado: queries should be addressable (to bookmark, link to, or put in basket) and editable.
  So a stored query should be loadable into the query widget.
  Query structure and representation has very high impact on these features, so it's a crucial question

What one can do after a search

• view thumbnails, timeline
• (future) view geographical map
• further restrict facets
• make link to a search result or its part (if he started from a post/annotation)
• save Search to Basket
• edit/refine search
• link to (bookmark) search and/or the results from a search

UI look and feel

• Currently it's a form.
  Multiple selected values for one FR are next to each other
• Hollie's mockup is "construct a sentence" with dynamic JS.
  An FR can appear anywhere in the sentence; connectives are not very clear; editing a query will be harder.
• Jira advanced search is "grammar-based auto-completion": completes not only thesauri values, but also keywords (FRs)
• Jira HP-Palm Search is "structured entry", very useful for searching sub-object data, eg "give me objects that were at Auction in Holland between 1600-1700"

Important considerations

• how much effort to spend on these various features
• the UI should reflect the Query Structure
  There are many ways to linearize a graph into an expression/sentence, which adds accidental complexity: for the user, and for query save/load/edit (bad).
• wild thought: maybe a graph-based widget is better?
  Consider this paper: []

Questions on Search Spec (RS3.3, Dominic)

Questions by Maria

• Explore Option - "allow the user to use the selected result as an anchor for an explore and browse"
  • Q1: Could you give some examples of what you expect to explore/browse for and what the result of this functionality should be?
    Maybe if we find:
    "Andromeda painting with the following details - Rembrandt (Actor),1630 (Date Of Creation), Den Haag (Place),panel (oak) (Support Material),oil paint (Technique)" you expect that if we click on Den Haag - then we will explore what - all painting, or sculptures, or artists from Den Haag? Or if we click on panel (oak) then we will find all museum objects made from panel (oak)? But are we going to stick to the already selected search criteria, or this is a new search? If it is a new search why the user don't just capture the new search criteria ?

In the USe case you explain a bit more in details "The explore function allows them to extend the browse to other datasets not in the original search. They select all datasets and then select the place concept and person concept. The explore function then explores connections between the anchor object and objects connected. The user can reduce the number of relationships that the explore system uses."

• • Q2: How the user is going to extend the number of datasets - by refining the search criteria by adding new datasets or you imagine it some other way?
  • Q3: Does the place concept and person concept means that we will be only able to explore the persons and places ?

• From the UC: "The system should show some additional details for an object that the user selects or highlights."
  • Q4: What is expected the system to do when the user "highlights" an object detail?

• From functions list "5. Results should be set out in an efficient light box arrangement with the ability to configure the summary metadata available."
  • Q5: What is the meaning of "summary metadata"? Do you expect each user to define what metadata to see for a the search result ?

Dominic's Considerations

Gathered from various emails and page comments

• the term artwork is probably not correct. (object should be fine as a generic term for different objects).
• The only FR's are "from", and essentially "has type". We should have a look at the BM and rembrandt sets to see whether it is worth extending this to some other of the FRs.
  • I also wonder if, in the absence of other FR's being apparent in the mappings that these might be developed further as part of the user enrichment process and perhaps should have some alignment with Link annotation.
  • What would be the effect of adding some of these FR's in at this point?

Search UI

I prefer Hollie’s design for search and I can’t see that it won’t do the same thing as the Jira preformatted approach – but it is more accessible. The functionality behind it is the same and I think is much better suited to the wide audience we will have. Please tell me if there are any issues your side with this approach or if additional help is required with the component itself.

Folder navigation

I think that it would be a mistake to let projects run riot with folder creation – particular if we want to migrate files over to the shared ResearchSpace environment. Therefore a limit to three levels of nesting seems sensible and provides consistency for the UI. At the BM we always try to avoid deeply nested folder structures and keep things as flat as possible. I think three levels if fine.