container

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

I am revisiting the container issue, which was recently cited by Nick as needing some clarification and probably rewriting.

I see now that there are two use cases different enough that perhaps we need separate functions.

Consider first the example:

        

!                    name=jones prox/container=author date=1950
Find the name 'jones' and date '1950' in the same author field.

As Nick pointed out, it is incorrect to think of the container as an index, rather it is more like an abstract structure that "contains" indexes. So if a server declares the container 'author' to contain 'name; and 'date'  then it will support a query looking for "name=jones and date=1950 within the same author field".  You need this container function because otherwise you get hits where name-jones and date=1950 but not necessarily for the same author. 

However, consider this example:   (both of these are curently in the CQL draft)

!                    jack PROX/container=author jones
Find 'jack' and 'jones' within the same author field.

I think that this is significantly different from the first.  It simply says find 'jack' and 'jones' in the same author field.   You need some sort of "container" function to do this, otherwise you get hits where jack and jones are found but  not necessarily in the same field.  

 

So I'm leaning toward separate function.  Use 'container' for the first case, and define a new function (prox modifier)  'sameField' for the second.  Or do you think we can define a single container function general enough to cover both cases without overloading it?

 

Thoughts, please.

 

--Ray