Re: new bibliographic data schema proposal

Hi,

Bruce D'Arcus writes:
 > I guess I just mean that levels are only one kind of relation of
 > relevance, and that there are other important ones. Likewise, to have
 > top-level elements like journalarticle is flattening the typing model.
 > 

Again I don't quite understand. journalarticle is a type that
describes an article published in a journal (using the analytical
information). You can link it to a periodical entry describing the
journal (using the monographic info). Alternatively you can provide
the monographic info in the same dataset, leaving it to the reference
database application to split it into two related entries. I wouldn't
call this flat.

 > Correct. It's just that for an atom:entry, there is always a title. As
 > with most recent formats, the focus is on the object of interest. So
 > if I write an xpath to grab all titles from an atom feed, it'd be
 > "//atom:title".
 > 
 > Consider the xpath to grab all primary titles with the level structure
 > (not using your precise element names, but you get the idea):
 > "//part/title|//publication/title[not(part)]".
 > 
 > Or say you were modeling this with objects. In the RIS-ish approach, you'd =
 > get:
 > 
 >    article_title =3D ref1.part.title
 >    book_title =3D ref2.publication.title
 > 
 > ... while the other approach you'd have:
 > 
 >    article_title =3D ref1.title
 >    book_title =3D ref2.title
 >    article_journal_title =3D ref1.container.title
 > 
 > So there's a mismatch between the models that is somewhat awkward. I
 > think it makes more sense, and its just as easy to handle
 > programatically, to do:
 > 
 > title
 > isPartOf (or whatever you want to call the level relation)
 >   title
 > 

Isn't that the ill-fated approach that RIS took with the TI element
(which can mean anything from an analytical to a monographic title)
and the likewise illogical AU to A1/A2/A3 mappings?

I took great care to make each level of a reference citable all by
itself. That is, a chapter in a book is represented as two entries in
the database: a chapter (analytical) and a book (monographic). The
former must be associated with the latter, whereas the latter may be a
standalone item. Querying for titles of the chapter reference thusly
means:

chapter_title = analytical.title
book_title = monographic.title

A direct query for the very same book results in:

book_title = monographic.title

In your approach the first query will give something like:

chapter_title = ref1.title
book_title = ref1.container.title

and the second:

book_title = ref2.title

That is, you have to run different queries depending on how the book
was initially added to the database. To me, this is just reinventing
the downsides of RIS.

 > Certainly in a database, one need not store parts and publications in
 > separate tables.
 > 

In order to be as relational as possible, you should store them in
separate tables. Both levels have different storage requirements.

 > > - if you work with URIs to address relational parts of a reference,
 > > who defines/publishes these items?
 > 
 > Anybody, really. But having a standard id helps to at least solve the
 > problem of "how do we identify something". That it's hooked into the
 > architecture of the web is the all the more useful.
 > 

Well, in my area of work the DOI seems to be more suitable to identify
an article. But you do have a point here.

regards,
Markus

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



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642