Improving support for locators

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

Improving support for locators

rmzelle
Administrator
Cites can include locators to specify a location within a larger work, e.g. "(Doe et al. 2000, pp. 14-24)". CSL 1.0 has a defined set of locator terms, such as "volume", "chapter", "page", etc (see http://citationstyles.org/downloads/specification.html#locators for the full list). With the citeproc-js JSON input format, the locator information of a cite is stored in two fields: a) "label", which specifies the locator term, e.g. "page", and b) "locator", which stores the (numeric) locator value, e.g. "14-24". See https://bitbucket.org/bdarcus/citeproc-test/src/6fda4656cf9d/processor-tests/humans/locator_SimpleLocators.txt#cl-61 for an example.

While this approach works quite well, there have been several user requests to expand the number of locator terms. We could just expand the current set, although it might be hard to cover all the desired locator terms, and having a long list would increase UI clutter. More problematic are hierarchical locators (e.g., "Act I, scene i, lines 12-23").

One of the suggestions that has come up is to keep the current list of locator terms mostly untouched, and add an "empty" locator term. If this locator type is selected, both the locator descriptions and values would be stored in the "locator" field of citeproc input JSON, e.g. { "label": "none", "locator": "Act I, scene i, lines 12-23" }.

Does anybody have an opinion about whether this is an acceptable way to improve the support for locators?

Rintze

P.S. The related GitHub issue can be found at https://github.com/citation-style-language/schema/issues/94

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

Re: Improving support for locators

Sebastian Karcher
I'm strongly in favor of this.

On Mon, Jun 4, 2012 at 7:06 PM, Rintze Zelle <[hidden email]> wrote:

> Cites can include locators to specify a location within a larger work, e.g.
> "(Doe et al. 2000, pp. 14-24)". CSL 1.0 has a defined set of locator terms,
> such as "volume", "chapter", "page", etc (see
> http://citationstyles.org/downloads/specification.html#locators for the full
> list). With the citeproc-js JSON input format, the locator information of a
> cite is stored in two fields: a) "label", which specifies the locator term,
> e.g. "page", and b) "locator", which stores the (numeric) locator value,
> e.g. "14-24". See
> https://bitbucket.org/bdarcus/citeproc-test/src/6fda4656cf9d/processor-tests/humans/locator_SimpleLocators.txt#cl-61
> for an example.
>
> While this approach works quite well, there have been several user requests
> to expand the number of locator terms. We could just expand the current set,
> although it might be hard to cover all the desired locator terms, and having
> a long list would increase UI clutter. More problematic are hierarchical
> locators (e.g., "Act I, scene i, lines 12-23").
>
> One of the suggestions that has come up is to keep the current list of
> locator terms mostly untouched, and add an "empty" locator term. If this
> locator type is selected, both the locator descriptions and values would be
> stored in the "locator" field of citeproc input JSON, e.g. { "label":
> "none", "locator": "Act I, scene i, lines 12-23" }.
>
> Does anybody have an opinion about whether this is an acceptable way to
> improve the support for locators?
>
> Rintze
>
> P.S. The related GitHub issue can be found at
> https://github.com/citation-style-language/schema/issues/94
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>



--
------
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

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

Re: Improving support for locators

Charles Parnot
sounds  like a good way  to fall back on any custom scheme for users.

On Jun 4, 2012, at 7:30 PM, Sebastian Karcher wrote:

> I'm strongly in favor of this.
>
> On Mon, Jun 4, 2012 at 7:06 PM, Rintze Zelle <[hidden email]> wrote:
>> Cites can include locators to specify a location within a larger work, e.g.
>> "(Doe et al. 2000, pp. 14-24)". CSL 1.0 has a defined set of locator terms,
>> such as "volume", "chapter", "page", etc (see
>> http://citationstyles.org/downloads/specification.html#locators for the full
>> list). With the citeproc-js JSON input format, the locator information of a
>> cite is stored in two fields: a) "label", which specifies the locator term,
>> e.g. "page", and b) "locator", which stores the (numeric) locator value,
>> e.g. "14-24". See
>> https://bitbucket.org/bdarcus/citeproc-test/src/6fda4656cf9d/processor-tests/humans/locator_SimpleLocators.txt#cl-61
>> for an example.
>>
>> While this approach works quite well, there have been several user requests
>> to expand the number of locator terms. We could just expand the current set,
>> although it might be hard to cover all the desired locator terms, and having
>> a long list would increase UI clutter. More problematic are hierarchical
>> locators (e.g., "Act I, scene i, lines 12-23").
>>
>> One of the suggestions that has come up is to keep the current list of
>> locator terms mostly untouched, and add an "empty" locator term. If this
>> locator type is selected, both the locator descriptions and values would be
>> stored in the "locator" field of citeproc input JSON, e.g. { "label":
>> "none", "locator": "Act I, scene i, lines 12-23" }.
>>
>> Does anybody have an opinion about whether this is an acceptable way to
>> improve the support for locators?
>>
>> Rintze
>>
>> P.S. The related GitHub issue can be found at
>> https://github.com/citation-style-language/schema/issues/94
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>>
>
>
>
> --
> ------
> Sebastian Karcher
> Ph.D. Candidate
> Department of Political Science
> Northwestern University
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Charles Parnot
[hidden email]
twitter: @cparnot
http://mekentosj.com



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

