Print

Print


> Given a choice here the extension "x-databases=abc,def,ghi" seems the more
> natural.

Yep.

A third option, which we already have as it turns out, would be to have it
as an index:

   dc.title = froissart and rec.collectionIdentifier any "a b c d"


> It does take the SRU/W model away from its original meaning, but it seems to
> me that this is an important enough area of our business (a little bit of
> bias showing here, perhaps?) that we should attempt to create something to
> bring the MSEs into the same fold.

Another aspect that would be needed is a recordSource element for
extraRecordData... which leads me to the answer for below ...


> This leads to the fact that sections 26-29 of the Spec (to do with
> extensions) mention "profiles" and 'profile designers" quite a few times
> with no definition of what a profile is in this context. Is it (part of)
> a context set? (but they are for CQL?) If not what is it? Confusion is
> reigning (or raining) at the moment.

A profile is a set of requirements that the protocol doesn't make.  For
example, I have a CCG profile that specifies which indexes from Dublin
Core are to be used, which from my own CCG set, etc, along with the
record schemas that have to be supported and so forth.
I don't have any extensions as part of the profile, but they would form a
core part of the MSE profile.

So a very brief MSE profile might be:

Indexes:  dc.title, dc.type, rec.collectionIdentifier
Schemas: dc, mods
Extensions:  serverVersion, dedupe, recordSource


Rob

       ,'/:.          Dr Robert Sanderson ([log in to unmask])
     ,'-/::::.        http://www.csc.liv.ac.uk/~azaroth/
   ,'--/::(@)::.      Dept. of Computer Science, Room 805
,'---/::::::::::.    University of Liverpool
____/:::::::::::::.
I L L U M I N A T I  Cheshire3 IR System:  http://www.cheshire3.org/