On Sun, Jun 10, 2012 at 6:27 AM, Bruce D'Arcus <[email protected]> wrote:
> On Fri, Jun 8, 2012 at 1:52 PM, Rintze Zelle <[email protected]> wrote:
>> On Thu, Jun 7, 2012 at 10:31 AM, Bruce D'Arcus <[email protected]> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