Re: Improving support for locators

Carles Pina
Hi,

Sounds good here too.

On 5 June 2012 04:23, Charles Parnot <[hidden email]> wrote:

> sounds  like a good way  to fall back on any custom scheme for users.
>
> On Jun 4, 2012, at 7:30 PM, Sebastian Karcher wrote:
>
>> I'm strongly in favor of this.
>>
>> On Mon, Jun 4, 2012 at 7:06 PM, Rintze Zelle <[hidden email]> wrote:
>>> Cites can include locators to specify a location within a larger work, e.g.
>>> "(Doe et al. 2000, pp. 14-24)". CSL 1.0 has a defined set of locator terms,
>>> such as "volume", "chapter", "page", etc (see
>>> http://citationstyles.org/downloads/specification.html#locators for the full
>>> list). With the citeproc-js JSON input format, the locator information of a
>>> cite is stored in two fields: a) "label", which specifies the locator term,
>>> e.g. "page", and b) "locator", which stores the (numeric) locator value,
>>> e.g. "14-24". See
>>> https://bitbucket.org/bdarcus/citeproc-test/src/6fda4656cf9d/processor-tests/humans/locator_SimpleLocators.txt#cl-61
>>> for an example.
>>>
>>> While this approach works quite well, there have been several user requests
>>> to expand the number of locator terms. We could just expand the current set,
>>> although it might be hard to cover all the desired locator terms, and having
>>> a long list would increase UI clutter. More problematic are hierarchical
>>> locators (e.g., "Act I, scene i, lines 12-23").
>>>
>>> One of the suggestions that has come up is to keep the current list of
>>> locator terms mostly untouched, and add an "empty" locator term. If this
>>> locator type is selected, both the locator descriptions and values would be
>>> stored in the "locator" field of citeproc input JSON, e.g. { "label":
>>> "none", "locator": "Act I, scene i, lines 12-23" }.
>>>
>>> Does anybody have an opinion about whether this is an acceptable way to
>>> improve the support for locators?
>>>
>>> Rintze
>>>
>>> P.S. The related GitHub issue can be found at
>>> https://github.com/citation-style-language/schema/issues/94
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>>>
>>
>>
>>
>> --
>> ------
>> Sebastian Karcher
>> Ph.D. Candidate
>> Department of Political Science
>> Northwestern University
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
> --
> Charles Parnot
> [hidden email]
> twitter: @cparnot
> http://mekentosj.com
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Carles Pina | Software Engineer
http://www.mendeley.com/profiles/Carles-Pina/

Mendeley Limited | London, UK | www.mendeley.com
Registered in England and Wales | Company Number 6419015

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

Re: Improving support for locators

Bruce D'Arcus-3
In reply to this post by rmzelle
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

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

Re: Improving support for locators

fbennett
On Thu, Jun 7, 2012 at 8:57 PM, Bruce D'Arcus <[hidden email]> 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?

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

Re: Improving support for locators

Bruce D'Arcus-3
On Thu, Jun 7, 2012 at 9:04 AM, Frank Bennett <[hidden email]> wrote:

> On Thu, Jun 7, 2012 at 8:57 PM, Bruce D'Arcus <[hidden email]> 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.

Bruce

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

Re: Improving support for locators

fbennett
On Thu, Jun 7, 2012 at 10:13 PM, Bruce D'Arcus <[hidden email]> wrote:

> On Thu, Jun 7, 2012 at 9:04 AM, Frank Bennett <[hidden email]> wrote:
>> On Thu, Jun 7, 2012 at 8:57 PM, Bruce D'Arcus <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: Improving support for locators

