Re: DASL / GILS alignment

William Fisher said this:
> > William Fisher said this:
> > > 	Others mentioned the Z39.50 protocol and the huge library base
> > > 	which utilizes that protocol.
> > > 
> > > <snip>
> > > 
> > > 	So my question is: Are you willing to consider extending this
> > > 	protocol to cover legacy full-text searching?
> > 
> > Z39.50 has spent the majority of this decade getting "legacy full-text 
> > searching" right. IMHO, DASL's scope is doable as its stands. Adding
> > the scope that Z39.50 and "legacy full-text searching" have would make it
> > impossible to complete in any of the time frames of the implementors.
> > 
> > Please, if we need full text searching algorithms lets use what we have.
> > If Z39.50 is deficient in some way lets fix that. Not burden DASL, DAV
> > and, by extension, HTTP with all of the headaches that Z39.50 has already
> > sovled...
> > 
> > Now, with that said, a profile of DASL for dealing with a Z39.50 database
> > in a degenerative but standardized way might be something worth doing...
> > 
> > Sorry to be blunt, but I've seen Z39.50 in action. It solves all of the
> > right problems. The end result is that its a very hard protocol to 
> > implement in its entirety. But it solves the problems. You pick hard
> > problems you have to live with hard solutions.
> > 
> 	I don't have any energy on Z39.50 OR interest in working with Z39.50
> 	to try and beat DIALOG command searching into that model.
> 
> 	I do have an interest in searching using DIALOG and Lexus-Nexus full
> 	text search engines. It was very clear that your protocol is
> 	pretty short when looking at it to support either of these full-text
> 	search engines. They are a pretty limited subset but rather
> 	valuable when you consider the market share the Lexus-Nexus has
> 	in the legal market. Currently using simple http requires these
> 	two major on-line vendors to do weird web hacks to crowbar there
> 	old scheme's onto the WEB and it hasn't been done well.

Since queries are typed and/or in XML (never could find an answer to that 
one) supporting DIALOG/Lexus-Nexus queries should be simple. Their
query languages aren't that complex. I'm not suggesting that building
a DASL frontend for those is wrong. What I am suggesting is that
forcing DASL to support all of the IR problems of legacy full text
searching is wrong...

> 	You sure don't need all of Z39.50's baggage to support this market.

One of Z39.50's pluses is that you don't need to implement the entire
thing. You pick and choose which parts you need...

> 	If you are really going to restrict the requirements, my reading
> 	of them didn't see anything that says revision '04' was the answer.
> 
> 	Where is the multi-lingual requirement satisfied that was discussed
> 	in great detail in Orlando?
 
> 	I gather that you weren't in Orlando since lots of the time was spent
> 	on the scope of the requirements and possible ramifications of various
> 	items.

I was there. The scope that was discussed was something that was doable.
It won't be easy, but its doable. What I'm concerned about is that
we not start trying to re-specify Z39.50 in the HTTP stream. What DASL
has done is dead on target. And what you want to do with Dialog/Lexus-Nexus
is probably doable once they map their query language into XML. But
I think making DASL do more than that is a bad road to start down.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Thursday, 28 January 1999 10:02:15 UTC