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 ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
