[ARSCLIST] A formal open standard process proposed for ARSC Discographical Data Model and DTD

[Jon Noring <jon@xxxxxxxxxxx>]

Matthew Snyder wrote:

> The free discography software Brian facilitates exchange of discographical
> information via xml files, enabling researchers worlwide to pool their
> information. This has been underway for years now, under the radar (it
> seems). More information at www.jazzdiscography.com.

And this is definitely a good thing!

My view has always been that XML should form the basis, the "master"
if you will, for all discographical information. What is needed is a
data model (ontology), and then that ontology is realized with an
intelligently designed XML DTD or Schema allowing for validation.

I'm definitely interested to know the fine details of BRIAN's
underlying data model, since that's the most critical thing that
needs to be done right, and to be *openly* developed by the
discographical information user community with a formalized open
standards process.

Whatever application sits on top of the data model is not important
since any seasoned developer can build applications for creating and
reading discographical information organized to a given data model.

That is, we must not be seduced into thinking that the application
defines the discography. It does NOT! Designing our data model around
a certain application is putting the cart before the horse.

I am hoping that whatever ontology and associated XML DTD ARSC ends
up "blessing" (if it hasn't yet blessed BRIAN) is that the XML DTD
is a published, open standard. And as just mentioned, it needs to be
vetted by a number of XML, discography, database, library, developer
and other experts using a proper open standards process, which
includes substantial public input, before being released.

I don't believe BRIAN's data model and XML schema has been vetted
this way, but it can certainly be introduced to the open standard
process as a starting point (along with other proposed data models)
so we don't have to start totally from nothing. (Digging out my notes
on the beginning of a data model done back in 2003...)

Btw, ARSC should consider OASIS as one formal standards body to
develop the discographical data model and the associated XML DTD/
Schema. This allows a neutral ground where other organizations
interested in the specification(s) (e.g., Library of Congress, ALA,
etc.) can participate and contribute. OASIS also offers a proven,
"turn key" framework of organization and communication to conduct
open standards work in an effective manner. Here's the OASIS home
page:

   http://www.oasis-open.org/home/index.php

I've been involved with XML-based standards development since 1999,
and have co-authored all the IDPF e-book specifications (for example,
I wrote chapter 3 and authored both DTDs for OEBPS 1.2 -- I even
served as Vice Chair and Acting Chair for a time), along with the
OpenReader Specification and the Generalized Container Format. An
example OR specification, which ARSC could use as a pattern for the
final discographical data model specification, is found at:

   http://www.openreader.org/spec/bnd10.html


So far this whole approach of focusing on the application rather than
the data is, to be blunt, disconcerting. The BRIAN approach shows
great promise as an *application* for entering and reading
discographical information, but ARSC needs to finalize an open
standard discographical data model and associated DTD/Schema. I'm
sure applications like BRIAN can quickly adapt to whatever data model
results from this effort, and probably will be the first to market
since they already have a head start over others. Fortunately the
consistent XML DTD will assure that different applications will always
"speak the same language."

Of course, those who build applications should also participate in
this standards effort since they have a number of important formal
requirements, and general insights, to add to the spec development
process. In the development of e-book standards, developer input was
important to assure we didn't do something that would give developers
headaches or needless complications. But we also balanced the needs of
developers (who prefer to write as little code as possible) with the
equally important requirements of publishers, end-users, and other
important stakeholders in the e-book ecosystem.

So don't misconstrue my above comments as being hostile to application
developers -- they are not. But for ARSC there is a right way to do
this, and I believe what I propose is the right way for ARSC...

Jon Noring