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

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

From: Eliot Christian <echristi@usgs.gov>
Date: Fri, 22 Feb 2002 11:07:08 -0500
Message-Id: <5.1.0.14.0.20020222103917.014b8b70@gsvaresm03.er.usgs.gov>
To: www-zig@w3.org
At 03:55 PM 2/22/2002 +0100, Sebastian Hammer wrote:
 >[...] What I'd like to consider is whether it would be feasible
 >to build a structure in which these lists could be merged or
 >cross-searched... one of the key elements, surely, would be a
 >good schema for describing targets, second would be some
 >mechanism for organising a virtual union catalogue (Z39.50,
 >LDAP, OAI are readily available technologies that come to mind).

Such a list of 234 Geospatial Clearinghouse Nodes is maintained
at http://clearinghouse4.fgdc.gov/registry/browse.asp?order=title
These records are searchable via the GILS Profile as well as the
Geospatial Profile.

This list can also be regarded as a register of "businesses" that
offer "services" over the Web, including but not limited to Z39.50.
Viewed in this way, the service metadata is easily modeled in UDDI
(Universal Description Discovery and Integration). To show how
this works, here's a quick walk-through of the UDDI registrations
for geospatial data search services as exposed through distributed
UDDI public (and/or private) registries. (The UDDI community home
is <http://www.uddi.org/>

Go to <http://test.uddi.microsoft.com> and select "Advanced Search".
You'll see a pull-down list for ways to constrain your search.
Here, choose "tModel by Name" and enter "geo" as the search string.
(BTW, a search on "z39.50" also gives interesting results :-)

Next, you should see several tModels having names that contain
the string "geo". We are interested in the one that looks like
this: GEO (Geospatial Metadata) Profile (details) If you were
to follow the "details" hyperlink, you would find a description of
the Geospatial Metadata Profile and a "discovery URL" pointing to
the actual Geo Profile document. (One could, of course, do the
same with "Bath", "Bio", ...)

Follow the GEO (Geospatial Metadata) Profile hyperlink. This
launches a search for all UDDI records that have been described
as supporting the Geospatial Metadata Profile service. You will
see that there are 234 "business services" supporting the Geospatial
Metadata Profile. Each of these correspond to one of the servers
in the Clearinghouse noted above.

Follow the Alamo Area Council of Governments (AACOG) hyperlink
and see  business and contact details, as well as "classifications".
These classifications can take values from any taxonomy one might
want (subject, place, type of library, ...). The classifications
and identifiers are the main mechanism by which users discover
the businesses and services of interest.

In the selected example case, a geospatial "business" offers five
"services":

    Web home page
    FGDC Entry Point to Geospatial Data Clearinghouse
    Z39.50 search contents of named database
    GILS search contents of named database
    GEO search contents of named database

These are all automated services on the Internet. The first two
of these are just HTTP Web pages but the last three are all Z39.50
services (unprofiled Z39.50 followed by GILS and Geo Profiles.)
This ability to drill down all the way to an automated service is
the most innovative part of UDDI. This is where UDDI meets another
specification known as Web Service Definition Language (WSD).

It is a very useful design feature of UDDI that the business and
service metadata chosen by the UDDI community is very similar to
what is available via GILS (see <http://www.gils.net/uddi.html> ).
This makes it straightforward to construct a two-way GILS/UDDI
Gateway. Recntly, the .Net organization within Microsoft began
developing just such a gateway, building on a prototype developed
by Matthew Dovey.

Another interesting wrinkle in the UDDI work concerns the ability
to define relationships among businesses. I've published a test
view of the top 2000 organizations of the U.S. Federal Government
with defined parent-child relationships reflecting their hierarchy.
(This data comes from professional catalogers at the University
of Illinois-Chicago. Again, this hierarchical classification is
easily supplemented with other kinds of classifications so that
users have many ways to find the right organization.)

To see this in action, go to <http://uddi.rte.microsoft.com/> and
choose "search". Select the "Find Provider" tab and enter
"U.S. Government".When you click on the "search" button, you'll
get results in the left-hand bar. One of those is a hyperlink
titled "U.S. Government", described as "National node of an
hierarchical taxonomy of government". If you select that hyperlink,
the right-hand frame will show the several pieces of that entry
(Details, Identifiers, Categories, Discovery URLs, Relationships).
If you follow "Relationships", you'll see that "U.S. Government"
is the parent of a child entry named "Federal U.S. Government".

In this interface, it's pretty tedious to follow the relationship
trail. But, if you do you'll find that "Federal U.S. Government"
has these six children:

  Boards, Commissions, and Committees
  Executive Branch of Federal U.S. Government
  Independent Establishments and Government Corporations
  Judicial Branch of Federal U.S. Government
  Legislative Branch of Federal U.S. Government
  Quasi-Official Agencies

...and, of course, the chains go quite a bit deeper (ten levels
in these top 2000 records).

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.

Eliot
Received on Friday, 22 February 2002 11:09:28 UTC

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