Re: RefDB and Jurabib

Hi Jeremy,

Jeremy Malcolm writes:
 > I'm resending this message because this didn't appear in the last 
 > archives after two days so I guess it got lost along the way.  Sorry if, 
 > despite that, it is in fact a duplicate.
 > 

I'm afraid it was a duplicate but don't worry about that. The list
archives are not a good way to check whether your mail went through
because they often lag behind a week or more.

 > It does not store them.  Amonst the unusual ones that Jurabib needs are
 > booktitle, edition, howpublished, institution, language, school, series,
 > type, urldate, volumetitle, dissyear, howcited, shorttitle, shortauthor,
 > ssedition, titleaddon, booktitleaddon, editortype, sortkey, annote,
 > gender, translator, updated, totalpages, founder, archive, and a number
 > of others, most of which are documented at
 > http://jurabib.homelinux.org/jurabib/docs/english/jbendoc.html, but
 > others only in the source code.

Apparently there is no comprehensive (or comprehensible?) list of
fields which Jurabib actually uses. I've found a few fields mentioned
in that documentation, but even in those case it is not always clear
to me what information they are supposed to carry.

 > 
 > Admittedly, not all of these are equally important, and some can use
 > other existing fields; for example urldate can probably use a secondary
 > pubdate, edition can sometimes use volume (but what if there is a volume
 > *and* an edition?), and some of the others might be able to use the
 > spare fields (refdb_user1-user5 and refdb_misc1-misc3) in the refdb
 > database table.
 > 

The following mapping seems to make sense to me:

booktitle: BT

edition (book, chapter, and a few others): VL (the SVN version treats
this internally like an issue, as that is used only for periodical
publications)

institution (thesis, conference and the like): PB

school (thesis): PB

urldate: Y2

dissyear (thesis?): PY

annote: N1

The following fields whose semantics I believe to understand are
currently not supported: language, howcited

The following "fields" seem to depend on the citation style and should
as such not be stored in the database, but created from other fields
(I'm not sure though): shorttitle, shortauthor

All other fields are unclear to me and would require a formal
definition of their purpose.

 > But this doesn't really scale too well, so perhaps rather than patching
 > the code for every new field that anyone wants, there could be an
 > interface in RefDB for users to add an arbitrary number of new fields,
 > and optionally to define how these are mapped to RIS fields (though I
 > realise that RIS isn't extensible like BibTeX is).  I am probably
 > overlooking some valid reason why that isn't possible.

I've been thinking about moving to a richer data model for quite some
time. I've tried MODS a while ago but this turned out to be far too
complex (and far too flabby) to solve the problems of RIS. I've
started defining a new format called rbib
(http://refdb.sourceforge.net/rbib.html) which is still open for
modifications. You're welcome to suggest additions here.

Basically RefDB could povide a mechanism to add arbitrary properties
(implemented as key/value pairs in a separate table) to references. It
is simply a question of how we're supposed get them into and out of
the database without defining these properties in the data
formats. BibTeX is easy to extend because it does not make any
assumptions about the relationship of the fields. Other, more
structured formats like risx or rbib are harder to extend.

 > Sorry, you're right and I should have been more exact.  I just meant
 > that this explains why I need to move to Jurabib and drop DocBook
 > (despite preferring SGML/XML to TeX), as the former supports all the
 > features that I mentioned needing in that post - even down to enclosing
 > the year in parentheses for journals that use a volume number, and
 > square brackets for those that don't.
 > 
 > I agree that this kind of thing is too obscure to expect RefDB to
 > support, or at least should be a lower priority to implement.  Since TeX
 > will always be a more fine-grained tool for formatting, I think it is
 > better to use it for that for now, and RefDB just as a reference
 > database.  Do you agree, or is it worth trying to duplicate some of
 > Jurabib's obscure formatting features?
 > 

Well, it is probably not worth attempting this with RefDB's current
bibliography code. On the long run it may be prudent to move to raw
instead of cooked bibliography output and externalize the formatting
of the citations and the bibliographies entirely to the publication
step, along the lines of what citeproc does. However, this will
require a complete rewrite of the DSSSL and XSLT stylesheets, and this
is not likely to happen on a rainy Sunday afternoon. XSLT is said to
be a complete programming language and should be able to do anything
that TeX can. DSSSL (or rather, the only DSSSL engine that we have)
may be more limited and may suffer from a few restrictions though. In
any case, I guess it would require the commitment of one or more
persons who know XSLT/DSSSL and who are familiar with the citation and
bibliography requirements of legal studies and of scientific
manuscripts in the humanities.

regards,
Markus

-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/