On Mon, Apr 2, 2012 at 8:18 PM, Rintze Zelle <[email protected]> wrote: > On Mon, Apr 2, 2012 at 5:34 AM, Frank Bennett <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
