Francesco wrote:

> the work you mention was and is very controversial among jazz discographers.
> For me there are two basic points: it is true that it has been mainly a
> compilation of older discographies with very little original work, and there
> is a lot of mistakes. At the same time it's about the only place you can
> find easily and at a glance a rough list of a jazz artist's discography, and
> I have been using it quite a lot since I bought the book edition. It 
> requires special care to double-check the information, but this is true of
> any source. The latest versions of it on CdRom allow searches for any 
> musician (i. e. not only leaders but members of the band) and song title (a
> vey useful feature), as well as copying and pasting the results of the
> search into any document. None of the other classic and pioneering works in
> the field, of whose research Lord benefited, has been updated with such
> modern facilities. I haven't tried the online edition yet. In short, there
> are many limits to it, but as of today I would not do without it.

When I spent some time back in 2003 or so looking at discographical
data (most of the controversy Francesco refers to is session data,
not "artifact" data), it was clear that any type of discographical
database has to allow alternative interpretations. That is, the
ontology should allow different interpretations to sit side-by-side,
so the end-user may decide for themselves which to use. Certainly, an
authority organization, such as ARSC, can assign an estimate of
reliability of the information, and of course the source of the
discographical information would be recorded as well (e.g., "Brian Rust
Jazz Records.")

Now, to quickly answer another private reply, let me offer a heretical
proposal: the "artifact" side of the database should record exactly,
and only, the data the artifact itself provides. This includes
misspellings, etc. No need to extrapolate or normalize. Normalization
is done elsewhere and at a later time -- in some cases possibly in
the session data, and in other cases in other specialized outside
databases (e.g., song and composition compendiums.) Doing this makes
life *so much easier* when transcribing and organizing the audio
artifact data. Where things get complicated is when we try to hook an
artifact to a session recording, and auxiliary information such as
musician bios and song/composition information.

(Still trying to figure out the best way to hook a 78 side which does
not provide matrix information, such as some pre-ARC Brunswicks, to a
given session. It can be done using unique identifiers, but still haven't
figured out the specifics -- I really don't think we should transfer any
data from the session data to fill out fields on the artifact
side-of-the-database.)

Jon Noring