darcusblog

I just posted this to the BiblioX list, and will do so here in case anyone has thoughts on this. It is based on the ideas laid out in this document.

This is an alternative to the current BibliX spec, an example of which is here. My belief is that by moving some of the logic for genres and names out of the main layout definition, there’s no need for anything beyond three or four definitions there.

When we think of this stuff, I think we need to keep in mind a use scenario. Let’s imagine:

• style file created by a life scientist (who only cites journal articles and, say, proceedings)
• style file downloaded by someone at the border of the social sciences and humanities like me, who may cite everything from articles to legal documents to speeches, to media sources
• imagine neither of these people have any deep knowledge of bibliographic theory and practice.

My contention is that modifying the style spec along the lines I am suggesting – perhaps along with a GUI or script interface – makes this workable. The layout information is generic, so that there is no need to explicitly define templates for every kind of resource. If our hypothetical humanities scholar downloads the stylefile created by our life scientist, the only change they might need to make is to add a few genre terms to get them to render.

Thoughts?

Note: this example is stripped-down and schematic; it is not a complete design.

<style>
  <names>
    <roles>
<!-- this just says, "if you have a name with this role, here 
     is how you handle it"; otherwise leave alone -->
      <creator>
        <editor>
          <single>Ed.</single>
          <multiple>Eds.</multiple>
        </editor>
      </creator>
      <contributor>
        <translator>
          <single>Tran.</single>
          <multiple>Trans.</multiple>
        </translator>
      </contributor>
    </roles>
  </names>
  <genre-terms>
<!-- this works the same as name roles; if listed here, the genre 
     term is printed as defined; otherwise not -->
    <thesis type="MA">MA Thesis</thesis>
    <memo>memorandum</memo>
    <speech>speech</speech>
  </genre-terms>
  <layout>
    <object>
      <creator/>
      <year beforesep="(" aftersep=")"/>
      <title/>
      <origin beforesep="(" aftersep=")">
        <publisher/>
        <place/>
      </origin>
      <contributor/>
      <genre/>
      <location/>
    </object>
    <part>
      <creator/>
      <year beforesep="(" aftersep=")"/>
      <title beforesep="“" aftersep="”"/>
      <container beforesep="In ">
        <creator/>
        <title/>
        <origin beforesep="(" aftersep=")">
          <publisher/>
          <place/>
        </origin>
        <genre/>
        <location/>
      </container>
    </part>
  </layout>
</style>

Responding to suggestions, Jon Udell has hit on using multiple css class definitions to semantically code XHTML. In one example, he has a blockquote with two definitions: a generic “personQuote” and another to identify the specific author source.

Having struggled a bit with how to mark up bibliographic annotations, this may well be a useful alternative, although I suspect it’d be too unwieldy. It’s not clear to me, for example, how to markup page numbers in such a system. Perhaps it’s just better code annotations in my own XML dialect and transform it.

Richard Lennox is working on an RDF representation of bibliographic data, and posted a comment on something I’d not run into before: XNAL. Apparently the OASIS group responsible for the standard are working on an RDF representation as well.

XNAL is indeed interesting, in part because it tackles name structures somewhat differently than the orthodoxy would suggest (see example below). For example, it has elements for first, last and middle names, which are typically seen as very Western (even U.S.) centric. But the standard allows attribute-level coding of data such as family and given names, abbreviations, etc. Hmm … wonder what the FOAF people – who have a proposal to revamp name support – think about this.

update: I just looked at the schema. One big problem here is that the name type values are just free text. That strikes me as a very bad idea.

<?xml version="1.0"?>
<xNL xmlns="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0 xNL.xsd">
  <NameDetails PartyType="Person">
    <PersonName>
      <Title>Mr</Title>
      <FirstName Type="GivenName">Ram</FirstName>
      <MiddleName>Laxhman</MiddleName>
      <MiddleName Type="Initial">B</MiddleName>
      <LastName NameType="SurName">Kumar</LastName>
      <Alias>Ram</Alias>
      <FormerName>
        <NameLine>Ramkumar</NameLine>
      </FormerName>
    </PersonName>
    <DependencyName PartyType="Person" DependencyType="C/O">
      <PersonName>
        <Title>Mr</Title>
        <FirstName Type="Official" NameType="GivenName">
        Venkat</FirstName>
        <FirstName Type="Unofficial" NameType="GivenName"> 
        Venki</FirstName>
        <LastName>Krishnan</LastName>
      </PersonName>
    </DependencyName>
  </NameDetails>
  <NameDetails PartyType="Person">
    <PersonName>
      <Title>Mrs</Title>
      <FirstName>S</FirstName>
      <MiddleName>Devi</MiddleName>
      <LastName>Sadasivan</LastName>
      <Alias>Baby</Alias>
    </PersonName>
    <DependencyName PartyType="Organisation">
      <OrganisationNameDetails>
        <OrganisationName NameType="New Name">NRMA ASSET MANAGEMENT</OrganisationName>
        <OrganisationName NameType="Formerly">NRMA INVESTMENTS</OrganisationName>
      </OrganisationNameDetails>
    </DependencyName>
  </NameDetails>
  <NameDetails PartyType="Person">
    <NameLine>Ram Kumar</NameLine>
    <DependencyName PartyType="Organisation">
      <NameLine>C/O MasterSoft International Pty. Ltd</NameLine>
    </DependencyName>
  </NameDetails>
