 |
 |
No time to reply properly, but I do just want to say that I see the justice of Eliot's cause. There are real reasons why you might want the same index to be known by different names. I still think that on balance it's better not to do this, but I do recognise that the matter is worthy of debate and not an open-and-shut case. > Envelope-to: [log in to unmask] > Delivery-date: Tue, 11 Jan 2005 15:21:59 +0100 > X-MIMETrack: Itemize by SMTP Server on gsvaresh02/SERVER/USGS/DOI(Release > 6.5.2|June 01, 2004) at 01/11/2005 09:10:21 AM, > Serialize by Router on gsvaresh02/SERVER/USGS/DOI(Release > 6.5.2|June 01, 2004) at 01/11/2005 09:10:27 AM, > Serialize complete at 01/11/2005 09:10:27 AM > Content-Type: text/plain; charset="us-ascii"; format=flowed > Date: Tue, 11 Jan 2005 09:07:14 -0500 > Reply-To: "Z39.50 Next-Generation Initiative" <[log in to unmask]> > Sender: "Z39.50 Next-Generation Initiative" <[log in to unmask]> > From: Eliot Christian <[log in to unmask]> > Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]> > X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on bagel.indexdata.dk > X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham > version=3.0.0 > X-Spam-Level: > > At 07:15 AM 1/11/2005, Mike Taylor wrote: > >[...] > >Also for the record (thank, Rob!) Eliot is incorrect in supposing that > >I think it's OK for CQL indexes in different context sets to have > >different names. Far from it: as a matter of Good CQL Citizenship, > >anyone defining a new context set should take pains to ensure that > >they do not duplicate the semantics of an index already defined > >elsewhere. [...] > > Sorry, I guess I misunderstood Mike's position in a prior > exchange. I will try to present the "multiple index names > with same semantics" issue as I see it. > > I think it is reasonable to have CQL accommodate current > practice in the naming of indexes for existing communities > of practice. This has already been done to some extent > with bibliographic terminology in anticipation that CQL > will be used by the library community. But, the library > community is only one among a great number of communities > that ought to use CQL. > > If CQL is to also be used for the searching of news stories, > we can anticipate that there will be a "news context set" > wherein the index named "byline" would have the same semantics > as "author" and the index named "headline" would have the same > semantics as "title". If CQL had a rule that prohibited more > than one index name for the same semantics, the result would > surely be that the news context set author/creator would insert > some trivial difference in the semantics so that the community > can write CQL using the index names that are natural for them. > Then, CQL would have encouraged an artificial barrier to search > interoperability: two indexes that ought to have been the same > for almost all search purposes have been made to seem different. > > Obviously, any search server supporting CQL must provide some > kind of semantic mapping function to relate named indexes to > particular pieces of content. It is expected that such a > function will often map multiple index names to the same > content. Since only the human who sets up that mapping is > responsible for how "good" is the semantic match, I don't > see why we would want to have CQL playing "semantics cop". > > Eliot >