Re: GILS Report available


Subject: Re: GILS Report available
Sebastian Hammer (quinn@indexdata.dk)
Date: Sun, 09 Aug 1998 10:10:33 +0200


Message-Id: <199808090816.KAA10290@bagel.indexdata.dk>
Date: Sun, 09 Aug 1998 10:10:33 +0200
To: gils@cni.org
From: Sebastian Hammer <quinn@indexdata.dk>
Subject: Re: GILS Report available
In-Reply-To: <199808071958.OAA15272@rgate2.ricochet.net>
References: <v04003a02b1effc3bd12d@[204.210.227.47]> <Chameleon.902352942.patrice@patrice.rtknet.org>

On 07-08-98, Carl Hage <carl@chage.com> wrote:
>
> On Fri, 7 Aug 1998, David Landsbergen <landsbergen.1@osu.edu> wrote:
> >
> > I read the report but I'd still like to talk about the best way to
> > get GILS implemented. I believe that we can talk all we want about
> > statutory authority but the tools must be available to these agencies
> > to allow them to implement.
>
> I agree with that -- if good tools existed (and addressed various needs)
> then people would use GILS. We often see messages posted here saying
> something like, "OK I read the spec and created a GILS record -- now
> what do I do with it?"

I think the major challenge here is that the "tools" needed to manage
and manipulate GILS records depend heavily on the information managament
systems already in place at the institution. Of course, it is possible
to maintain the GILS records in a completely separate information
management framework - divorced from the goings and comings of the
organisation. However, that approach frequently leads to a database
which is out-of-date, and/or treated as an inferior source of
information.

In most cases, we find that the support of GILS in an organisation
does not necessarily require people to sit down and laboriously type
in records. Rather, we find that the requisite information IS ALREADY
THERE, in running information systems which support the daily operation
of the unit. The challenge is to put an appropriate system in place
to export the data, or otherwise make it available to a GILS server
function. The role of GILS, then, is to create a window to a subset of
the existing information, which can be accessed without worrying about
what type of information system(s) are in place.

Exactly because each body handles information internally in its own way,
it would be highly problematic for a central organization to mandate or
prescribe tools or procedures to this end. However, the definition of
easily processed exchange formats such as Eliot's XML specification are
a great help. While most webmasters or system consultants would need to
spend a lot of time constructing a new Z39.50/GILS target, they will all
feel comfortable generating XML-records.

Rather than producing software tools and/or strict guidelines, I would
recommend that a more introductory text is produced, to supplement the
standard, and focusing on local management issues. I would emphasise
the fact that the key is to setup a system that gets the job done
reliably with the least possible effort or hassle to the organization,
and give examples of ways that this can be accomplished. The 10-line
Perl scripts you mention will spring from that, and what's more, the
requirements for generalized software will become more apparent. Let
this list be a forum for the exchange of ideas and solutions for how to
make GILS work smoothly in the organization.

> Tools besides search and retrieval are needed. GILS would be useful
> for cataloging WWW sites, and tools processing GILS records could be
> used to create a WWW Table of Contents or to produce WWW catalogs/
> directories of documents. GILS could be tightly integrated with WWW
> site implementation, but tools need to address this vs simplistic
> word search.

I can heartily support this statement. In the Scandinavian countries,
we have extensive experience using GILS to manage WWW indices. The
experiences are completely positive, in no small part thanks to the
effort made by this group to track the development of the Dublin Core
data elements. An automated webcrawler scanning a website containing
documents with embedded metadata (Dublin Core or otherwise) can produce
a very nice GILS database with practically zero effort. Such a database
can meet both the organization's requirement to supply a "search"
function to internet/intranet users, and it can provide external access
to the catalogue via GILS - all through the same search engine.

> The biggest problem with GILS is the lack of efforts and tools dealing
> with controlled vocabularies (standardized sets of index terms). There
> are few mechanisms to create, maintain, exchange, and access CVs.

I agree that in GILS-related projects, the CV-part is often forgotten
in the effort to get the basic system operational. Now, GILS is used
in many different settings (outside of the US government as well), and
LCSH is by no means appropriate for all. But any guideline to GILS
implementors would do well to emphasise the need for topic-specific
controlled-keyword lists. You wouldn't need to tell this to a
librarian, of course.

--Sebastian

Sebastian Hammer
<quinn@indexdata.dk>



This archive was generated by hypermail 2a16 : Tue Mar 23 1999 - 03:55:43 EST