</xNL>

Art Rhyno’s Memex proposal to serve content up via XSLT and WebDAV is intriguing, but how about pushing this farther into the realm of wireless and seamless network access?

I’d like to be able to go to my wireless-enabled library and have access to the library catalog on my Palm or laptop, to be able to easily save those records to my own data store, and to be able to annotate them while reading the text I have just found on the shelf. When I go back to the desktop machine in my office, I want it all to be available for incorporating into my documents: lecture outlines, journal articles, etc.

Isn’t this the precisely sort of thing that Apple’s Rendezvous technology is designed to facilitate?

Art Rhyno has run with one his comments here and suggested an outline of a project exploiting WebDAV, XML and XSLT. I’m not sure I totally understand the WebDAV connection, but I get the feeling Art is on to something here.

As he puts it:

[B]etween XML and WebDAV, and an XML architecture like Cocoon on a web server, your content might achieve a neutrality that allows it to plug into all manner of applications…. OpenOffice presents a great opportunity to use a documented XML format within the personal productivity suites that a lot of the world’s content is created in. WebDAV could even achieve the glow of RSS in this framework, RSS was around a long time before it became the focus of much of the web community, and WebDAV proxies may be an unobtrusive way of delivering content to much more than the web authoring tools it was originally intended for. Content creation is one of the most intimate points in the knowledge cycle, maybe the desktop is the ultimate portal or even memex that we have been trying to build within the confines of the web.

More at:

Is it Real or is it Memex More Memex Musings

Matthias Basler has put together a very preliminary GUI design document for the OpenOffice bibliographic project (available here). When I get time I’ll try to find more detailed comments, but in the meantime, let me start with some general observations on search interfaces.

I find many search interfaces for bibliographic records – whether online library catalogs or those in personal reference manager applications – awkward. They require too many mouse clicks, and slow down workflow. So I suggest a few models to learn from:

1. Google One of the reasons why Google has been successful is because of its simple inteface; a single field, with no other optional checkboxes or pop-ups.
2. Apple’s applications In applications like iTunes and Mail, there is a single search field above a table view. A search filters the view, and clicking on the columns resorts.
3. Endnote As much as I complain about Endnote, there are a few things I like. One is that in the table view, I can click a letter or letter-combo on the keyboard and quickly go to that point in the table.
4. Making remote access easier The standard protocol for searching and downloading online catalog records from libraries is Z39.50. A search interface for this protocol ought to be just as easy, and almost as sparse, as the generic local search interface. Rob Sanderson is doing some interesting prototyping on this for OOo, having previously come up with a similar UI for Mozilla, which will no doubt improve over time.

Perhaps it’s a function of the dominance of English on the Internet, but I’ve yet to see anything on an interesting project out Germany called SozioNet.

I quite like its MetaWizard entry interface. Building on ideas in the DC-Dot project, the interface optionally allows a user to specify a URL from which it can suck in metadata. Here’s the opening form, where you specify the type of record, the url, and the title.

Based on the input type, the user is then presented with a second form, which is rich with tooltips, and also has an elegant solution to the multiple authors issue.

Wolfgang Meier is one of the architects of SozioNet, as well as the force behind the eXist XML DB. He’s experimenting now with an XForms-based entry GUI for MODS data, and the project has expressed some interest in opening it up to contributions from an international community.

I just posted the following on the bib-dev list for OOo in response to Rob Sanderson’s observation that the Berkeley XML DB stuff is a just a library layered on top BDB itself:

Exactly. This seriously needs to be added to OOo. And I get the feeling the OOo developers ought to be talking to the Chandler developers, who are using the Berkeley XML DB technology along with RDF for their storage. Imagine if there was some way – in the not-too-distant future – to have OOo and Chandler communicate, such that contact and calendar data, bibliographic metadata, and documents themselves could all be tied together seamlessly…

It seems someone at Sun has finally understood not only the as-yet-untapped possibilities opened up with OpenOffice’s XML support, but also that the bibliographic project is an excellent real world example case. To wit, a recent meeting of the OOo file format Technical Committee meeting has identified key topics of discussion for the next phase of development discussions.

The TC members have already collected some topics that might be discussed in 2nd TC phase. These topics are:

• Security features (for instance digital signatures)
• Form features (for instance support of XForms functionality)
• Integration of user defined schemes
• Enhanced bibliography features

This is very encouraging, not so much because they have explicitly recognized the need to improve bibliographic support, but because this is placed within a larger and more comprehensive solution: namely support for arbitrary schema data, and XForm interfaces.

This is big stuff, if a little late coming. It would add InfoPath-like capabilities to a widely available open source software suite!

So … let’s see.

1. document data = XML
2. bibliographic metadata = XML
3. online access configuration files = XML
4. citation formatting specification file = XML
5. bibliographic metadata GUI specified in … XML

Very interesting indeed!

I also just learned that OOo already includes the Berkeley DB. Next step: add the XML libraries?

PS - I also love the fact the development for the file format is being done in RELAX NG!