Subject: Re: Cataloging of Multimedia E-Journals
Tony Barry (tonyb@dynamite.com.au)
Date: Sun, 22 Aug 1999 22:54:45 +1000
Message-Id: <l03130304b3e59b9fcbe5@[203.37.43.24]> In-Reply-To: <s7bd3b6a.048@gwgate.lib.iastate.edu> Date: Sun, 22 Aug 1999 22:54:45 +1000 To: arl-ejournal@arl.org From: Tony Barry <tonyb@dynamite.com.au> Subject: Re: Cataloging of Multimedia E-Journals
On 8/20/99, Gerry Mckiernan <gmckiern@gwgate.lib.iastate.edu> wrote:
>
> You raise an interesting point here, However, it seems that at
> present from my superficial review of the _M-Bed(sm)_ multimedia
> journals that individual journals limit the multimedia that can
> be used.
Commercial print journals with electronic equivalents certainly. I'm
not so that this applies to electronic only "journals"
> This raises a host of related issues and possible solutions. Would
> a link to the appropriate page of a given e-journal to its multimedia
> types and required plug-ins be possible within the bibliographic
> record?
If you can link to the page for the journal where any responsible
web site will indicate what is needed why clutter the bibliographical
record? The needed information will normally only be one or two
clicks away.
> My personal conclusion about the choice of noting Acrobat is that
> we still have a 'print/paper' mind set and unconsciously see only
> the paper analog version [Is this an unreasonable conclusion?]
The entire idea of a "journal" with "issues" is a print mind set. If
the journal is multimedia in _can't_ have a print equivalent.
> This does raise *the* basic issue: What is to described and how should
> we describe it? It also raises the issue of the multiple roles that
> a bibliographic/surrogate record has taken on, e.g. information about
> preservation.
It seems to me that the bibliographic/surrogate record was in the
catalogue in such detail so that a decision could be made as to whether
it was worthwhile to go and find the item on the shelves. If the item
is a click away and then on the screen there is no need for a detailed
surrogate (if you don't have to pay for access). If you do have to pay
then you will want more information. I am convinced however that the
future for "journals" which charge end users and libraries for access
is bleak. I'm with Harnard on this on. Authors and their organisations
or professional societies are more likely to carry the funding in an
electronic world.
> > How would you describe Java-based multimedia components?
>
> Good question, but some of the bib records for the multimedia e-journals
> note for example that the journal exists in HTML format and that it is
> available via the World Wide Web. Is this necessary? Is it necessary
> to note the Java requirement? I would say 'Yes' to both questions.
You need a pretty old browser to find one which does not support Java.
I often turn Java off as few sites providing useful information require
it and I find helpful messages as to the functionality I am missing and
sometimes a link to where I can update.
If you are going to say anything about Java being needed in the record
you need to indicate which version and which implementation eg an
"enhanced" Microsoft version which breaks Netscape. You would also
need to put in requirements for javascript, jscript, etc. Why bother
to add this to the record when a link to the site provides the
information?
> I just became aware of SMIL ('smile') two weeks ago and am glad you
> mention it. To me, SMIL -- the Synchronized Multimedia Integration
> Language -- holds great potential for multimedia presentation
> [Readers may wish to review the W3C site for details about SMIL at
> http://www.w3.org/AudioVideo/ ]
And XML, MathML, ChemML, with and without RDF which may or may not
encapsulate Cublin Core which may specift AACRII for names or something
else, MESH or LC for subjects or something else etc.
> This is *the* question! *Is* it sufficient? Here again, it depends
> on what role the record should play.
That's the question. My view is that records need hold far less than
they did before as they can link to where the information can be
obtained. Fo instance do you need a full bibliographical record if
one click gives you the actual document?
> Does / Can / Should a library allow its users to download and install
> any and all plug-ins?
We can expect users to have their own equipment and not fiddle with
the libraries. On the other hand the library should install any
helper or plugin which might be needed.
> > I think it also points out the short-comings of the MARC record
> > as a descriptor for digital resources, and the need for movement
> > on integrating emerging metadata standards into library systems
> > (and building new library systems).
>
> Yes. Your point does raise other issues, e.g. how do we integrate
> two different systems in one OPAC?
I increasingly wonder if it isn't the complexity of the MARC record
which is holding us back
> I like your last point here and its implications: Let the
> hardware/system handle the multimedia seamlessly
That's why the browser was invented, to pull together the protocols --
ftp, gopher, http and telnet (wais and z39.50 are there to but have
never got of the groups other than wais as a helper application) and
the formats through MIME tagging
> > That way the bib record does not have to be everything to everyone.
>
> Another point of view would be that the bib record becomes more than
> just a describer but takes on other roles, e.g. link to full-text
> [e.g., 856].
Once the 856 link is there you potentially have not just the full text
but all the details that might be in the bib record.
> Yes. We do need to re-think MARC in light of the multimedia issues
> and the like.
It's not just MARC it's also the catalogue. As more and more
material is on the "shelves" of the internet should we catalogue them
at considerable expense or find them through another for of database
and consider the bibliographical entries in the catalogue as just
legacy data which we access like any other database on the internet?
Tony
- - - - - - - - - - - - - - - -
phone +61 2 6241 7659
mailto:me@Tony-Barry.emu.id.au
http://purl.oclc.org/NET/Tony.Barry
This archive was generated by hypermail 2a16 : Mon Dec 20 1999 - 18:02:15 EST