Re: Tables of content

And as memory serves, ONIX is another vehicle that carries this
information in ways that promote its automated use. The idea is not bad
- using this information in ways not well supported in the transport
system MARC. The fun part is how to transport and then use the data in
ways that make sense - preferably in standards-based ways so code is not
provincial, proprietary, or one-use-only.

And I doff an imaginary hat at the many standards whose time was not
"right" at the point they were made. But the underlying ideas, if they
are good ones, or more importantly, the underlying problems, if they are
persistent ones, live on.

Candy Zemon
Senior Product Strategist
Polaris Library Systems
candy.zemon_at_polarislibrary.com
315-506-1611
www.techtidbits.info
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Ted Koppel
Sent: Monday, January 29, 2007 10:11 PM
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] Tables of content

Judith,

Great ideas all - and might I say, about eleven years late.  In the mid
1990s, as an outgrowth of the SICI (Z39.56) standard, work was begun on
a similar and self-derivable item identifier for pieces within a book.
It was called the BICI (Book Information Component Identifier or
something like that).  See the following URL for a short description:
http://cendi.dtic.mil/presentations/ref_link_blixrud.ppt.

It went exactly nowhere.  We finished a draft standard, but this took
place at a time when DOI was in its ascent and BICIs were seen as old
technology, despite their obvious benefits in self derivability, ability
to make hierarchical connections, and so on. Bottom line: nothing
official ever became of the BICI.  (There were other issues as well, but
nothing insurmountable.)

Still, as an answer to your quest: "describing parts that have their own
bibliographic integrity ... To spawn child records with appropriate
connections to parents"  - the BICI might be worth a second look.

No good deeds every go to waste....

Ted


-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Judith Pearce
Sent: Monday, January 29, 2007 8:16 PM
To: NGC4LIB_at_listserv.nd.edu
Subject: [NGC4LIB] Tables of content

While time travelling on this list I noticed a discussion on how to
encode tables of content in MARC records to support controlled access to
authors of the listed parts. I've been mulling over this issue for some
time in relation to our still image and audio digitisation projects.
When it comes to describing parts that have their own bibliographic
integrity I don't think trying to put this data in a note field is the
way to go.

In our new generation catalogues, why don't we throw tables of contents
in records away, start giving parts of things their own records and
express parent-child relationships in forms that enable users to
navigate up and down bibliographic hierarchies and that enable the
generation of tables of content dynamically in displays of the parent
record.

Why not encode and share tables of content and other lists in a form
that can be used to spawn child records that inherit parent details in
the appropriate fields and not bother storing this information in the
parent record at all.

This would make us look more closely at the information that needs to be
stored in the child record and the information that can be inherited
from the parent to create a full bibliographic citation.

It would also make us look at ways of making the encoded relationship
persistent when metadata is shipped to other places - union catalogues,
federated metadata repositories, Google. Blogs, bibliographies.

And it would make us look at ways of encoding the bibliographic citation
so that the content inherited from the parent is not lost on export and
the relationships can be fully exploited in the new context. I know
OpenURL and the DC Citation working group have been working on this
problem.

This thinking can be extended to manuscript and archive collections,
where we tend to treat the finding aid as a table of contents to the
whole collection. When a whole collection (or an item in a collection)
is digitised, there's a need to support component level searching and
bibliographic citation.

(How to handle parent-child relationships consistently and in a
user-friendly way is still a real issue in our own production systems.

http://nla.gov.au/nla.cat-vn3769891 is the best we can do with Voyager.
Nuff said.

http://nla.gov.au/anbd.bib-an40661746 is the same record in the
Australian union catalogue. The direct parent-child relationship is lost
because it was invoked by a local system number. The relationship has
been expressed as a series, which is certainly not FRBR correct and the
link retrieves all the bibliographic records with the same series
authority, not the parent record.

http://nla.gov.au/nla.ms-ms9803-1-13 - the same record in our digital
delivery system. It gives a full bibliographic citation with item number
and series details from the finding aid and enables navigation up and
down the hierarchy through breadcrumbs.)

Judith

Judith Pearce
Director, Feasibility & Standards
National Library of Australia
CANBERRA ACT 2600
phone: +61 2 62621425
email: jpearce_at_nla.gov.au

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.