Bruce D'Arcus-3
On Thu, Jun 7, 2012 at 10:08 AM, Frank Bennett <[hidden email]> wrote:
> On Thu, Jun 7, 2012 at 10:13 PM, Bruce D'Arcus <[hidden email]> wrote:

...

>> 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.

Just emphasizing here this is my key point. But ...

...

> 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".

Right. While I don't understand all the intricacies of your case, the
point is my suggestion here does not mean these fields are free text;
they are comma-separated lists of structured key values, where
optionally a key is empty and its value is free text.

So users would have to account for that presumably. I can't imagine
any other way.

> 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.

OK. Sounds like we agree.

> The use case shown above (with
> "&") also shows that a strict key/value representation will be too
> limiting.

But that presumes we all accept the requirement that users should be
able to do that. I don't (but my opinion is just one).

> 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.

Given this is the key problem now in moving forward with a concrete
proposal, can you expand on why you say this is a requirement?

Consider how Zotero deals with dates; why not something like that here?

Bruce

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

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

Re: Improving support for locators

rmzelle
Administrator
On Thu, Jun 7, 2012 at 10:31 AM, Bruce D'Arcus <[hidden email]> wrote:
> The use case shown above (with
> "&") also shows that a strict key/value representation will be too
> limiting.

But that presumes we all accept the requirement that users should be
able to do that. I don't (but my opinion is just one).

Accept which requirement, exactly? That users should be able to create complex cites such as "23 USC 253(a) & 264"?
 
> 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.

Given this is the key problem now in moving forward with a concrete
proposal, can you expand on why you say this is a requirement?

Consider how Zotero deals with dates; why not something like that here?

Do you suggest using a dedicated cs:locator rendering element, akin to cs:dates? How would that work?

Rintze

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

Re: Improving support for locators

Bruce D'Arcus-3
On Fri, Jun 8, 2012 at 1:52 PM, Rintze Zelle <[hidden email]> wrote:

> On Thu, Jun 7, 2012 at 10:31 AM, Bruce D'Arcus <[hidden email]> wrote:
>>
>> > The use case shown above (with
>> > "&") also shows that a strict key/value representation will be too
>> > limiting.
>>
>> But that presumes we all accept the requirement that users should be
>> able to do that. I don't (but my opinion is just one).
>
>
> Accept which requirement, exactly? That users should be able to create
> complex cites such as "23 USC 253(a) & 264"?

Should be able to enter that data as is and get useful citations out
the other end. I'm talking about data input here; something not per se
the domain of CSL.

>> > 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.
>>
>> Given this is the key problem now in moving forward with a concrete
>> proposal, can you expand on why you say this is a requirement?
>>
>> Consider how Zotero deals with dates; why not something like that here?
>
> Do you suggest using a dedicated cs:locator rendering element, akin to
> cs:dates? How would that work?

I don't know ATM. I still am not clear on the use cases (and in
particular legal eccentricities).

I also think we need to clarify that this discussion is not about what
we might call "reference locators" (identifiers that locate a
reference source within some larger containing entity), but rather
"point locators" (identifiers that locate a specific fragment of
content within a reference source). Right?

Bruce

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

Re: Improving support for locators

fbennett
On Sun, Jun 10, 2012 at 6:27 AM, Bruce D'Arcus <[hidden email]> wrote:

> On Fri, Jun 8, 2012 at 1:52 PM, Rintze Zelle <[hidden email]> wrote:
>> On Thu, Jun 7, 2012 at 10:31 AM, Bruce D'Arcus <[hidden email]> wrote:
>>>
>>> > The use case shown above (with
>>> > "&") also shows that a strict key/value representation will be too
>>> > limiting.
>>>
>>> But that presumes we all accept the requirement that users should be
>>> able to do that. I don't (but my opinion is just one).
>>
>>
>> Accept which requirement, exactly? That users should be able to create
>> complex cites such as "23 USC 253(a) & 264"?
>
> Should be able to enter that data as is and get useful citations out
> the other end. I'm talking about data input here; something not per se
> the domain of CSL.

Expressed as input in the scheme I described, the locator portion of
the bogus example "23 USC §§ 253(a) & 264" might be broken down like
this:

{
  "section": [
     { "section": "253" }
  ],
  "locator": [
     { "none": "(a) &" },
     { "section": "264" }
   ]
  "
}

Where the "section" variable is drawn from the persistent Item, and
the "locator" variable is drawn from the supplementary item data set
for this citation. As you can see, the "none" locator label has a role
to play when the Item specifier is supplemented in the citation to
refer to a smaller subunit of the target resource.

