-----BEGIN PGP SIGNED MESSAGE-----
Mr C A Rusbridge writes:
| Matthew Dovey wrote:
| > The use of RDF and XML based standards in the catalogue level
| > descriptions may make this gap smaller.
|
| I've seen a number of statements like this one and I must confess I'm
| puzzled. Z39.50 and LDAP are essentially communication protocols. RDF/XML,
| MARC, X.509 etc are basically document standards. While I can see
| advantages in moving towards RDF and XML, I can't see they make any
| difference to the gaps between Z39.50 and LDAP (or even whois++).
OK, acronym soup and techie jargon alert!
My impression is that the most significant difference between Z39.50
and the various directory service protocols is in the way that results
are squirted back. Directory protocols typically return result
objects in a fixed format, usually consisting of attribute/value
pairs. Z39.50 is built around the notion that you can ship around any
sort of objects so long as they're properly tagged.
This does raise the question of whether you actually want to ship any
old object over the network. Jon's (in)famous .signature (ableit
somewhat cryptic due to being tweaked to fit in the smallest possible
space!) amply illustrates the benefits of requiring a single well
defined result format:
#!/usr/bin/perl -- -Whois++-client-in-6-lines-of-Perl -Beat-that-Z39.50!
use IO::Socket;sub w{$f=shift;$a{$f}=1;($h,$p,$q)=split("/",$f);$s=
IO::Socket::INET->new(PeerAddr=>"$h:$p")||return;print $s "$q\r\n";while(<$s>)
{next if(/^%/);if(/^# SERVER-TO-ASK/){while(<$s>){$x=$1 if/Name: (.*)\r\n$/;$y
=$1 if/Port: (.*)\r\n$/;$f="$x/$y/$q";@j=(@j,$f)if(/^# END/&&!$a{$f})}}else{
print}}close($s)}@j=shift;while(@j){w(pop(@j))}# whois++.pl host/port/query
There you go - a working distributed indexing and searching system.
User interface needs a bit of attention, mind you :-)
I suppose the analogy in Z39.50 terms would be to always offer (say)
the USMARC format in your result sets, if your database is going to
be accessible to random Internet people.
There's also no (built-in) equivalent in Z39.50 to the "referral"
concept in LDAP, RWhois and WHOIS++. This makes it harder to do
distributed indexing and searching, since if you want to keep
everything Z39.50, you'll probably end up having to search multiple
servers in series or parallel rather than searching an index server
which refers you back to those services that appeared to have matches
for the query. If people were to agree on a convention for doing
referrals, Z39.50 would become a lot more useful for this sort of
thing.
The IETF's Common Indexing Protocol (not to be confused with the
Z39.50 Catalogue Interoperability Protocol) can be implemented
independently of the search and retrieval protocols being used to make
available the data you're indexing, so you could export centroids from
your Z39.50 server without having to hack Z39.50 itself. If you
didn't mind that the core index server searching activity wasn't using
Z39.50, you *could* use CIP to quickly do the first level searching of
an index server, and then follow through his to individual services
(thinking hybrid libraries, clumps, ...) with Z39.50 later if desired.
The rub with CIP is that it's really at same stage as RDF at the
moment - there's enough in the way of specifications for a few basic
implementations (such as the one we did for ROADS), but a lot of the
things you might want to do haven't been specified yet - or else it's
not clear what the specification should say. If you wanted to use
this approach with more stable code/specs it would probably be better
to use the Bunyip, CNIDR or ROADS WHOIS++ servers, each of which can
also act as an index server. Each of these supports the original
WHOIS++ specification for distributed indexing and searching - RFC
1913, but only ROADS supports the Common Indexing Protocol so far.
So there :-)
Ciao!
Martin
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBNcIeT9ZdpXZXTSjhAQE/ewP/YQ31yIoylGmgKRqvCZchpzNkYirAYj0h
QcDCebLKRf2QoMf0aMHxSzXiQ4BCAypPFWEz5xzi+0VvEY448ywv5XQ6J+/evte3
wxl7wJCrbii9RHNm3OtobqeAEdhiethbQ7iz+fM2kwjm/uCiAjdfpsZ91IpXI6MG
zwInufn2OHA=
=aMSv
-----END PGP SIGNATURE-----
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|