W3C home > Mailing lists > Public > www-zig@w3.org > February 2002

RE: Z39.50 on the web (and in print)

From: Stevens, Pat <stevens@oclc.org>
Date: Sat, 23 Feb 2002 18:48:18 -0500
Message-ID: <E5431CF93E29F9478878F623E5B9CE98029AF3A3@OA3-SERVER.oa.oclc.org>
To: "'Andy Powell'" <a.powell@ukoln.ac.uk>, Eliot Christian <echristi@usgs.gov>
Cc: www-zig@w3.org
Andy has put into very clear language what I was thinking as I read the
thread.  

We can help those within the Z39.50 community work more efficiently with
explain, but it won't take us outside the current implemetation community.
I am not so naive as to assume that 'advertisement' in broader based
collection description services will cause a stampede of Z39.50
implementations. It can help those who want to integrate Z39.50 into a
broader range of services do so more easily.  My experience with current
portal building is that portals must be able to handle a variety of
proprietary API's , Z39.50 and plain old Web. Having a single place to come
to discover a resource and determine how it is accessed, is what is
required.

pat

 

-----Original Message-----
From: Andy Powell [mailto:a.powell@ukoln.ac.uk]
Sent: Saturday, February 23, 2002 2:53 AM
To: Eliot Christian
Cc: www-zig@w3.org
Subject: Re: Z39.50 on the web (and in print)


On Fri, 22 Feb 2002, Eliot Christian wrote:

> Personally, I believe the UDDI initiative (and similar work in
> the ebXML community) is exactly what we need for a register of
> services, including but not limited to those whcih happen to
> use the z39.50 protocol.

Yes, I tend to agree with this.

Firstly, Z39.50 doesn't stand on it's own in the resource discovery arena.
If one looks at initiatives like the UK DNER architecture

  http://www.ukoln.ac.uk/distributed-systems/dner/arch/

(which I reported on briefly at the last ZIG meeting) Z39.50 is just one
of several protocols and standards that support the discovery of resources
within that particular framework.  The others are OAI and RSS currently,
but one might expect SRW (or something like it) and other stuff to be
added in the future.  Any 'service registry' approach that focusses on
only one protocol is problematic from this perspective.

Secondly, a limitation with Explain is that you have to know something
about a target in order that you can go and ask it it for more details.  
This is where F&N becomes useful I guess.  I know that the OAI tech group
has also discussed the possibilities of doing F&N within the OAI protocol
(i.e. having a way of asking an OAI repository for a list of all the other
repositories that it knows about).  Again, these approaches are of limited
value because they don't help you work across several protocols.

Thirdly, any 'service registry' needs to describe both the content of the
target 'collection' and the 'services' that make that collection
available.  The same collection may be made available by both Z39.50 and
OAI for example.  Our work on RSLP collection description (and in
particular Michael Heaney's underlying model) makes this distinction clear

  http://www.ukoln.ac.uk/metadata/rslp/

The DNER architecture talks about distinct 'collection description' and
'service description' services

http://www.ukoln.ac.uk/distributed-systems/dner/arch/collection-description/
http://www.ukoln.ac.uk/distributed-systems/dner/arch/service-description/

though I would expect these two things to be delivered via a single 'DNER
directory' (or 'DNER registry') shared service.

My understanding of UDDI is that the 'businessService' and
'bindingTemplate' entities provide the same distinction - though, clearly,
the terminology is very different.

For anyone who is really interested, an initial comparison of the DNER
architecture and the 'Web services' architecture is available at

  http://www.ukoln.ac.uk/distributed-systems/dner/arch/ws/notes/

Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell       +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
Received on Saturday, 23 February 2002 18:48:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:27 UTC