>
>>> > 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.
>>>
>>> Given this is the key problem now in moving forward with a concrete
>>> proposal, can you expand on why you say this is a requirement?
>>>
>>> Consider how Zotero deals with dates; why not something like that here?
>>
>> Do you suggest using a dedicated cs:locator rendering element, akin to
>> cs:dates? How would that work?
>
> I don't know ATM. I still am not clear on the use cases (and in
> particular legal eccentricities).

As background, Thomas Bruce has a useful series of posts on
legislative identifiers and Linked Data.

  blog.law.cornell.edu/metasausage/2012/05/07/identifiers-part-1/

>
> I also think we need to clarify that this discussion is not about what
> we might call "reference locators" (identifiers that locate a
> reference source within some larger containing entity), but rather
> "point locators" (identifiers that locate a specific fragment of
> content within a reference source). Right?

For statutes and other large documents/archives with a nested
structure, the boundary between the two gets fuzzy.

>
> Bruce
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

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

Re: Improving support for locators

Bruce D'Arcus-3
On Sat, Jun 9, 2012 at 5:55 PM, Frank Bennett <[hidden email]> wrote:

> On Sun, Jun 10, 2012 at 6:27 AM, Bruce D'Arcus <[hidden email]> wrote:
>> On Fri, Jun 8, 2012 at 1:52 PM, Rintze Zelle <[hidden email]> wrote:
>>> On Thu, Jun 7, 2012 at 10:31 AM, Bruce D'Arcus <[hidden email]> wrote:
>>>>
>>>> > The use case shown above (with
>>>> > "&") also shows that a strict key/value representation will be too
>>>> > limiting.
>>>>
>>>> But that presumes we all accept the requirement that users should be
>>>> able to do that. I don't (but my opinion is just one).
>>>
>>>
>>> Accept which requirement, exactly? That users should be able to create
>>> complex cites such as "23 USC 253(a) & 264"?
>>
>> Should be able to enter that data as is and get useful citations out
>> the other end. I'm talking about data input here; something not per se
>> the domain of CSL.
>
> Expressed as input in the scheme I described, the locator portion of
> the bogus example "23 USC §§ 253(a) & 264" might be broken down like
> this:
>
> {
>  "section": [
>     { "section": "253" }
>  ],
>  "locator": [
>     { "none": "(a) &" },
>     { "section": "264" }
>   ]
>  "
> }
>
> Where the "section" variable is drawn from the persistent Item, and
> the "locator" variable is drawn from the supplementary item data set
> for this citation. As you can see, the "none" locator label has a role
> to play when the Item specifier is supplemented in the citation to
> refer to a smaller subunit of the target resource.

But what does this all mean; in particular the "253(a) & 264" bit?

To break it fully down (consider this legal citations for dummies, of
which I am one):

23 = volume (?)
USC = container-title (e.g. it's an abbreviation for the code, which
is a periodical)
§§ = ??
253 = section (of the volume?)
(a) = ?? (is this a subsection of "253", and therefore a point locator?)
& = (what it seems?)
264 = section (also of the volume?)

>>>> > 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.
>>>>
>>>> Given this is the key problem now in moving forward with a concrete
>>>> proposal, can you expand on why you say this is a requirement?
>>>>
>>>> Consider how Zotero deals with dates; why not something like that here?
>>>
>>> Do you suggest using a dedicated cs:locator rendering element, akin to
>>> cs:dates? How would that work?
>>
>> I don't know ATM. I still am not clear on the use cases (and in
>> particular legal eccentricities).
>
> As background, Thomas Bruce has a useful series of posts on
> legislative identifiers and Linked Data.
>
>  blog.law.cornell.edu/metasausage/2012/05/07/identifiers-part-1/
>
>>
>> I also think we need to clarify that this discussion is not about what
>> we might call "reference locators" (identifiers that locate a
>> reference source within some larger containing entity), but rather
>> "point locators" (identifiers that locate a specific fragment of
>> content within a reference source). Right?
>
> For statutes and other large documents/archives with a nested
> structure, the boundary between the two gets fuzzy.

OK. Perhaps the example above can help us understand the fuzziness?

Bruce

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

Re: Improving support for locators

fbennett
On Sun, Jun 10, 2012 at 7:09 AM, Bruce D'Arcus <[hidden email]> wrote:

