simple search api (was Re: mimetype standardisation by testsets)

[Jean-Francois Dockes]

Mikkel Kamstrup Erlandsen writes:
 > 2006/12/24, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr>:
 > 
 > > Oops, yes, you're right the URI can change too.
 > 
 > Whether an uri can "change" or not is merely a matter of definition. If
 > an object changes uri it might as well be regarded as another object all
 > together. The end user will see it as a rename/move but in the api I
 > think we should go for the delete-create metafor. Meaning that the is a
 > one-to-one correspondence between objects and uris.

If the document pointed to by a URI is now replaced by a new one, and the
old one has a new URI, I think that any user would see this as the URI
having changed because what they care about is document contents, not URIs,
which are just an implementation detail.

 > > Lacking stable item identifiers, the only solution I can see is to
 > > have the initial query create and return a unique query identifier.
 > 
 > I'm not sure I understand what you mean here...

What I meant is the following: because the result list for a given query
can change in time and because URIs can change (in the above sense), if we
want to give the backend a chance to isolate a given query from
inconsistencies caused by an index update, we should not force the use of
the query text as a query identifier or the URI as a document identifier.

The proper way instead is probably to let the backend generate a
unique query identifier (which identifies a specific instance of the
execution of a given query text), and also let it use document
identifiers which are relative to this unique query identifier.

By doing so, we let the backend do its best to prevent inconsistencies
such as, for example, a displayed snippet not matching the document
title displayed in the initial hit list. 

This still probably wouldn't prevent a given backend to use the query
text as an identifier, or URIs as document identifiers, but forcing
their use in all cases might make it more difficult for some backends
to do their job properly.

J.F. Dockes