Re: new bibliographic data schema proposal

On 4/25/06, Markus Hoenicka <[email protected]> wrote:

> 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).

But notice the difference even in how you describe it using natural
language. There are articles that are published in periodicals
(newspapers, magazines, journals, newsletters). The related type is
not intrinsic to the primary reference type.

> 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.

Just in the sense that you are collapsing the types for two related
items into a single type.

>  > 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?

No, it's fundamentally different because the RIS approach is
incredibly limited.  You indicate a relation with an opaque integer
whose meaning varies by reference type.

In this approach, you are in fact very precisely modelling exactly how
reference metadata works. If you cite a journal article, you say:

    [article] has title "X" and i<is published in> [journal] "Y", etc.

... where the stuff in brackets indicates entities and the <>
indicates a relation.

> 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).

Good; makes sense.

> The former must be associated with the latter, whereas the latter may be a
> standalone item.

Right.

> 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

Correct.

> That is, you have to run different queries depending on how the book
> was initially added to the database.

Hmm ... am not following you here.

In the database, the book in any case is stored separately from the
chapter and they are linked. That should be true regardless of "how
the book was initially added."

But sure, the query to grab the part vs. monographic title is going to
be different when referring to the chapter than it is when referring
to the book it is in. This is only logical; isn't it?

E.g. you say to someone "look at the chapter titled 'abc' in the book
called 'xyz'." You don't say "look at analytical title 'abc' that has
a monographic title 'xyz'."

In Rails code, you might do:

    recommendation = Chapter.find_by_title("abc")
    buy_this_book = recommendation.publication
    puts buy_this_book.title

If I just want all books (including that one):

    Book.find_all

> To me, this is just reinventing the downsides of RIS.

Not at all. In the approach I am advocating, you can reliably
represent everything in RIS, and MUCH more. It is basically the MODS
approach, but with a much tighter modelling. Each entity gets a type,
the types have some sort of hierarchy (a journal is a subclass of
periodical, for example, which is a subclass of Collection) so that
stuff doesn't fall through the cracks, and the linking is clear.
Likewise, the locator information in analyticals always is associated
with the main level.

>  > 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.

Not necessarily. The primary difference is that parts contain locators
like volume, issue, pages, while monographic items often contain
publishers. Those can (and probably should) be stored in separate
tables so that what is stored in parts and monographic rows per se is
pretty much the same.

I do think periodicals and such (collections) are a different matter though.

>  > > - 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.

Oh, yes, certainly. In fact, you can use the info uri schema to do
that like so "info:doi/10.1111/j.1467-8306.2005.00468.x".  I think
crossref does something similar:
"doi:10.1111/j.1467-8306.2005.00468.x". Both are valid uris.

Bruce


-------------------------------------------------------
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&kid0709&bid&3057&dat1642