Subject: Re: GILS Report available
Pedro Urra (urra@infomed.sld.cu)
Date: Thu, 13 Aug 1998 21:12:35 -0400
Message-Id: <01BDC6FF.9F437400@laptop.rtn.net.mx> From: Pedro Urra <urra@infomed.sld.cu> To: "'gils@cni.org'" <gils@cni.org> Subject: Re: GILS Report available Date: Thu, 13 Aug 1998 21:12:35 -0400
On Sun, August 09, 1998, Sebastian Hammer <quinn@indexdata.dk> wrote:
>
> 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.
I agree with Sebastian!!
GILS is a good idea, is pragmatic and is simple. Of course that some
tools are needed and that availability could be essential.
We are working in a project to implement a network of GILS compatible
locators for health information in Latin America and the Caribeean and
it works.
In our experience it is essential to integrate very well the web
enviroment and any effort to build the locators.
At the same time it is very usefull to have tools to use
metainformation from different sources and in differents formats.
Doublin Core, USMARC, etc.
People react in a very simplistic way when you talk about Z39.50 and
catalogs. That is a first reaction. There is not enough information
about the GILs efforts and in sources like Computer Select what you find
is not very helpfull.
Australia, Scandinavian countries and Canada are more clear about the
succes of the project.
Until today Z39.50 implementations are expensive and not very common.
Anyway there is a chance to have something working good with relativelly
very resources because it is a matter of knowledge and understanding
specially by the people more closelly related with the information
system implementation.
More interaction between information systems specialists and librarians
will help in this sense together with more simple tools to do the work,
Pedro Urra
Infomed Cuba
<urra@infomed.sld.cu>
This archive was generated by hypermail 2a16 : Tue Mar 23 1999 - 03:55:43 EST