Re: new bibliographic data schema proposal

"Bruce D'Arcus" <[email protected]>
Newsgroups gmane.text.refdb.general
Message-ID <[email protected]>
On 4/23/06, Markus Hoenicka <[email protected]> wrote:

>  > I suppose in a nutshell my argument is that the three-level structure
>  > and flat typing is still not very, um, relational.
>
> I can't follow you here. In risx, only periodicals were treated in a
> more or less relational fashion. rbib treats the relationships of all
> levels in a relational fashion, regardless of the reference type. You
> can even define relations between datasets, regardless of the level of
> the dataset. Is it that the relations are hard-linked only in the
> database, not in the XML file?

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.

More below ...

>  > Also, I think there
>  > are some recent developments around syndication technologies in
>  > particular, as well as RDF, that make it pretty important to fit new
>  > formats into those methods of modelling data, identifying things
>  > (increasingly using uris) and so forth.
>  >
>
> Two things:
>
> - isn't the data format definition (the RelaxNG schema in this case)
> independent of the modes of distribution (e.g. an Atom feed)? I don't
> know much about Atom, but it seems to me that you can embed just about
> anything as a payload (at least with namespaces).

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 = ref1.part.title
   book_title = ref2.publication.title

... while the other approach you'd have:

   article_title = ref1.title
   book_title = ref2.title
   article_journal_title = 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

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

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

> Do you expect them to be universally available on the web?

In the long run, yes, and even now we can grab a lot of this data off
the web using standard ids like this. See, for example, this little
python script:

<http://onebiglibrary.net/project/opa/opa-0.2-release-with-json-wrapper>

But even if not available now, you can still always include that
information. For example, with RDF, if I have a link that says:

<dcterms:isPartOf rdf:resource="urn:isbn:34354466"/>

I can always add that book too:

<Book rdf:about="urn:isbn:34354466">
  ...
</Book>

> Do you expect the bibliographic dataset an URI points to to be unique on the web?

Not necessarily.  Exploiting uris and standard ids really just makes
it easier to associate and merge data. Even for citation purposes this
can be critical.

Consider, for example, if you are collborating on a document with
someone who uses a different database. How do you know you're
referring to the same items when you cite something with just a plain
key? Answer: you don't. It's why these days my citations look like:

<citation><biblioref xlink:href="urn:isbn:343542566"/></citation>

There's a pretty good discussion of uris in the context of RDF here:

<http://taubz.for.net/code/semweb/whatisrdf/#Distributed%20Information>

> Why would you want to store the stuff in a database then? What do you do when you're
> offline?

Per above, I'm not saying the data needs to be only available on the
web, just that idenfitying things in this way opens up a lot of
flexibliity, and enhanced interoperability.

>  > That said, if all you're interested in is improving RISX, then it
>  > seems you're on the right track. But even so, I think you can bring it
>  > closer in line with my suggestions.
>
> I wouldn't mind, but I guess I'll have to learn quite a bit.

:-)

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.