ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Alan BRASLAU <alan.braslau@cea.fr>
To: Rob Heusdens <robheus@xs4all.nl>
Cc: ntg-context@ntg.nl, Hans Hagen <pragma@wxs.nl>
Subject: Re: Bibliography: criterium=all
Date: Wed, 16 Jul 2014 17:15:56 +0200	[thread overview]
Message-ID: <20140716171556.10bd4dae@iram-ha-003840.extra.cea.fr> (raw)
In-Reply-To: <53C673CB.9090106@wxs.nl>

BibTeX was one approach that is somewhat a standard. There are other
bibliography database file formats such as EndNote, RIS, and many
others. From an academic researcher's point of view, one practical
point is the accessibility of bibliographical data. Many websites, both
public as well as paying can output to these formats, so we use
them.

Hans has undertaken a lua reimplementation of using these bibliography
database files. BibTeX as a program is no longer used in the new
bibliography macros. Our use of the bibliography database is far from
covering all of the possibilities of the BibTeX program, but we are
building it up with functionality that we find necessary. The
performance appears to be quite satisfactory and the flexibility of
being able to program in lua has allowed Hans to fairly easily provide
whatever crazy functionality that we have thrown at him so far!

Maybe, as you suggest, a real relational database approach would be
useful. As long as it does not become too complicated and not impose
important dependencies. I am not a specialist on these issues so I do
not have any real opinion, though.

Alan




On Wed, 16 Jul 2014 14:44:59 +0200
Hans Hagen <pragma@wxs.nl> wrote:

> On 7/16/2014 2:24 PM, Rob Heusdens wrote:
> > Hello,
> >
> > This is more a 'side-comment', but anytime I see an application
> > that wants in fact to query data from some dataresource, I ask
> > myself: why is that not implemented as a real relational database?
> >
> > BibTex is some weird implementation for a problem that in facts
> > requests a real relational dababase approach, in which your data
> > does not reside in a file, but a couple of tables. Like PUBLISHER
> > (the organisation that publishes the article/book/journal, etc.),
> > PUBLICATION, EDITION, AUTHOR/CONTRIBUTOR (a person making a
> > contribution to a PUBLICATION, like author, co-author, editor) etc.
> >
> > For example: every author that has contributed to a publication (or
> > edition thereof) has only one record in the AUTHOR table, and for
> > each contribution to a PUBLICATION/EDITION there is a record in the
> > CONTRIBUTION table, with the foreign keys to the primary key of
> > AUTHOR/CONTRIBUTOR and to the PUBLICATION/EDITION table.
> >
> > A data-model for such must exist in the real-world, somewhere, I
> > guess. But Tex and other implementors have choosen to implement
> > this in a simple flat-file system, and which I think is part of the
> > problem, because the implemenation as flat file has certain limits.
> > Esp. when more demanding features are requested.
> >
> > Still thinking that ultimately that would be the best way to
> > implement BibTex, using a relational database as repository instead
> > of flat files. And you could implement many other 'nice' featueres,
> > like querying other works related to the works you want to cite
> > (for instance at the basis of relevant key/reference words or
> > other).
> >
> > Would be do-able I guess (LuaTex can access dabatases), only
> > problem is you have to convert al these .bib files into the
> > database format.
> >
> > But don't know if anyone has thought about implementing Bibtex as a
> > database.
> 
> the main problem there is that normally authors collect their own 
> bibentries and that bib has become sort of a standard ... i have no 
> problem with a database approach but it would also mean normalizing 
> (e.g. get rid of tex stuff in bib entries) and so
> 
> technically it's no problem but politically ...
> 
> (similar arguments can be given for math habit and so)
> 
> with context we're not too bound to such 'standards'  but we can't 
> ignore them (and therefore support them); the bib implementation is 
> flexible enough to be extended but in order to get a database
> approach done a reasonable set of users need to carry it
> 
> (there are some search options built in btw)
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


      reply	other threads:[~2014-07-16 15:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 10:39 Flavien Lambert
2014-07-15 20:31 ` Hans Hagen
2014-07-16  0:20   ` Flavien Lambert
2014-07-16  7:33     ` Hans Hagen
2014-07-16  8:10       ` Flavien Lambert
2014-07-16  9:15         ` Hans Hagen
2014-07-16  9:31           ` Flavien Lambert
2014-07-16  9:52             ` Hans Hagen
2014-07-16 11:59               ` Alan BRASLAU
2014-07-16 12:24                 ` Rob Heusdens
2014-07-16 12:44                   ` Hans Hagen
2014-07-16 15:15                     ` Alan BRASLAU [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140716171556.10bd4dae@iram-ha-003840.extra.cea.fr \
    --to=alan.braslau@cea.fr \
    --cc=ntg-context@ntg.nl \
    --cc=pragma@wxs.nl \
    --cc=robheus@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).