I’ve finally turned to the legislation item type in the suite of legal
styles that I’ve been building out these past months. I have an odd
idea for improved handling of this class of material, which I’ve
implemented to see if that would turn up any problems. It hasn’t, so
I’ll throw the idea up here for comments.
In CSL we handle a statute as a single item (as for a book or an
article), and provide the section number as a pinpoint locator. This
works fine inside CSL itself, but with a simple data model that
assumes a one-to-one link between CSL items and database/UI items in
the calling application, we have the entire statute as a single entry
in the reference manager database.
The problem with this is that the entirety of a statute almost never
serves as a unit of analysis; attention always focuses on specific
provisions, each of which invites a large amount (sometimes a very
large amount) of commentary. In a reference manager, if all commentary
related to all provisions in a statute are attached to a single,
top-level item, things can very quickly become unmanageable.
What I’ve done as an experiment is to set the locator as a static
value on the item itself, both on the client side (in Zotero, for
testing) and in citeproc-js. This requires some small adjustments to
processor position evaluation logic, but once that’s done, it all
seems to work like a charm. Here is a test that exercises the
behavior:
https://bitbucket.org/fbennett/citeproc-js/src/a5203d0d4cea/tests/fixtures/local/statute_Backref.txt
In terms of user experience in the calling application, the provision
level is definitely the right unit of reference for note-taking, etc.
I can see several ways of setting that up. One is to adapt the
processor to run, as illustrated in the test, with a static locator
(in some form – using the section field with parsed-out label strings
may not be ideal). Another would be to make no adjustments in the
processor, and put the burden on calling applications to find a way of
dicing up statutes into manageable units.
The problem I see with the latter approach is that programmers of a
calling application will be tempted to “do the right thing” and treat
the statute as an object with a hierarchical structure internally (an
XML construct). Doing that unavoidably opens up a massive engineering
task that John Sheridan and Jeni Tennison are working on in the UK:
statutes change over time, and so the XML object needs to support
versioned storage. It’s not really necessary, since a reference
manager is only used for handling individual scraps of a statute for
writing purposes – for research, it is sufficient that the user has a
browser channel through which the user can access robust data stores
(like legislation.gov.uk), through which to discover the scraps that
they actually want to work on.
So my simple solution is:
(1) for legislation and bills, build a shadow ID from the name of the statute,
issued, original-date, and disambiguating fields (volume, number,
container-title).
(2) where the shadow ID is available, use it for the purpose of position
evaluation, and in this case use the static locator variable for position
evaluation as well, rather than a user-supplied value.
This seems hackish, but it certainly works very smoothly for Zotero, I suspect
it would work equally smoothly for other reference managers, and I’m unable to
find a downside larger than the alternatives.
Thoughts?
Frank