> On Sat, Jun 9, 2012 at 5:55 PM, Frank Bennett <[hidden email]> wrote:
>> On Sun, Jun 10, 2012 at 6:27 AM, Bruce D'Arcus <[hidden email]> wrote:
>>> On Fri, Jun 8, 2012 at 1:52 PM, Rintze Zelle <[hidden email]> wrote:
>>>> On Thu, Jun 7, 2012 at 10:31 AM, Bruce D'Arcus <[hidden email]> wrote:
>>>>>
>>>>> > The use case shown above (with
>>>>> > "&") also shows that a strict key/value representation will be too
>>>>> > limiting.
>>>>>
>>>>> But that presumes we all accept the requirement that users should be
>>>>> able to do that. I don't (but my opinion is just one).
>>>>
>>>>
>>>> Accept which requirement, exactly? That users should be able to create
>>>> complex cites such as "23 USC 253(a) & 264"?
>>>
>>> Should be able to enter that data as is and get useful citations out
>>> the other end. I'm talking about data input here; something not per se
>>> the domain of CSL.
>>
>> Expressed as input in the scheme I described, the locator portion of
>> the bogus example "23 USC §§ 253(a) & 264" might be broken down like
>> this:
>>
>> {
>>  "section": [
>>     { "section": "253" }
>>  ],
>>  "locator": [
>>     { "none": "(a) &" },
>>     { "section": "264" }
>>   ]
>>  "
>> }
>>
>> Where the "section" variable is drawn from the persistent Item, and
>> the "locator" variable is drawn from the supplementary item data set
>> for this citation. As you can see, the "none" locator label has a role
>> to play when the Item specifier is supplemented in the citation to
>> refer to a smaller subunit of the target resource.
>
> But what does this all mean; in particular the "253(a) & 264" bit?
>
> To break it fully down (consider this legal citations for dummies, of
> which I am one):
>
> 23 = volume (?)
> USC = container-title (e.g. it's an abbreviation for the code, which
> is a periodical)
> §§ = ??
> 253 = section (of the volume?)
> (a) = ?? (is this a subsection of "253", and therefore a point locator?)
> & = (what it seems?)
> 264 = section (also of the volume?)

http://www.law.cornell.edu/citation/2-300.htm

>
>>>>> > 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.
>>>>>
>>>>> Given this is the key problem now in moving forward with a concrete
>>>>> proposal, can you expand on why you say this is a requirement?
>>>>>
>>>>> Consider how Zotero deals with dates; why not something like that here?
>>>>
>>>> Do you suggest using a dedicated cs:locator rendering element, akin to
>>>> cs:dates? How would that work?
>>>
>>> I don't know ATM. I still am not clear on the use cases (and in
>>> particular legal eccentricities).
>>
>> As background, Thomas Bruce has a useful series of posts on
>> legislative identifiers and Linked Data.
>>
>>  blog.law.cornell.edu/metasausage/2012/05/07/identifiers-part-1/
>>
>>>
>>> I also think we need to clarify that this discussion is not about what
>>> we might call "reference locators" (identifiers that locate a
>>> reference source within some larger containing entity), but rather
>>> "point locators" (identifiers that locate a specific fragment of
>>> content within a reference source). Right?
>>
>> For statutes and other large documents/archives with a nested
>> structure, the boundary between the two gets fuzzy.
>
> OK. Perhaps the example above can help us understand the fuzziness?
>
> Bruce
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

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

Re: Improving support for locators

Bruce D'Arcus-3
On Sat, Jun 9, 2012 at 6:19 PM, Frank Bennett <[hidden email]> wrote:
> On Sun, Jun 10, 2012 at 7:09 AM, Bruce D'Arcus <[hidden email]> wrote:

...

>> To break it fully down (consider this legal citations for dummies, of
>> which I am one):
>>
>> 23 = volume (?)
>> USC = container-title (e.g. it's an abbreviation for the code, which
>> is a periodical)
>> §§ = ??
>> 253 = section (of the volume?)
>> (a) = ?? (is this a subsection of "253", and therefore a point locator?)
>> & = (what it seems?)
>> 264 = section (also of the volume?)
>
> http://www.law.cornell.edu/citation/2-300.htm

That's awesome!

But it doesn't completely break it down for me. Am I right to assume that:

$$ = "sections" (plural)

If that's the case, then why isn't the input ...

{  "section": ['253(a)', 264] }

... (where I"m assuming the '(a)' bit is just a subsection of 253)?

Finally, is this a point locator, or a resource locator? Or both?

Bruce

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel