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

[Mikkel Kamstrup Erlandsen]

2007/1/6, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr>:
> 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.

To put matters short: You agree with Magnus' proposal 2 in the thread
"Simple ssearch API proposal, take 2"?

Cheers,
Mikkel