My thoughts on the attribute discussion

I have a few comments and observations related to
the discussion of the Norzig bib-1 proposal.

First....

Mike Taylor wrote:

> I have reservations about plenty of these --
> quite apart from sharing
> Barbara's distaste for _any_ new BIB-1
> attributes -- but I wonder
> whether it's even worth discussing.  We all know
> BIB-1 is a garbage
> can, and it's hard to see that it makes much
> difference exactly how
> much garbage is contains.  So my first instinct
> was just to shug and
> say, what the hey, if NORZIG wants 'em, let it
> have 'em.

The simple fact is that Mike's  "garbage can"
theory is valid. We, the ZIG, explicitly took this
position a number of years ago.  We all understand
the reasons why we need to perpetuate bib-1 and
why, even, we need to add new Use attributes to it
--  we don't add these with interoperability in
mind, nor with adherence to any architectural or
even scope principals. If we want a carefully
crafted and thoughtfully scoped attribute set it
should be developed under the attribute
architecture. If we are to decide that the
attribute architecture effort is a failure (which
would be a shame), and go back to carefully
crafting bib-1 (which at this stage would be very
difficult if not impossible) then that's a
decision that the Z39.50 implementor community at
large would need to make and would probably
require that we convene a ZIG meeting.

Therefore....

"LeVan,Ralph" wrote:

> I have no problem with the proposed Use
> attributes.  But, I don't like the
> content rules associated with many of them.
> They call for the fields/access
> points to be specific codes.  I believe that
> such rules should be imposed
> through local profiles.  An example is the
> Nationality Use attribute.  If it
> may only have two letter codes, then I'll need
> an Uncoded-Nationality Use
> attribute.  Or, we'll all just ignore the
> semantics, just like we do today
> with Code--Language (Use attribute 54) which is
> the only Use attribute
> available to me to pass language queries.  I'd
> prefer not to continue that
> practice.

Given my comments above it should come as no
surprise that I don't agree with Ralph on this. I
don't see the proposed attributes as serving
applications other than those for which they have
been developed.

However....

"Larry E. Dixson" wrote:

> One of the requested new Use attributes
> (Subject--genre/form) is, in my
> opinion, already present.  I believe that Use
> attribute "1075" is the
> genre/form subject search.  Confusion is being
> caused by the name of
> this attribute in the current Bib-1 attribute
> list.  Attributes 1073-1079
> were given the following names:
>
>   1073  Subject-name-conference
>   1074  Subject-name-corporate
>   1075  Subject-name-form
>   1076  Subject-name-geographical
>   1077  Subject-name-chronological
>   1078  Subject-name-title
>   1079  subject-name-topical
>
> I think that the word "name" should be removed
> from 1075, 1077, 1078, and
> 1079, and that 1075 should be renamed
> "Subject-form/genre" (or
> "Subject-genre/form").  With this change, I
> think that NORZIG should use
> 1075.

I do agree with the principle that if there is a
perfectly appropriate attribute already in bib-1
that serves the purpose for which another is
proposed, then the new attribute should not be
added, and the existing attribute be used instead.

However in this case, I don't think we can simply
rename these, without the concurrence of the body
who originally proposed/added them. That would be
the German Library.

Anyone out there from the German Library who cares
to comment on Larry's suggestion?

And one more thing.....

Sebastian Hammer wrote:

> In DanZIG, we're also not using the attribute
> set architecture
> specifically. However, we did choose to create a
> new attribute set (Dan-1)
> for attributes of specific national relevance,
> rather than moving
> everything into Bib-1. This was based on the
> observation that pretty much
> all targets on the Danish market were capable of
> supporting multiple
> attribute sets when pushed.

This is a point worth  elaborating. When Sebastian
says "capable of supporting multiple attribute
sets" he means within a single search (I assume,
since dan-1 numbering begins with 1, which means
it doesn't "inherit" bib-1).

With respect to how many attribute sets a server
can handle there are  three degrees of
flexibility:
(1) Some servers ignore the attribute set oid and
just assume bib-1.
(2) Some recognize the oid but cannot handle more
than one in a search (because they are version 2).
An example is GILS.
(3) And some can handle multiple sets within a
query.

I understand the severe limitations of the first
two types, and why it is so hard to consider
implementing the new generation of attribute
sets.  I'm not so sure I understand the
limitations for the third type.

--Ray

Received on Monday, 24 March 2003 10:36:39 UTC