Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (January 2005)Back to main ZNG pageJoin or leave ZNGReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Tue, 11 Jan 2005 12:15:40 GMT
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Mike Taylor <[log in to unmask]>
Subject:      Re: context set for gis
Comments: To: [log in to unmask]
Comments: cc: [log in to unmask]
In-Reply-To:  <[log in to unmask]>
              (message from Dr Robert Sanderson on Tue, 11 Jan 2005 10:53:28
              +0000)

> Date: Tue, 11 Jan 2005 10:53:28 +0000 > From: Dr Robert Sanderson <[log in to unmask]> > > > I believe that Mike Taylor has concerns about mapping multiple > > index names to the same semantics, though apparently that is > > considered OK in the case of "author/creator" and is also OK if > > the index names are in different context sets. In GILS, we do have > > a few instances where multiple names are needed for the same > > abstract concept. > > For the record, I agree with Mike's concerns. It would be better if > you just picked one name for each index, as then there's no decision > to be made by people using the context set as to which name(s) to > support. Nor requiring clients to try and support all of the > different names. 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. This is why, for example, the Bath Profile for SRW at http://zing.z3950.org/srw/bath/2.0/ does not define a "title" element in its "bath" context set, but instead describes how "dc.title" should be used. (Note that a specific server interpretation may, due to inadequacies of its data model, end up interpreting multiple indexes in the same way; but that is not the same thing as the indexes being _defined_ identically. To take a topical example, a server might well implement cql.serverChoice and cql.anywhere using the same internal index, but that doesn't change the fact that in principle they are defined differently.) Finally, the case of author/creator is regrettable, but I don't think there is any point in trying to hold back the tide on that one. The whole world uses these index names interchangably, and we must either acquiesce or spend our lives fielding "bug reports" from uses who want to know why our servers don't support author-searching. _/|_ _______________________________________________________________ /o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk )_v__/\ "If Microsoft Word had been around 400 years ago, Martin Luther would never have got around to nailing his thesis to the church door. He'd have spent the evening messing around with the font size and found out the next day that the Reformation had broken out without him" -- Andrew Rilstone. -- Listen to free demos of soundtrack music for film, TV and radio http://www.pipedreaming.org.uk/soundtrack/


Back to: Top of message | Previous page | Main ZNG page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager