On Thu, Jun 7, 2012 at 10:13 PM, Bruce D'Arcus <[email protected]> wrote: > On Thu, Jun 7, 2012 at 9:04 AM, Frank Bennett <[email protected]> wrote: >> On Thu, Jun 7, 2012 at 8:57 PM, Bruce D'Arcus <[email protected]> wrote: >>> Minor issue: >>> >>>> { "label": "none", "locator": "Act I, scene i, lines 12-23" }. >>> >>> First point is this is easier as just: >>> >>> { "locator": "Act I, scene i, lines 12-23" }. >>> >>> E.g. just make the label key optional. >>> >>> The second point is more about the substance of the proposal. If I >>> understand right, we have two, completely orthogonal, issues here. >>> >>> 1) custom locators (what to do about point locator labels we haven't >>> itemized?) >>> >>> 2) multiple locators >>> >>> This proposal (as represented in the example above; it's doesn't seem >>> to be formalized as such) attempts to solve both problems at once, so >>> that the upshot is that the second problem requires a free text value. >>> >>> For sake of argument, why not split these issues, so that you have a >>> point locator defined as a list of key values; something like? >>> >>> [ >>> { "act": "1"}, >>> { "scene": "3"}, >>> { "value": "foo 5"} >>> ] >>> >>> Bruce >> How would this work in a user interface? > > Is that really our concern? > > Seems to me we want a good, stable, spec that leaves room for > different sorts of UI approaches. > > It might be, for example, that some apps (like Zotero) just have a > simple field and parsers that field as a set of comma-separated > values. > > It might be that other apps treat it more structured. > > I guess I just need think if we're going to go this way, we better > define the model (is a point locator a single value, or is it a list > of key-values) so that it's clear, and that we probably shouldn't be > changing it later.
I adopted an approach like this in CSL for Law. Some specialised problems emerged, and it would be good to have them taken into account at this point. We hold individual provisions in Zotero as separate items (having one item for an entire statute is not useful, but if we are able to link and comment on individual provisions, it is very useful). One CSL item field (section) is reserved for locator information. This consists of (optional) label strings (sec., p. etc) and accompanying locator strings. There can be several sets of these in the field, each separately evaluated for pluralism, numeric/non-numeric status, and so forth. There were a number of tricky issues, but one of the most difficult was working out how an actual, user-supplied locator field and label should interact with the leading, structured portion supplied via the "section" field. For example, suppose an entry for 23 USC 253(a), where the section field is set as "sec. 253(a)". Now suppose this provision is cited at 253(a)(i), with "(i)" supplied via the user locator. Alternatively, suppose it is cited at 23 USC 253(a) para. 2, where the "para." element might come from the pull-down menu, or be supplied as an abbreviated term at the start of the locator field. There are also problems with multiple locators, such as "23 USC 253(a) & 264". I was able to make things work pretty well (i think), but the experience suggested to me that mixing two structures in input (pull-down labels for the initial element, possibly overridden by a leading in-field label like "sec.", and embedded in-field labels for the rest) was a headache. It will be easier to just use embedded in-field label abbreviations for everywhere and dispense with the pull-down label altogether in the UI. The use case shown above (with "&") also shows that a strict key/value representation will be too limiting. We need to localize the label to the style (so "sec." or "section" in some styles, and a section symbol in others), but preserve user-supplied connecting punctuation. It's a messy half-structure, but that's how things are referenced, and I concluded that there isn't much that can be done for further discipline. Frank ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
