 |
 |
The GILS Profile includes a GILS schema with a bunch of named data elements (see http://www.gils.net/xml-en.xsd ). Most GILS implementations allow searchers to search on any GILS schema element, and I'd like to preserve that potential in an SRW/CQL environment as well. It is an easy matter to make CQL index names from GILS schema elements by just converting the name to camel case (getting back to to their ASN.1 names, BTW). Trouble is, I already have elements in GILS with names like "Record-Source". So, should the GILS Profile for CQL allow a search on "gils.recordSource" or should it insist that the CQL query can only use "rec.creationAgentName"? Along the same lines, if one implements a Microsoft Office search with CQL one will need to support the friendly MSO property names such as DocTitle, DocSubject, DocAuthor, DocEditTime, DocLastPrinted, DocPageCount, DocWordCount (e.g., http://msdn.microsoft.com/library/default.asp?url=/library/en-us/indexsrv/html/ixuwebqy_4drn.asp ). We are NOT going to be successful with SRW if we insist that everyone learn to use a mixed bag of index names: dc.title, dc.subject, dc.author, mso.DocEditTime, mso.DocLastPrinted, mso.DocPageCount, mso.DocWordCount (and, I guess these last four would need to migrate down to the Record context set?) I don't quite see a full solution to all of this, but I am wondering if it is really that important to have each name prescribed in a separate context set. Maybe CQL context sets should be the place where indexes live IF AND ONLY IF they have an "unusual" definition. Any index whose name conforms to the naming rules and is composed solely of registered base concepts gets a free ride (no context set prefix needed). Would that work? Eliot