next up previous
Next: 4 Testing the agent Up: 3 Config file Previous: 3.2 Provider

3.3 Map

The map translates the information accessed by the provider into metainformation, and the query into a format understable by the information support. It usually does not have metainformation associated to it, so, the only way to extract this metainformation is directly from the information, mapping information fields into metainformation. In the same way, to translate a general query into the particular format a metainformation field is mapped to any local field. It is better undestood with an example.

The metainformation model is Dublin Core, whose propourse is to describe resources like books, images or in general anything which identity; its terms set is suitable to describe a wide range of concepts, regardless of its nature or format. The most important Dublin Core terms are title, creator, subject, description and identifier. A complete description of the terms is available in [*].

At the moment only one map mechanism is available, the filter map. It uses the same philosophy that the printf C function, it takes a string and substitutes some special strings into others. Lets see it with an example of a SQL provider.

SELECT author, title, booksAvatible, comment FROM fooTable WHERE (author = ``%query%'') 

it is a typical SQL query that serves as a template, the provider takes this string and subtitutes %query% with the submited query. For example, if it receives a query with valour ``homer'', it will query the data base with the string

SELECT author, title, booksAvatible, comment FROM fooTable WHERE (author=''Homer'') 

Each term may have a string defining how to construct it, there will be a string for creator, another for title, etc.

To generate the response, the idea is the same. For example, in our example the data base table has fields author, title, booksAvatible and comment. The two first fields fits directly with Dublin Core terms, they are the same concept, so the filter string may be quite simple, for creator

%author% 

and for title

%title% 

if the data base returns the author Homer, and the title ``The Odyssey'', creator and title will be ``Homer'' and ``The Odyssey''. These are trivial examples, let's go with a more difficult case.

There is not a DC term to describe if a resource is available or not, but we can use the DC description to express it with the following filter:

%comment%. There are %booksAvatible% books in the Homer Simpson University Library. 

Let us suppose that the data base returns a comment field with valour ``Homer's epic story about the return of Odysseus to his home in Ithaca'' and a field bookAvatible with valour ``2'' . The user will have a DC description equal to ``The epic return of Odysseus to his home in Ithaca. There are 2 books in the Homer Simpson University Library'' for this resource.

It may be more clear with a concrete example. Let's come back to the example configuration.

<map name="Google map" type="filter"> 

This map is called Google map, it is the name that have to be used in the attribute map of the provider section. The type is filter, the only one available in this version of Searchy, in a future new map types may be added.

A map section contains several tags, two for each DC term, the attribute filter sets if it is a query map of a response map:

<author filter="query">SELECT author, title, booksAvatible, comment FROM fooTable WHERE (author = ``%query%'')</identifier> 

If the value of attribute filter is query, it is used to map queries. Query filters use the string %query% to identify the user's query, in our example it is Homer.

To get the response, Searchy maps all the response strings, searching something of the form %foo%, foo must be a field available in the data source. For the data base example, foo may be author, title, booksAvatible and comment.

<description filter="response">%comment%. There are %booksAvatible% books in the Homer Simpson University Library.</identifier> 


next up previous
Next: 4 Testing the agent Up: 3 Config file Previous: 3.2 Provider
2004-05-20