Static locator for bill and legislation?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Static locator for bill and legislation?

fbennett
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: Static locator for bill and legislation?

rmzelle
Administrator
On Mon, Apr 2, 2012 at 5:34 AM, Frank Bennett <[hidden email]> wrote:
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.

This reminds me of a suggestion I made earlier on attaching locators to item notes:


Would that be a possible way to keep track of provisions, without requiring separate (and hierarchically structured) items?

Rintze 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: Static locator for bill and legislation?

fbennett
On Mon, Apr 2, 2012 at 8:18 PM, Rintze Zelle <[hidden email]> wrote:

> On Mon, Apr 2, 2012 at 5:34 AM, Frank Bennett <[hidden email]> wrote:
>>
>> 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.
>
>
> This reminds me of a suggestion I made earlier on attaching locators to item
> notes:
>
> http://forums.zotero.org/discussion/17270/page-numbers/?Focus=99600#Comment_99600
>
> Would that be a possible way to keep track of provisions, without requiring
> separate (and hierarchically structured) items?
>
> Rintze

Good thought. That would avoid any need for adjustment in the
processor, since the locator and label would just come through in the
normal way. Statutes are a slightly different creature, though. In
modern legislative publishing (lead by ), the laws are held in an XML
database accessed via a RESTful API, so each provision has a unique
URL. The most advanced system around is legislation.gov.uk:

  http://www.legislation.gov.uk/ukpga/2003/17/section/177

If provisions are stored as first-class items, we can use the URL
stored on the item to invoke any magic in the client that can make use
of it. In Zotero, that might include tying in the LocateEngine to
leverage server-side data for interesting things like:

  - a TOC of the legislation at the point in time when the relevant
provision was enacted
  - a list of revisions to the provision over time
  - a list of inbound cross-references to the provision in other instruments
  - a list of regulations enabled by the provision
  - ???

On the client side, doing this from within subordinate item would
require a lot of extra work to replicate parts of the top-level item
logic inside the note object, and the result would be difficult to
maintain and possibly hard to understand.

There is also a portability issue. If provisions are top-level items
on client side, it should be simple to work out mappings to import
them into any CSL-consuming reference manager. I'm not sure the same
would be true of notes.

The grouping of separate items under a common ID could be done on
client-side; I've done the trial implementation inside the processor
(deriving keys from item metadata) just because I have better control
over the code there. But there's a benefit there, in that if it works,
the devs of calling applications won't need to implement the logic
separately, possibly with varying results.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel