W3C home > Mailing lists > Public > www-zig@w3.org > September 2001

RE: Sebastian's Euro 2 cents worth of ZNG dicussion:

From: Sebastian Hammer <quinn@indexdata.dk>
Date: Thu, 27 Sep 2001 18:03:25 +0200
Message-Id: <>
To: www-zig@w3.org
Hi Barbara,

At 11:29 27-09-2001 -0400, you wrote:

>.... What libraries desperately *do* need is ... someone to take the lead in
>proposing a
>standard mechanism for handling loan requests that can be used together with
>Z39.50. ...
> >From my viewpoint, that is what the ILL Protocol Implementors Group (IPIG)
>has been doing for the past 5 years - and there are several library
>applications now available that have successfully melded the implementation
>of the IPIG profile for handling the loan of material along with Z39.50
>functionality for resource discovery.  IPIG has always been open to Danish
>and other European participation in this work.

I don't dispute it, but my sense is still that in the Z39.50 community, we 
could use a consensus on a "best practice" for this. My sense is that the 
two communities need to work more closely together. It's one thing to 
develop "several applications". What is required from a national profiling 
perspective is a believable, documented approach that we can push upon 
*all* of the veondors working in our area.

But please don't read into my message a criticism of the work of the IPIG. 
I am trying to get a point across to the ZIG that I consider urgent, and 
ILL *IS* one of the most crucial applications of Z39.50. You could say that 
Z39.50 needs ILL more than ILL needs Z39.50. You can do ILL without 
real-time search/retrieval if you're willing to accept certain compromises, 
but if you implement Z39.50 in libraries, sooner or later people will want 
to borrow the books.   :-)  I think Z39.50 people probably need to be more 
proactive about choosing a "best practice" for dealing with ILL -- most 
likely by leaning on the IPIG. But my point today was a broader one -- that 
there are more important issues than ZNG for the ZIG to be concerning 
itself with.

>Sebastian, I agree that profiling work is essential to take the ambiguity
>out of using bibliographic attribute sets.  But I'd like some thought given
>to the use of the newly defined  bibliographic attribute sets (Bib-2 and
>MARC)  and searching power offered through their integration with the
>Utiliity and Cross-Domain attribute sets defined within the new "Attribute
>Architecture - rather than sticking with Bib-1.   One of the most
>interesting aspects of the Bib-2 set is that, for the most part, Bib-2
>simply uses Cross-Domain access point attributes modified by specific
>library-related content authorities and fucntional and semantic qualifiers.

Absolutely. I think the trouble facing all bibliographic profile developers 
is the same we've been dealing with in Denmark... at what point do we 
decide to adobt Bib-2, and how do we go about it? The problem here is that 
at the level of complexity we're dealing with right now, Bib-2 has little 
new to offer. The requisite access points are already in Bib-1 and the 
remains can be added in a separate set (ours is called "dan-1"). So what is 
the rationale to asking people to move to Bib-2?

It may be that what you really need is a marketing effort for the attribute 
set, but it will be a tough sell. Again, our problems in Denmark have had 
to do with fine-tuning the alignment of individual libraries's systems and 
their configurations, and determining what sort of role a Z39.50 -based 
virtual union catalog can play. Although we do follow Bib-2, the decision 
so far has been to leave it on hold basically because we have more pressing 
issues, and Bib-2 doesn't help us solve those any better than BIb-1 did.

>I cannot argue with Mike about the complexity of "Bib-2" as conceptually
>defined in the Bib-2 document.  But, during the time I've spent refining
>these specs over the  past year, I worked on the assumption that most of the
>details would be profiled out for general library applications.

Agreed. Just as Bib-1 becomes a lot more manageable when you look at it 
through the filter of Bath or one of the national profiles, so would Bib-2. 
I think it's safe to say that in an interoperability setting (communicating 
across systems), you'll most often see people specify subsets of any 
attribute set, rather than attempting to include everything.

>[For instance:  it was an interesting intellectual exercise for me to figure
>out where in a MARC-based bibliographic record  "geographic referents"
>occur.  But I expect that it will be a rare library catalogue that will
>actually  use those fields and index the information to allow for retrieval.
>But it's defined for the use of those library applications that can support

Yes. Consider that many elements of the national cataloguing rule are 
probably there to serve internal library administration rather than 
external users or other libraries. An all-inclusive Bib-2 is a useful tool 
for a library system that chooses Z39.50 as its internal communication 
protocol... it's probably less relevant for the national profiles which are 
more pragmatic.

In Denmark, the funding authority is quite clear on what they want out of 
Z39.50 -- they want cheaper ILL. If the users get a better service, that's 
good, but mostly they want to save money on costly referrals and manual 
processing of requests.

>I can see that the ability to combine this set with other modules of the new
>Attribute Architecture could be of great value.  It will only gain the full
>potential of its power when all the pieces are in place and working (one
>reason that I was willing to devote so much work to Bib-2 within the past
>year - so that piece would be there, just in case.)


>Since I've scheduled the meeting on Bib-2 to run concurrently with the
>tutorials on Tuesday afternoon, I can't expect that either of you, Sebastian
>and Mike, will be free to attend that review session- but hopefully we can
>address your concerns during the briefing on this work during the actual ZIG


Received on Thursday, 27 September 2001 12:05:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:03 UTC