|
|||||||
Global navigation options: |
|||||||
The group developed the following action items.
1. Define functional requirements for Dublin Core searching.
However, before doing so:
1.1_ Articulate what are the inadequacies of Internet searching (and Web searching in particular) that need to be solved.
1.2_ Define the audience for these requirements: vendors, standards developers, users?
1.3_ And define just who the users are. Are we developing requirements for "power" users or just recreational/casual users, or both?
1.4_ Determine whether or not there should be a working group to develop search requirements. (Note: subsequently, at the Wednesday plenary session, "Search" was listed among the working groups to be formed. Presumably that group will address search requirements.)
1.5_ Answer the following preliminary questions:
1.5.1 Which DC elements are access points? All of them?
1.5.2 Does DC searching apply to unqualified DC, qualified DC, or both? This question corresponds closely to 1.3 above.
1.6 Develop user scenarios for searching/discovery/navigation/browsing. First, however, develop working definitions for these concepts (search, discovery, navigation, browsing) and their inter-relationships.
1.7 Define requirements for cross-domain searching. Do DC search requirements include cross-domain searching? Describe the differences between and similarities among DC searching and cross-domain searching.
2. After defining requirements, answer the following:
2.1 Is there a requirement for a DC search service definition?2.2 Does a DC search service definition assume an abstract layer? For example, are DC access points "abstract" access points (as in the Z39.50 model)? And if so, to what extent are we to be concerned about mappings of abstract to real access points?2.3 Is retrieval within the scope of a search definition? Or can a search definition be developed independent of retrieval considerations? Discussion:
In the Z39.50 model, search and retrieval are very clearly distinguished: In the search phase of a search/retrieval scenario, the client sends a query to the server and asks the server to (a) identify records that meet the criteria specified by the query, (b) create a (local) result set corresponding to the records, and (c) report the number of records. In the retrieval phase, the client requests the server to send one or more of the records that were identified in the search phase. However, even though there are distinct models for search and retrieval, the two models are closely related; for example, both rely on the concept of a result set.
Thus the question is: must a DC search definition consider matters such as element selection (for example, to retrieve metadata only, or even selected metadata) and record syntax? Or might a simple model suffice, where only record pointers are retrieved, and real retrieval is declared out-of-scope?
3. Develop a working a definition of Interoperability as it pertains to searching, and define meaningful levels of interoperability. The Search breakout group suggested the following: "syntactic", "semantic", and "content", as levels of interoperability. Develop guidelines for each defined level of interoperability.
4. Though the breakout group was not tasked with suggesting requirements, a few very basic requirements came up as a by-product of discussion and the group could not resist listing them. (Please note that the group did not spend time trying to brainstorm requirements so this is by no means an exhaustive list of basic requirements.)
[an error occurred while processing this directive]4.1 Some sort of "Explain" facility, allowing a client to determine what search capabilities are supported on a server.
4.2 Fielded Searching.
4.3 Boolean searching.
4.4 Ranking. (Note that in the discussion of ranking, de-duplication was discussed but there was no consensus on listing it.)