Skip to end of metadata
Go to start of metadata

ResearchSpace Search


Author: Dominic Oldman


Date: 2 March 2012


Draft: 0.1


Introduction & Main Concept


The ResearchSpace Search system is initially discussed in the Business requirements and Specification v2 document at pages 43 and 88. Page 43 provides the main functional requirements. These sections should be re-read as a starting point for the specification.


1.     Main Search


The main concept is the ability the perform searches with the appropriate level of recall and precision. As such the Ontotext offer seeks to implement the semantic search concept developed by FORTH in which CRM concepts and relationships are aggregated into a core set of concepts and relationships. A draft confidential paper which provides examples  of how thease aggregation works has been set to Ontotext and should be reviewed.


2.     Other search functions for refining


The requirement talk about additional search devices to aid the main searching feature. This included the use of free text searching, additional taxonomy and ontology searching and facets.


3.     Exploring


The idea that once a result sets was available a the level required that these could be used as a basis for exploring the data using the results as an anchor for finding other connected objects through different relationships.


User Interface


Functionality will be complemented with a user interface designed by the project designers which should be implemented and should be consistent with other designed interfaces. 

1                   Adherence to Client Business Requirements

( )

Please refer to ResearchSpace Business Requirements & Specification, Date: May 2010, Version: 2. These elements are part of client acceptance testing.


Relevant Business rules 


Please to refer to all business rules on page 14 on the specification. The most relevant in this case are;



Business Rule 1: Original Research - Data and assets generated by research are private to the project and restricted to project members until published to the shared ResearchSpace repositories. Projects would be expected to publish this data to the shared repository at some stage (as soon as practicable and reasonable) and data would be shared on the repository at the end (decommissioning) of the project.


Business Rule 3: Open System Standards - the ResearchSpace tools should not be dependent on

proprietary APIs. It should be possible to take any tool developed for use with open standard RDF

data and incorporate that tool into ResearchSpace without substantial redevelopment. Similarly, tools developed specifically for ResearchSpace should be useable with little or no modification outside the ResearchSpace environment. This business rule ensures the open nature of ResearchSpace and keeps the RDF research tool model simple and accessible.


Business Rule 7: Open Source – New software created will be released to the community freely as open source. Existing open source tools should, if possible, be utilised for ResearchSpace development.


Availability - Is tool available for public web site Research tools should also be offered as web site tools or plug-ins for general internet users of the site but in a form that can be locked down through configuration, if required, to restrict access (for example read rather than write access). (See para 11.2.5.)

Are high level requirements for Image Annotation fulfilled. (See para 12.6) Does system comply to general architecture principles ?


“As an open system, closed protocols, proprietary APIs and formats are to be avoided. Where not specifically stated in this document, the following rules should be applied. Any exceptions to the following must have a clear business case, such as that an existing component would require too much resource to comply. The ResearchSpace environment will primarily be accessed through the a web browser interface, however specialised research tools which are not web-based may additionally be adapted to access data from and contribute to ResearchSpace as required.


·        All data, components and services must be capable of being invoked over HTTP.

·        The primary mode of access is by URI resolution to a simple data URL (document) or Linked Data URI (semantic data).

·        Services are invoked wherever possible in a REST-compliant manner; if full REST compliance is not possible, then REST-like URIs must be used.

·        Complex queries in this REST-like style using standard SPARQL will be supported.

·        All metadata shall be represented in an accepted format of RDF, such as RDF/XML, Turtle or N3, in order of preference.

·        For data objects, such as documents and images, open formats such as html, jpeg and mp3 are preferred, although it is accepted that proprietary formats such as PDF and Microsoft Word may sometimes be necessary.

·        It may be permissible to invoke a service on the same directly, for example by using direct invocation via functions, but only if there exists an equivalent means via HTTP; the direct route being used solely for performance or similar reason.See para 13.2

Main Search


Search Sentence method


The main search should work in the way indicated by the BVA design. This allows the use of auto lookup for controlled terms, the use fundamental relationships and connecting elements ro allow a user to develop a “search sentence”.














The search system should result in a results page with summary information


·        The summary results should lead to a full results page


·        The full results page should have navigation for applying ResearchSpace tools, going back to search, dashboard etc. The diagram above should have a side panel for this purpose.


·        The summary results page should have a side panel which provides more information about the object when it is highlighted.


·        A highlighted summary result should be allowed to be used as the basis of a exploring other connected objects. This might be similar in principle to the old “results similar to this one” option. In the case it would be used as the basis for a “results which have a semantic connection to this one”.


·        The semantic connecting would use the same fundamental concepts but the user would have the option of extending the connection to a wider range of datasets from the ResearchSpace repository. External connection may also be included here.





Search with Fundamental Concepts and Relationships



Refine with Free text and Facets


Get Summary Results and show more details for the object in focus (clicked by the user)



Allow new search, back to dashboard and navigation to tools etc, that would be relevant for working on the object. Allow search criteria to be saved. Allow user to go to the detailed result screen.


Additionally provide an option to explore the selected object



Explore Option



Either from the object in focus on the summary results screen or the details screen allow the user to use the selected result as an anchor for an explore and browse.


Include the same navigation options as above



Detailed  results screen



Same navigation links as above


Explore Screen



Allow the user explore other data with a wider set of datasets that may have been chosen for the original search to make connections using the Fundamental Concepts as the facets and

Generating those connection displaying the relationships in terms of the Fundamental relationships.   



Use Case Example


The user searches for an object of a particular type and period. They use the sentence construction system to construct the necessary search. They have selected some particular datasets from the ResearchSpace public repository to compliment the projects data store (which may be private or public). The search includes the optional free text search for searching literals in the potential results.


The results set is large and the user attempts to refine this will by additional parameters or search strings. Once the user is happy they save their search and select a object from the results for data annotation. They perform some data annotation and then go back to their saved search and bring the results back to the screen.


They select one record and read some additional data about it. They decide that it would be useful to use the object record and explore any connected objects. 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. 


The system should show some additional details for an object that the user selects or highlights.


Again, when the user is happy they can select a record for use with the tools available, start over or go back to their dashboard.










Stage 3 status




The  search sentence should allow the inclusion of “and”  “or” and “Not” Boolean operators






The  search sentence should support searching of fundamental concepts, Things, People, events, Places, Events and Time  and support the use of fundamental relationships as set out in the paper, “ A New Framework for Querying Semantic Networks, Katerina Tzompanaki, Martin Doerr






It should be possible to combine the search with a free text search of the literals within the database or simple perform a Google style free text search.







It should be possible to refine searches with appropriate concept facets.








Results should be set out in an efficient light box arrangement with the ability to configure the summary metadata available.






Search should allow the user to select specific datasets (through inclusion or exclusion e.g. select all and exclude some or select none and add a few). The user settings should remain between sessions until reset.







The search system should be relevant for different object types – not just art. The BM dataset should be the basis for this.






Search will be saved in order to supply results to other tools or allow researchers to come back to their results set in another session.






The search screens (including results) should have a consistent navigation system between dashboard, research tools, search etc.






The Explore system should allow users to use a particular result from a search as the anchor for exploring connected objects and records in the ResearchSpace data repository. The scope could be wider  than the original search.







The Explore function should allow users to increase or decrease the concepts and relationships that are used.






Summary results should allow the user to highlight a particular summary result to see some additional information before proceeding – perhaps to the full results screen. Options for taking the record into a Research Tool interface should also be available at any point that the user is able to select a distinct record.





Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.