from:"Bruce D'Arcus"

Re: [xbiblio-devel] Migrate to Discourse (help requested)

2017-12-07 Thread Bruce D'Arcus

Great; thanks to both of you!

On Wed, Dec 6, 2017 at 12:07 AM Rintze Zelle  wrote:

> Hi all,
>
> Quick updates regarding the mailing list:
>
> * I took Michel up on his offer to help with the migration to
> Discourse. We have the forum up and running at
> https://discourse.citationstyles.org/, but I'm keeping it private
> until we complete the migration.
> * It would make things easier if we don't need to migrate any newer
> emails from after 2017-11-24 to Discourse. Feel free to keep using the
> mailing list until we migrate, but if you want any new emails to
> migrate please wait until we wrap things up (hopefully within the next
> two weeks or so).
> * The migration hit a little snag because SourceForge has in 2017
> started obfuscating email addresses in mailing list mbox archive
> files. Luckily I had a 2015 mbox archive on hand, and I un-obfuscated
> the email addresses for more recent emails by touching up the mbox
> file by hand.
> * I also discovered that the Nabble mirror
> (http://xbiblio-devel.2463403.n2.nabble.com/) had stopped mirroring
> the main list since June 2017, so it's missing some emails (again this
> is because SourceForge changed something). I fixed this last week, but
> if you subscribed through Nabble you likely missed the emails between
> June and November 2017.
> * I also discovered that our Gmane mirror
> (http://dir.gmane.org/gmane.text.xml.xbiblio.devel) has gone offline
> since June 2016 along with the demise of the entire site (see
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ and
> http://home.gmane.org/2016/08/29/next-steps-gmane/).
>
> Best,
>
> Rintze
>
> On Fri, Nov 24, 2017 at 1:00 AM, Michel Krämer 
> wrote:
> > Hi Rintze,
> >
> > I agree with you that we should avoid GitHub-only communication. GitHub
> is for issues for not for general discussion/support/help.
> >
> > I had a look at the install instructions and the import script. Looks
> pretty doable. If you like, I can try to do the migration.
> >
> > Cheers,
> > Michel
> >
> >
> >> On 24. Nov 2017, at 02:19, Rintze Zelle  wrote:
> >>
> >> Hi all,
> >>
> >> I recently came across an offer by Discourse for free hosting for
> >> popular open source projects
> >> (
> https://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/
> ),
> >> and I'm happy to report that we got approved. I think this would be a
> >> very nice replacement for the SourceForge mailing list (and maybe we
> >> can also use it for user support and reduce our reliance on the Zotero
> >> forums). I guess we could also move to GitHub-only communication, but
> >> I think a separate platform like Discourse is still useful for
> >> high-importance/low-volume discussions with a wider audience.
> >>
> >> We should be able to migrate the xbiblio-devel mailing list archive,
> >> but the Discourse folks told me that we can't do the migration on
> >> their hosted copy. However, we could migrate our mailing list content
> >> into a development instance of Discourse, export a Discourse data
> >> backup, and have the Discourse folks apply that to their hosted
> >> instance.
> >>
> >> I was hoping somebody would be willing to assist me with this
> >> migration. I can supply an mbox file for the xbiblio-devel SourceForge
> >> mailing list archive
> >> (
> https://sourceforge.net/p/forge/documentation/Mailing%20List%20Archives/).
> >>
> https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md
> >> has instructions for installing Discourse locally or on a cloud
> >> instance.
> https://meta.discourse.org/t/problem-importing-using-mbox-script/37567
> >> has a discussion of a successful SourceForge mailing list migration.
> >> https://meta.discourse.org/t/howto-import-mbox-mailing-list-files/51233
> >> has general instructions on using the standard mbox import script at
> >>
> https://github.com/discourse/discourse/blob/master/script/import_scripts/mbox.rb
> .
> >>
> >> Best,
> >>
> >> Rintze
> >>
> >>
> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> xbiblio-devel mailing list
> >> xbiblio-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >>
> >
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > xbiblio-devel mailing list
> > xbiblio-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
>
> --
> Check out the vibrant tech

Re: [xbiblio-devel] APA 6th using OWL rather than APA

2017-12-05 Thread Bruce D'Arcus

Seems the thread started with "would be nice to have this feature" but came
to a stopped at "we don't really have a clear idea how to implement it
generally."

So I'd say no ;-)

But did you see bwiernik's note?

On Tue, Dec 5, 2017 at 9:42 AM Joseph Reagle  wrote:

> In the past few years (I asked about this in July 2015) has any progress
> been made on the need for style-specific genre strings?
>
> As I prepare my next book manuscript using
> `chicago-fullnote-bibliography`, I'm wondering if I still have to go in and
> replace the APA-specific genre strings in my bibliographic data?
>
> For example, for APA papers I do below, but these strings also appear when
> I use Chicago, which is obviously wrong.
>
> It'd be great if I didn't have to manually convert my bibliographic data
> every time I switch styles. (For example, in one day I might work on the
> book and an article.)
>
>
> On Jul 27, 2015 10:51 PM, "Joseph Reagle"  wrote:
> > I added a genre field to my YAML data for post-weblog and it did indeed
> > appear in brackets, but it seems odd that I'd have to add APA-specific
> text
> > in the genre field to my generic YAML data.  Doesn't it make more sense
> to
> > have the apa.csl have rules for that? For example:
> >
> >
> > post -> [Online forum comment]
> > post-weblog -> [Web log message]
> > videoRecording -> [Video file]
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> xbiblio-devel mailing list
> xbiblio-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Different and= for narrative and parenthetical citations?

2017-10-06 Thread Bruce D'Arcus

feel free to add notes to the issue(s).

On Fri, Oct 6, 2017 at 12:57 PM Wiernik <xbib...@wiernik.org> wrote:

> The general idea that seems to have emerged from various discussion here
> and on the Zotero forums that styles would need to specify two different
> citation formats. For author-date styles, these would generally take the
> forms: (Author, Date) and Author (Date). For numeric and note styles, these
> would be: [1] and Author [1].
>
> Supporting two formats like this in CSL would be excellent, as it would
> dramatically improve the ability of users to change styles quickly (at the
> moment, changing rules for “and” vs “&”, formatting rules for “et al.”,
> etc. must be manually adjusted for “narrative citations”). As Sebastian
> mentions, this is probably the single most requested feature/complaint from
> Zotero users.
>
> On Oct 6, 2017, 17:15 +0200, xbiblio-devel-requ...@lists.sourceforge.net,
> wrote:
>
> Send xbiblio-devel mailing list submissions to
> xbiblio-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> or, via email, send a message with subject or body 'help' to
> xbiblio-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> xbiblio-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of xbiblio-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Different and= for narrative and parenthetical citations?
> (Bruce D'Arcus)
> 2. Re: Different and= for narrative and parenthetical citations?
> (Sebastian Karcher)
>
>
> ------
>
> Message: 1
> Date: Fri, 06 Oct 2017 15:05:46 +
> From: "Bruce D'Arcus" <bdar...@gmail.com
> To: development discussion for xbiblio
> <xbiblio-devel@lists.sourceforge.net
> Subject: Re: [xbiblio-devel] Different and= for narrative and
> parenthetical citations?
> Message-ID:
> <caf-fpgobcv9v7exveu2ba5gi6yvun_lkrt12enx+eiticns...@mail.gmail.com
> Content-Type: text/plain; charset="utf-8"
>
> I added the broader issue, and linked the two, here:
>
> https://github.com/citation-style-language/schema/issues/141
>
> On Fri, Oct 6, 2017 at 10:57 AM Bruce D'Arcus <bdar...@gmail.com> wrote:
>
> To be clear, I'm not sure we won't fix. It's just a possibility.
>
> This issue is tied into a somewhat complex issue: whether we support the
> feature ("narrative citations"), it needs to maintain a current original
> design goal, which is that an author can switch between note and other
> style types without editing their text.
>
> I couldn't figure out how to reconcile those in the past, but would be
> happy if someone did.
>
> On Fri, Oct 6, 2017 at 10:46 AM Malte Roedl <
> malte.ro...@postgrad.mbs.ac.uk> wrote:
>
> Thanks for your quick reply, Bruce.
>
> I have created a github issue, but I could unfortunately not tag it as
> "wontfix" myself.
>
> https://github.com/citation-style-language/schema/issues/140
>
> In my case, I will probably use latex (biblatex-apa) for this, as the
> journal is very picky about their citations.
>
> In case anyone is interested, another option to solve this is to use
> and="symbol" and use a regex for post-processing.
> This one works:
> "([&])(?=\s+(?:[\w-]+ ){1,3}[(])" -> "and"
> (unless there are punctuation characters in between the ampersand and
> the year, e.g. for first names, or there is random ampersands followed
> by brackets in the text)
>
> On Fri, 2017-10-06 at 10:31 +, Bruce D'Arcus wrote:
>
> CSL has no concept of a "narrative citation," which would explain why
> there's no way to distinguish formatting based on it.
> There's been discussions about it, but am not remembering where we
> ended up.
> If we don't already have it, we should have a general issue ticket on
> GitHub for the broader feature, and include a note about this
> particular detail there.
> Even if we label it "won't fix," at least we have the documentation
> in one place.
>
> On Fri, Oct 6, 2017, 5:44 AM Malte Roedl <malte.ro...@postgrad.mbs.ac
> .uk> wrote:
>
> Hello everyone,
>
> according to the APA style guidelines, which have many adoptions in
> various CSL-styles, it is mandatory to have 'and' connecting
> authors in
> narrative, and '&' connecting authors in parenthetical
> citations[1].
>
> None of the styles I tried were accommodating for this rule.
>
> So then I've tried to build a if-else-contro

Re: [xbiblio-devel] Different and= for narrative and parenthetical citations?

2017-10-06 Thread Bruce D'Arcus

To be clear, I'm not sure we won't fix. It's just a possibility.

This issue is tied into a somewhat complex issue: whether we support the
feature ("narrative citations"), it needs to maintain a current original
design goal, which is that an author can switch between note and other
style types without editing their text.

I couldn't figure out how to reconcile those in the past, but would be
happy if someone did.

On Fri, Oct 6, 2017 at 10:46 AM Malte Roedl <malte.ro...@postgrad.mbs.ac.uk>
wrote:

> Thanks for your quick reply, Bruce.
>
> I have created a github issue, but I could unfortunately not tag it as
> "wontfix" myself.
>
> https://github.com/citation-style-language/schema/issues/140
>
> In my case, I will probably use latex (biblatex-apa) for this, as the
> journal is very picky about their citations.
>
> In case anyone is interested, another option to solve this is to use
> and="symbol" and use a regex for post-processing.
> This one works:
> "([&])(?=\s+(?:[\w-]+ ){1,3}[(])" -> "and"
> (unless there are punctuation characters in between the ampersand and
> the year, e.g. for first names, or there is random ampersands followed
> by brackets in the text)
>
> On Fri, 2017-10-06 at 10:31 +, Bruce D'Arcus wrote:
> > CSL has no concept of a "narrative citation," which would explain why
> > there's no way to distinguish formatting based on it.
> > There's been discussions about it, but am not remembering where we
> > ended up.
> > If we don't already have it, we should have a general issue ticket on
> > GitHub for the broader feature, and include a note about this
> > particular detail there.
> > Even if we label it "won't fix," at least we have the documentation
> > in one place.
> >
> > On Fri, Oct 6, 2017, 5:44 AM Malte Roedl <malte.ro...@postgrad.mbs.ac
> > .uk> wrote:
> > > Hello everyone,
> > >
> > > according to the APA style guidelines, which have many adoptions in
> > > various CSL-styles, it is mandatory to have 'and' connecting
> > > authors in
> > > narrative, and '&' connecting authors in parenthetical
> > > citations[1].
> > >
> > > None of the styles I tried were accommodating for this rule.
> > >
> > > So then I've tried to build a if-else-control structure to identify
> > > whether it is a narrative or a parenthetical citation, but it seems
> > > that the processor would do that automatically by using "prefix"
> > > and
> > > "suffix"?
> > > Is there any way to identify in the csl-file what type of citation
> > > is
> > > calling the evaluation?
> > > Or even better, is there already an existing style that
> > > accommodates
> > > for my issue (I could not find one, but that may be because of very
> > > vague and ubiquitous search terms).
> > >
> > > Many thanks!
> > >Malte
> > >
> > >
> > > [1] e.g. https://en.wikipedia.org/wiki/APA_style#In-text_citations
> > > -
> > > -
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > xbiblio-devel mailing list
> > > xbiblio-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >
> > ---
> > ---
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > xbiblio-devel mailing list
> > xbiblio-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> xbiblio-devel mailing list
> xbiblio-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

[xbiblio-devel] MakeCSL?

2017-06-12 Thread Bruce D'Arcus

Still hoping at some point we end up with an easier style creation wizard.

As I googled for stuff I've done toward this end, I'm realizing this
document is now almost ten years old!

http://www.users.miamioh.edu/darcusb/citations/MakeCSL/makecsl.html

Should we maybe revisit this, and promote it more?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] schema error in nxml mode

2016-09-29 Thread Bruce D'Arcus

I will check.

A bug in nxml is certainly possible. Except James Clark wrote it, and aside
from being widely considered a master programmer,  he's also the author of
relax ng.

On Thu, Sep 29, 2016, 12:01 AM Rintze Zelle <rintze.ze...@gmail.com> wrote:

> I've never used nxml, but Jing (version jing-2009) doesn't report
> any problems for csl.rnc in the "master" branch. Maybe you could test
> whether you can fix the issue by rearranging
>
> include "csl-terms.rnc"
> include "csl-types.rnc"
> include "csl-variables.rnc"
>
> in csl.rnc to
>
> include "csl-variables.rnc"
> include "csl-terms.rnc"
> include "csl-types.rnc"
>
> ? If it does, we can change the order for future versions of CSL. I
> can dig into the RELAX NG spec to see if the "include"-order is ever
> supposed to matter, although
> http://www.relaxng.org/compact-tutorial-20030326.html seems silent on
> the matter. Probably just a bug in nxml.
>
> Rintze
>
> On Mon, Sep 26, 2016 at 10:23 PM, Sebastian Karcher
> <karc...@u.northwestern.edu> wrote:
> > yes, downloaded from github.
> >
> > On Mon, Sep 26, 2016 at 10:17 PM, Bruce D'Arcus <bdar...@gmail.com>
> wrote:
> >>
> >> Hmm ... interesting. Which version? Master?
> >>
> >>
> >> On Sep 26, 2016 9:50 PM, "Sebastian Karcher" <
> karc...@u.northwestern.edu>
> >> wrote:
> >>>
> >>> FWIW I'm using the schema in nxml mode all the time without issues.
> >>>
> >>> On Mon, Sep 26, 2016 at 9:49 PM, Bruce D'Arcus <bdar...@gmail.com>
> wrote:
> >>>>
> >>>> I ended up just combining the schemas into a single file, using trang
> >>>> and jing. It's here if anyone could use it.
> >>>>
> >>>> https://gist.github.com/bdarcus/b196aaff7133de337c70636e0f98ed78
> >>>>
> >>>> On Mon, Sep 26, 2016 at 11:51 AM, Bruce D'Arcus <bdar...@gmail.com>
> >>>> wrote:
> >>>> > Actually, it's flagging the csl.terms.rnc file as the problem.
> >>>> >
> >>>> > Not really sure why, since I'm specifying to validate against
> rnc.csl,
> >>>> > and that includes this file.
> >>>> >
> >>>> > On Mon, Sep 26, 2016 at 11:17 AM, Bruce D'Arcus <bdar...@gmail.com>
> >>>> > wrote:
> >>>> >> ... or maybe not error, but warning.
> >>>> >>
> >>>> >> On Mon, Sep 26, 2016 at 11:07 AM, Bruce D'Arcus <bdar...@gmail.com
> >
> >>>> >> wrote:
> >>>> >>> I'm getting an error about an undefined pattern variable.names
> when
> >>>> >>> trying to use the csl schema in nxml mode.
> >>>> >>>
> >>>> >>> I'm not exactly sure why, unless it's because the pattern is
> >>>> >>> referenced in the file before it's actually defined.
> >>>> >>>
> >>>> >>> Any ideas?
> >>>> >>>
> >>>> >>> I would test this further with the java tools, but my java isn't
> >>>> >>> setup
> >>>> >>> correctly.
> >>>> >>>
> >>>> >>> Bruce
> >>>>
> >>>>
> >>>>
> --
> >>>> ___
> >>>> xbiblio-devel mailing list
> >>>> xbiblio-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sebastian Karcher, PhD
> >>> www.sebastiankarcher.com
> >>>
> >>>
> >>>
> --
> >>>
> >>> ___
> >>> xbiblio-devel mailing list
> >>> xbiblio-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >>>
> >>
> >>
> >>
> --
> >>
> >> ___
> >> xbiblio-devel mailing list
> >> xbiblio-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >>
> >
> >
> >
> > --
> > Sebastian Karcher, PhD
> > www.sebastiankarcher.com
> >
> >
> --
> >
> > ___
> > xbiblio-devel mailing list
> > xbiblio-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >
>
>
> --
> ___
> xbiblio-devel mailing list
> xbiblio-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] schema error in nxml mode

2016-09-26 Thread Bruce D'Arcus

Actually, it's flagging the csl.terms.rnc file as the problem.

Not really sure why, since I'm specifying to validate against rnc.csl,
and that includes this file.

On Mon, Sep 26, 2016 at 11:17 AM, Bruce D'Arcus <bdar...@gmail.com> wrote:
> ... or maybe not error, but warning.
>
> On Mon, Sep 26, 2016 at 11:07 AM, Bruce D'Arcus <bdar...@gmail.com> wrote:
>> I'm getting an error about an undefined pattern variable.names when
>> trying to use the csl schema in nxml mode.
>>
>> I'm not exactly sure why, unless it's because the pattern is
>> referenced in the file before it's actually defined.
>>
>> Any ideas?
>>
>> I would test this further with the java tools, but my java isn't setup
>> correctly.
>>
>> Bruce

--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

[xbiblio-devel] schema error in nxml mode

2016-09-26 Thread Bruce D'Arcus

I'm getting an error about an undefined pattern variable.names when
trying to use the csl schema in nxml mode.

I'm not exactly sure why, unless it's because the pattern is
referenced in the file before it's actually defined.

Any ideas?

I would test this further with the java tools, but my java isn't setup
correctly.

Bruce

--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

[xbiblio-devel] github "mailing list"?

2016-09-25 Thread Bruce D'Arcus

I noticed the spacemacs project takes advantage of what seems to be some
new-ish github feature?

https://github.com/syl20bnr/spacemacs/projects/2#card-227403

Anybody know anything about this, and whether it's worthwhile for CSL?
--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

[xbiblio-devel] Fwd: csl as lisp

2016-09-07 Thread Bruce D'Arcus

Just came across this.

https://github.com/jkitchin/org-ref/tree/master/citeproc

--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] how to specify kindle location?

2016-07-18 Thread Bruce D'Arcus

Problem with ebooks is the don't have fixed pagination (because users can
change fonts and line spacing). In that sense, they're similar to web pages.

On Jul 18, 2016 4:50 PM, "Joseph Reagle"  wrote:

> Any suggestions for best practices on citing a Kindle ebook?
>
> In CSL [1] what kind of locators would you use? line, paragraph, sub verb?
>
> [1]: http://docs.citationstyles.org/en/stable/specification.html
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> ___
> xbiblio-devel mailing list
> xbiblio-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] non-dropping particles

2015-07-23 Thread Bruce D'Arcus

I wonder if a workaround would be to have some toggle switch that would
turn off the parsing for a specific name?

On Thu, Jul 23, 2015 at 11:07 AM, Frank Bennett biercena...@gmail.com
wrote:

 For what it's worth (and it's not a point that I would press hard in
 the face of strong opposition), I'm not a fan of adding fields to the
 UI for particle-purposes. I think it would make manual entry a real
 pain, and code maintenance would not be fun.

 On Fri, Jul 24, 2015 at 12:04 AM, Frank Bennett biercena...@gmail.com
 wrote:
  It could be documented ducks. Or you could have first-run guidance.
  It's a pretty straightforward distinction, easy to remember once
  you're exposed to it once.
 
  Things will be a lot easier to document now that the parsing is driven
  by a proper per-particle specification. The behavior is much more
  well-defined than it was previously.
 
 
  On Thu, Jul 23, 2015 at 11:48 PM, Rintze Zelle rintze.ze...@gmail.com
 wrote:
  How is a regular Zotero user going to discover that that's possible,
 though?
 
  Rintze
 
  On Thu, Jul 23, 2015 at 10:44 AM, Aurimas Vinckevicius
  aurimas@gmail.com wrote:
  Though the dropping particle in Rintze's example can already be defined
  explicitly via first name field, so it doesn't undergo any parsing
 anyway.
 
  On Jul 23, 2015 9:40 AM, Aurimas Vinckevicius aurimas@gmail.com
 
  wrote:
 
  I agree with Rintze about a more explicit UI and that may come in the
  future (probably not for 5.0). I would still like to have automatic
 parsing
  and have that work correctly 99% of the time. The explicit UI would
 only be
  necessary where automatic parsing fails.
 
  On Jul 23, 2015 9:30 AM, Rintze Zelle rintze.ze...@gmail.com
 wrote:
 
  I searched around a bit, and I agree that Jean de La Fontaine might
  not be the best example. Better examples might be Ludwig van
  Beethoven (dropping particle) and Vincent van Gogh (non-dropping
  particle). Then we get:
 
  Display order with demote-non-dropping-particle set to “never” or
  “sort-only”:
  Beethoven, Ludwig van
  van Gogh, Vincent
 
  Display order with demote-non-dropping-particle set to
  “display-and-sort”:
  Beethoven, Ludwig van
  Gogh, Vincent van
 
  As the example above shows, van has an ambiguous particle type and
  we thus cannot rely on automatic parsing of two-field name fields
  (given and family name) like those used in the Zotero UI to identify
  particles and assign them as dropping or non-dropping. The CSL spec
  currently doesn't discuss this type of parsing, since it assumes
 fully
  structured metadata. But it's clear that the particle parsing process
  is by far the most opaque aspect of Zotero/CSL's particle treatment.
  I'm really not a fan of protecting names in double quotation marks. I
  think the best option would be for the Zotero UI to be more explicit
  about particles, e.g. by offering a multi-part name field (given,
  dropping particle, non-dropping particle, family, and suffix).
 
  Rintze
 
  On Thu, Jul 23, 2015 at 6:58 AM, Nick Bart nickbart1...@gmail.com
  wrote:
   This is to proceed with a discussion started on
  
  
 https://forums.zotero.org/discussion/30974/2/any-idea-why-an-a-author-comes-last-in-the-bibliography/
 .
  
   While the CSL schema in its current form seems adequate for dealing
   with
   non-dropping particles in European and Arabic names, I feel some
   aspects of
   interpretation need to be reviewed:
  
   In a nutshell, I argue that “van den”, “al-” and friends are
 genuine
   non-dropping particles, but “La” and possibly a few others are not
 and
   are
   best seen as parts of a single multipart last name (just like
 “Van” in
   Belgian or American names, e.g., “Van Rompuy”).
  
   The following is copied from
  
  
 https://forums.zotero.org/discussion/30974/2/any-idea-why-an-a-author-comes-last-in-the-bibliography/
 :
  
   Certain names start with non-dropping particles, where
 “non-dropping”
   means
   these particles have to appear in in-text citations (“van den
 Keere”,
   “al-Hakim”) but may or may not be dropped in a bibliography for
 sorting
   (“al-Hakim, Tawfiq” [sort under “H”], “van den Keere, Pieter” [sort
   under
   “K”]), or sorting and display (“Hakim, Tawfiq al-”, “Keere, Pieter
 van
   den”).
  
   The Chicago Manual clearly recommends the sort-and-display variant
   (16e:
   8.10, 8.14, 16.71, 16.76); that’s why I would argue that all CSL
   Chicago
   styles should switch to
   `demote-non-dropping-particle=display-and-sort`.
  
   By contrast, any last name that does not function this way, i.e.,
 where
   elements are never removed from the front for purposes of sorting
 or
   display, or in other words, where the last name is always used in
 one
   and
   the same form only throughout a document, both in text and in a
   bibliography, should be parsed as one multipart last name.
  
   For example, I would argue that “La Fontaine” should be understood,
   contra
   the examples given in

[xbiblio-devel] Fwd: EDFT in ISO

2015-06-11 Thread Bruce D'Arcus

Apropos recent discussion.
-- Forwarded message --
From: Denenberg, Ray r...@loc.gov
Date: Jun 11, 2015 4:27 PM
Subject: EDFT in ISO
To: datet...@listserv.loc.gov
Cc:

I am pleased to report that work has begun in earnest to incorporate EDTF
into ISO 8601.  ISO recently approved a work item for an “8601 Part 2”.
(I don’t know if this really means “Version 2”, or if there will actually
be two parts.)  And so a Working Group has been convened, and I have
joined.  Unfortunately I have had to miss the past two calls, when EDTF has
been discussed, but from the minutes, it seems that much of it is being
well-received. This is all very preliminary of course.

I want to bring to your attention several changes that are being
suggested.  These suggestions are tentative as they have not been discussed
yet within the group, just suggested.   But I want feedback from this
group, if anyone objects to any of these suggestions. (Personally, I think
they’re fine.)

· ‘?’ (question mark) currently means “uncertain”, ‘~’ (tilde)
means “approximate, and ‘?~’ means “uncertain as well as approximate”.  The
suggestion is to replace the latter with a single character and the
suggested character is ‘%’ (percent).

· ‘u’ means unspecified, and the suggestion is to change that to
‘!’ (exclamation).

· ‘y’ is used at the beginning of the date string to signify that
the date is a year exceeding four digits. The suggestion is to change this
to ‘Y’ (upper case).

· ‘unknown’ and ‘open’ : the suggestion is to replace these with
single characters, and the suggested characters are ‘*’ and ‘’  (asterisk
and ampersand).

· Numeric values for seasons:

Currently:

   - 21 = Spring
  - 22 = Summer
  - 23 = Autumn/Fall
  - 24 = Winter

  The suggestion is to rename these four,  and expand the list:

· 21 = Spring - Northern Hemisphere

· 22 = Summer - Northern Hemisphere

· 23 = Autumn/Fall - Northern Hemisphere

· 24 = Winter - Northern Hemisphere

· 25 = Spring - Southern Hemisphere

· 26 = Summer - Southern Hemisphere

· 27 = Autumn/Fall - Southern Hemisphere

· 28 = Winter - Southern Hemisphere

· 31-34 for Q1 - Q4 ( 4 periods of 3 months each)

· 41-43 for Quadrimester (3 periods of 4 months each)

· 51-52 for Semestral (2 periods of 6 months each)

The next scheduled call is Tuesday, June 23, so if you have concerns about
these suggestions, please post them before then.

Ray
--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL style formatter

2015-06-09 Thread Bruce D'Arcus

Cool!

But why do we care about element order in the metadata?

I do believe we could construct the RNG to ensure a particular order. It
just doesn't seem a good idea, as order isn't relevant to the content
meaning.
--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Juris-M style module editor

2015-04-27 Thread Bruce D'Arcus

Wow; looks like a lot of work!

Will take a look later, when I have some time ;-)

On Mon, Apr 27, 2015 at 10:05 AM, Frank Bennett biercena...@gmail.com wrote:
 Following our discussion in the Macro condition thread last month, I
 built an editor for the legal style modules I had in mind. The initial
 version just went up at:

 https://juris-m.github.io

 When you enter the style editor area of the site, it will request
 access to your public GitHub repositories, and cast a personal fork of
 the modular styles repo to support pull requests from your account.
 There is a tutorial that explains the modular architecture, and covers
 the basics of module coding. There is also a nice live cite previewer
 in there that might be useful for general style editing as well as the
 modules.

 The site will eventually house a rebranded release of MLZ, which I'll
 probably be plugging away at into the summer break.

 (If there is interest, the GitHub submission code could be modified to
 route CSL 1.0.1 styles to the GitHub repo for review - not sure if
 that would just add confusion, though.)

 Anyway, take a look, comments welcome, hope it proves useful!

 Frank

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Use of Sponsorship Money and Governance

2015-04-12 Thread Bruce D'Arcus

Agreed. I guess the obvious question is what that should look like.
Perhaps something like Rintze suggests, along with a simple governance
document that articulates that all?

On Sun, Apr 12, 2015 at 4:48 PM, Martin Fenner m...@martinfenner.org wrote:
 My two cents as someone only peripherally involved: thinking about some
 level of governance feels like the right direction, as CSL has become an
 essential part of the scholarly infrastructure.

 Best,

 Martin

 Am 12.04.2015 um 22:19 schrieb Sebastian Karcher
 karc...@u.northwestern.edu:

 Hi all,
 this post has two parts: it starts with a suggested budget for the use of
 sponsorship money we have/will receive(d) this year, then some brief more
 general considerations on governance. So if you don't care about the former,
 please scroll down. We have received the money from Springer/Papers and are
 waiting for the check from Elsevier/Mendeley, which should arrive any time.

 This is Rintze and my budget proposal:

 Donations 2014 + $5000
 Rintze - $1962.94
 Sebastian - $1950
 Stickers - $72.96
 - taxes 2014: $1410*
 ---
 - 395.90

 Donations 2015
 $10,000
 
 - 1,200 (d) (Sylvester for submission bot)
 - 3,150 (Rintze, Sebastian, 1,575 each)
 - 400 (d?) (Phillip - proposed)
 - 165 (d) (style manuals)**
 - 396 (deficit 2014)
 - 2460 (est. taxes 2015) (10,000-anything I can tax deduct)*.285
 
 2015 Budgeted surplus: $2,229

 (d) signifies tax deductible for me

 Let me know if anything looks wrong or you have any questions, on or off
 list is fine.
 Three questions in ascending order of generality:

 1. Is everyone OK with this? Suggested changes, objections?
 2. What should we do with the $2,229 currently left? I'd love to support
 Frank's work in some way, so Frank if there's anything we can do--pay for
 server or the like--please let us know. Beyond that, any other ideas? Both
 donations are no-strings-attached, so we can do anything that's useful for
 CSL: Fund travel to conferences/talks or face-to-face meetings, fund/bounty
 additional CSL-related development. Thoughts, ideas?
 3. Rintze and I both feel that some type of governance would make sense now
 that we deal with non-trivial amounts of money. At the same time, time is
 one of our scarcest resources, so we shouldn't do anything that places any
 undue burden on that. Rintze suggested something like this:

 we could create a governing board, whose role is to annually articulate
 short and long-term goals of the CSL project (with community input), and
 make decisions on how these goals can be best achieved with the available
 funds. (...) We could have a poll every year or two for the board positions.


 We could, alternatively, just keep running this entirely through the list
 and on a consensus basis, which has worked pretty well, but I am a little
 worried that we don't have any mechanism in place at all should there be
 some type of conflict.

 Looking forward to hearing people's thoughts, especially on 2 and 3.
 Sebastian


 * a little under 15% each for income and self-employment tax
 ** specifically: CMoS subscription: $60 for 2 years (d)
 Australian Gov't Style Manaual $50 (d)
 Duden Schriftliche Arbeit $15 (d)
 SBL Style Manual 2nd Edition $40 (d)

 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net

Re: [xbiblio-devel] Native support in LibreOffice?

2015-04-06 Thread Bruce D'Arcus

I actually started CSL with that idea in mind, when I co-lead a project to
replace the OOo bib module.

But we had no resources, so nothing much happened.
On Apr 6, 2015 6:05 AM, Matěj Cepl mc...@cepl.eu wrote:

 Hi,

 I know that the official suggestion for the LibreOffice is to
 use Zotero and its extension, but I wonder whether anybody works
 on replacing that horrible native Bibliographic Database in
 LibreOffice/OpenOffice with something based on CSL? I cannot
 find absolutely anything on https://bugs.documentfoundation.org/

 Having Firefox opened just because I want to manage
 bibliographic information seems silly, and also better
 integration would probably allow including MODs/whatever data
 into ODT files for better collaboration with other
 coauthors/reviewers not using Zotero themselves.

 Thanks for any reply,

 Matěj
 --
 http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz
 GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

 Overfiend Don't come crying to me about your 30 minute
 compiles!! I have to build X uphill both ways! In the snow! With
 bare feet! And we didn't have compilers! We had to translate the
 C code to mnemonics OURSELVES!  And I was 18 before we even had
 assemblers!



 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL style submission bot

2015-04-03 Thread Bruce D'Arcus

Nice!
On Apr 3, 2015 11:56 AM, Rintze Zelle rintze.ze...@gmail.com wrote:

 Hi all,

 I mentioned previously that we were contemplating offering Sylvester Keil
 a bounty for development of a bot to parse Travis CI reports of CSL style
 repo pull requests and post back a user-friendly guidance comment (see
 http://xbiblio-devel.2463403.n2.nabble.com/Mendeley-Elsevier-Donation-tp7578731p7579161.html
 ). We just received the necessary funds, and Sylvester will probably have
 time later this month to start the project.

 Let us know if you have any thoughts on the tool's requirements. Issue at
 https://github.com/citation-style-language/utilities/issues/20.

 Rintze


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Proposal: new CSL variable multivolume-title (or similar) rather than volume-title

2015-03-12 Thread Bruce D'Arcus

Just quickly - am not entirely clear on collection vs collective
distinction. Other than one being a noun and the other an adjective, they
seem the same idea. A periodical title, for example, is a collection title
in the CSL logic.
On Mar 12, 2015 1:41 PM, Nick Bart nickbart1...@gmail.com wrote:

 Downsides: fair enough. But the Chicago Manual, 16e, 14.124, actually
 lists two formats, and for the second one – the one I'd favour –, your
 first concern would not apply.

 Pelikan, Jaroslav. *The Christian Tradition: A History of the Development
 of Doctrine.* Vol. 1, *The Emergence of the Catholic Tradition (100–600).*
 Chicago: University of Chicago Press, 1971.
 or
 Pelikan, Jaroslav. *The Emergence of the Catholic Tradition (100–600).*
 Vol. 1 of *The Christian Tradition: A History of the Development of
 Doctrine.* Chicago: University of Chicago Press, 1971.

 What I am worried about most, by contrast, is sorting, and the handling of
 short titles. For one of the Knuth books, e.g.,

 Knuth, Donald E. 1986. *METAFONT: The Program.* Vol. D of *Computers 
 Typesetting*. Reading, Mass.: Addison-Wesley.

 we'd certainly want METAFONT as the short title in notes, and I don't
 really see how to do this without even worse complications in the code if
 we do not use METAFONT: The Program as the title and METAFONT as the
 short title.

 For the British Library's definition of collective-title (An inclusive
 title for an item containing several works or a title used to collocate the
 publications of an author, composer, or corporate body containing several
 works, or extracts etc. from several works, e.g. Complete works.), see
 http://www.bl.uk/bibliographic/ukmarcmanual/ukmarc_glossary.pdf.
 For one example of a library catalogue using title and
 collective-title, see http://gso.gbv.de/DB=2.1/PPNSET?PPN=305817159.

 Finally, on This would always be the hierarchy, from specific to broad?
 – Yes, from a systematic point of view this would be best. This also seems
 to have been the consensus when I asked the MODS mailing list,
 m...@listserv.loc.gov, mostly frequented by librarians, how to best set
 up such title hierarchies in MODS.

 On 12 March 2015 at 14:20, Sebastian Karcher karc...@u.northwestern.edu
 wrote:

 I don't have a clear opinion on this yet, but two downsides that come to
 mind:
 1. It will make introducing this in styles much more code intensive:
 instead of just adding the volume-title to the citation, we'd have to test
 for the presence of volume title and if it exists, reverse the order of
 elements in the style.
 This may not become entirely clear with the Macbeth example, but if you
 look at the CMoS example that motivated this:
 Pelikan, Jaroslav. The Christian Tradition: A History of the Development
 of Doctrine. Vol. 1, The Emergence of the Catholic Tradition (100–600).
 Chicago: University of Chicago Press, 1971.

 The Christian Tradition: A History of the Development of Doctrine would
 now be the collective title
 which leads to

 2. It would require all upstream users to re-enter (rather than
 complement) their data entry (moving the title to volume title).

 I'm particularly concerned about 1. I don't have a strong opinion on this
 either way, but let's at least be aware of that.

 Sebastian


 On Thu, Mar 12, 2015 at 8:30 AM, Rintze Zelle rintze.ze...@gmail.com
 wrote:

 On Thu, Mar 12, 2015 at 9:16 AM, Nick Bart nickbart1...@gmail.com
 wrote:

 and for chapters:

 - `title` (e.g. “Macbeth”)
 - `container-title` (e.g. “Tragedies”)
 - `collective-title` (e.g., “Collected Works”)
 - `collection-title` (e.g., “Oxbridge Classical Texts”)


 This would always be the hierarchy, from specific to broad? Do you have
 any links to library catalog entries on hand, that demonstrate the point?

 Rintze


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




 --
 Sebastian Karcher, PhD
 Department of Political Science
 Northwestern University


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___

Re: [xbiblio-devel] Proposal: new CSL variable multivolume-title (or similar) rather than volume-title

2015-03-12 Thread Bruce D'Arcus

I'm just asking that the distinction be clear.
On Mar 12, 2015 2:07 PM, Sebastian Karcher karc...@u.northwestern.edu
wrote:

 a periodical title is a container-title, at least currently it is.
 As for the distinction, it's the distinction between a multi-volume work
 (the proposed collective-title) and a series (the current
 collection-title), which can and do exist coexist.

 We can argue about naming of the variable, but there are only so many
 words ;).

 On Thu, Mar 12, 2015 at 1:03 PM, Bruce D'Arcus bdar...@gmail.com wrote:

 Just quickly - am not entirely clear on collection vs collective
 distinction. Other than one being a noun and the other an adjective, they
 seem the same idea. A periodical title, for example, is a collection title
 in the CSL logic.
 On Mar 12, 2015 1:41 PM, Nick Bart nickbart1...@gmail.com wrote:

 Downsides: fair enough. But the Chicago Manual, 16e, 14.124, actually
 lists two formats, and for the second one – the one I'd favour –, your
 first concern would not apply.

 Pelikan, Jaroslav. *The Christian Tradition: A History of the
 Development of Doctrine.* Vol. 1, *The Emergence of the Catholic Tradition
 (100–600).* Chicago: University of Chicago Press, 1971.
 or
 Pelikan, Jaroslav. *The Emergence of the Catholic Tradition (100–600).*
 Vol. 1 of *The Christian Tradition: A History of the Development of
 Doctrine.* Chicago: University of Chicago Press, 1971.

 What I am worried about most, by contrast, is sorting, and the handling
 of short titles. For one of the Knuth books, e.g.,

 Knuth, Donald E. 1986. *METAFONT: The Program.* Vol. D of *Computers 
 Typesetting*. Reading, Mass.: Addison-Wesley.

 we'd certainly want METAFONT as the short title in notes, and I don't
 really see how to do this without even worse complications in the code if
 we do not use METAFONT: The Program as the title and METAFONT as the
 short title.

 For the British Library's definition of collective-title (An
 inclusive title for an item containing several works or a title used to
 collocate the publications of an author, composer, or corporate body
 containing several works, or extracts etc. from several works, e.g.
 Complete works.), see
 http://www.bl.uk/bibliographic/ukmarcmanual/ukmarc_glossary.pdf.
 For one example of a library catalogue using title and
 collective-title, see http://gso.gbv.de/DB=2.1/PPNSET?PPN=305817159.

 Finally, on This would always be the hierarchy, from specific to
 broad? – Yes, from a systematic point of view this would be best. This
 also seems to have been the consensus when I asked the MODS mailing list,
 m...@listserv.loc.gov, mostly frequented by librarians, how to best set
 up such title hierarchies in MODS.

 On 12 March 2015 at 14:20, Sebastian Karcher karc...@u.northwestern.edu
  wrote:

 I don't have a clear opinion on this yet, but two downsides that come
 to mind:
 1. It will make introducing this in styles much more code intensive:
 instead of just adding the volume-title to the citation, we'd have to test
 for the presence of volume title and if it exists, reverse the order of
 elements in the style.
 This may not become entirely clear with the Macbeth example, but if you
 look at the CMoS example that motivated this:
 Pelikan, Jaroslav. The Christian Tradition: A History of the
 Development of Doctrine. Vol. 1, The Emergence of the Catholic Tradition
 (100–600). Chicago: University of Chicago Press, 1971.

 The Christian Tradition: A History of the Development of Doctrine
 would now be the collective title
 which leads to

 2. It would require all upstream users to re-enter (rather than
 complement) their data entry (moving the title to volume title).

 I'm particularly concerned about 1. I don't have a strong opinion on
 this either way, but let's at least be aware of that.

 Sebastian


 On Thu, Mar 12, 2015 at 8:30 AM, Rintze Zelle rintze.ze...@gmail.com
 wrote:

 On Thu, Mar 12, 2015 at 9:16 AM, Nick Bart nickbart1...@gmail.com
 wrote:

 and for chapters:

 - `title` (e.g. “Macbeth”)
 - `container-title` (e.g. “Tragedies”)
 - `collective-title` (e.g., “Collected Works”)
 - `collection-title` (e.g., “Oxbridge Classical Texts”)


 This would always be the hierarchy, from specific to broad? Do you
 have any links to library catalog entries on hand, that demonstrate the
 point?

 Rintze


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join
 the
 conversation now. http://goparallel.sourceforge.net/
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




 --
 Sebastian Karcher, PhD
 Department

Re: [xbiblio-devel] Macro condition

2015-03-01 Thread Bruce D'Arcus

On Sun, Mar 1, 2015 at 7:58 PM, Frank Bennett biercena...@gmail.com wrote:
The basic objective of a proposal can typically be stated in a few words:

* To support configurable trigraph styles
* To support composite citation styles
* To support multilingual citations
* To support legal referencing

Given that CSL is a very solid language for the things that it does,
most proposals to change or extend it will be driven by some
compelling project need that cannot be avoided. The first thing a
proposer wants from CSL is a decision on whether the group is
committed to accommodating the basic requirement that he or she is
faced with.

If the ultimate decision on commitment in CSL is conditioned on the
proposer putting forward a roadmap that the group finds satisfactory,
that may be a big risk for them to assume: they will not have a very
strong incentive to engage with the process.

True. Perhaps it could be a staged process?

Bruce

Frank

On Mon, Mar 2, 2015 at 3:09 AM, Bruce D'Arcus bdar...@gmail.com wrote:
Thanks for attempting to move the discussion forward Phillip.

But I don't think these questions actually capture the issues some of
us are raising; they don't really capture the tensions of different
paths. So I'm not going to answer it.

The one thing I agree is worth discussing is medium and form of
communication around these proposals. Towards that end, a Google Doc
of a proposed standardized template for proposals:

https://docs.google.com/document/d/1GTTOl0_Yj9JidrTmOI_pXiKGUqpenFERTP7S4lIBbwo/edit?usp=sharing

Feel free to add comments or suggestions. Note that Google recently
added a suggesting mode that works like standard change-tracking.

Perhaps one way forward generally is to use Google Docs to flesh out a
proposal (ask questions, clarify language, etc.) and only once it's
clear move it to some other place (the issue tracker and/or here?)?

Bruce

On Sun, Mar 1, 2015 at 5:32 AM, Philipp Zumstein zuphi...@gmail.com wrote:
Maybe, it helps to see each others attitude to the general questions raised
here. I put together a poll for that:
https://terminplaner2.dfn.de/foodle/xbiblio-devel-Macro-condition-54f2e?language=en
(I hope that is more comfortable than another 8 emails).

2015-03-01 2:21 GMT+01:00 Frank Bennett biercena...@gmail.com:

On Sun, Mar 1, 2015 at 9:53 AM, Sebastian Karcher
karc...@u.northwestern.edu wrote:
this seems quite unsatisfactory to me. Principally, because it seems
like
Frank ended up throwing up his hands in frustration, which is bad on
multiple levels. Also, because I agree with him that our goal should be
to
incorporate legal support into CSL, and to those of us who have read
through
his blog post or list post (or both) on the topic it's quite clear
that's
not going to happen without some version of modularity and we might as
well
figure out how we want that to work now. (Modularity at a general level
would be nice, but we're doing just OK without--it's really the insane
requirements of legal citations that make this a necessity).

So, maybe we can take another stab at this tomorrow?

(I also wonder more generally how we can make discussion of such
proposals
more efficient and less frustrating for the person proposing them).

It's not necessarily a bad thing, and there is no ill will. To get
legal support going at the desktop level, we'll need to get people
from legal tech circles involved, because they know the style
requirements and will have an incentive to pitch in there. That won't
happen until there is a coherent picture in the client, MLZ/CSL-m
branding is a mess at the moment - it's a clutter of project names and
websites that I made up on the fly while pulling things together. If I
were a user, I would find it all a little off-putting.

Now with the kit all working is probably a good time for me to think
about presentation issues, and get a more comfortable watering-hole
and workflow in place. Nothing will change; there can still be
cross-pollination between projects, I'll keep pulling from Zotero and
CSL, and we can still keep an eye on compatibility. I'll just be
trying to present a more coherent picture to potential users on the
legal side, an let developments there take their natural course.

On Sat, Feb 28, 2015 at 2:57 PM, Frank Bennett biercena...@gmail.com
wrote:

On Sunday, March 1, 2015, Bruce D'Arcus bdar...@gmail.com wrote:

Rintze - the problem we have is this is a thread with like 40
messages,
but still not a lot of clarity.

Not sure how we fix this.

Perhaps it was all just too complicated.

I'll just extend the variant schema.

Thanks to all for time spent on the style selection issue.

-end-of-thread-

On Feb 28, 2015 11:58 AM, Rintze Zelle rintze.ze...@gmail.com
wrote:

@Charles, it would e.g. be relatively simple to convert all our
dependent styles to independent styles when we transfer them

Re: [xbiblio-devel] Macro condition

2015-03-01 Thread Bruce D'Arcus

Thanks for attempting to move the discussion forward Phillip.

But I don't think these questions actually capture the issues some of
us are raising; they don't really capture the tensions of different
paths. So I'm not going to answer it.

The one thing I agree is worth discussing is medium and form of
communication around these proposals. Towards that end, a Google Doc
of a proposed standardized template for proposals:

https://docs.google.com/document/d/1GTTOl0_Yj9JidrTmOI_pXiKGUqpenFERTP7S4lIBbwo/edit?usp=sharing

Feel free to add comments or suggestions. Note that Google recently
added a suggesting mode that works like standard change-tracking.

Bruce

2015-03-01 2:21 GMT+01:00 Frank Bennett biercena...@gmail.com:

So, maybe we can take another stab at this tomorrow?

(I also wonder more generally how we can make discussion of such
proposals
more efficient and less frustrating for the person proposing them).

On Sat, Feb 28, 2015 at 2:57 PM, Frank Bennett biercena...@gmail.com
wrote:

On Sunday, March 1, 2015, Bruce D'Arcus bdar...@gmail.com wrote:

Rintze - the problem we have is this is a thread with like 40
messages,
but still not a lot of clarity.

Not sure how we fix this.

Perhaps it was all just too complicated.

I'll just extend the variant schema.

Thanks to all for time spent on the style selection issue.

-end-of-thread-

On Feb 28, 2015 11:58 AM, Rintze Zelle rintze.ze...@gmail.com
wrote:

@Charles, it would e.g. be relatively simple to convert all our
dependent styles to independent styles when we transfer them to
https://github.com/citation-style-language/styles-distribution. That
would free the CSL software products from having to look up the
parent
styles, but it would complicate contributions to the CSL style
repository, since users would start to modify and submit changes to
those monolithic, formerly dependent styles.

@Bruce, Frank, is there really a need for a general extension
mechanism? I think it would be of limited use if it only covers XML
attributes. And wouldn't an uncontrolled extension mechanism
encourage
forking of CSL? How would we deal with arbitrary style extensions
that
are submitted to the style repository? I would also like to stress
that CSL can already be extended through an extension schema, as we
did for Frank's CSL-m fork
(https://github.com/fbennett/schema/blob/master/csl-mlz.rnc),
although
that of course breaks compatibility with the regular CSL schema.

Rintze

On Sat, Feb 28, 2015 at 9:00 AM, Frank Bennett
biercena...@gmail.com
wrote:
My question is more how

Re: [xbiblio-devel] Macro condition

2015-02-28 Thread Bruce D'Arcus

On Sat, Feb 28, 2015 at 5:43 AM, Frank Bennett biercena...@gmail.com wrote:

...

 Bruce has raised the larger question of whether CSL should concern
 itself with any sort of modularity. I'm firm that basic office-quality
 support for legal materials is impossible to achieve without
 content-driven dynamic loading of modular jurisdiction-specific
 styles. If there is a possibility of getting an extension mechanism in
 place, and of placing validated legal styles in the CSL repository,
 that will be a very good thing. If that possibility is foreclosed,
 there will have to be a permanent fork: what I am trying to accomplish
 in legal circles can't be done without this.

To be clear, I think if you need this requirement addressed, we should
support it.

My question is more how.

So let's say we have two options: a) add the attribute as Frank
proposes to the CSL schema and specification, b) add the ability to
add arbitrary non-CSL attributes to CSL elements (e.g. extension).

In each case, what would the specific proposed schema and (in
particular) spec changes be?

For b, I would say:

Spec


CSL allows arbitrary extension attributes with names prefixed with
extension- (for example, extension-random). Processors may ignore
these attributes.

Schema
===

extension-attribute = attribute extension-* { text } [not sure this is
legal; if not, need to reassess; alternative is to use foreign
namespaces]

[not sure; key question is where the pattern gets allowed]

What about for option a?

Bruce

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Macro condition

2015-02-28 Thread Bruce D'Arcus

Rintze - the problem we have is this is a thread with like 40 messages, but
still not a lot of clarity.

Not sure how we fix this.
On Feb 28, 2015 11:58 AM, Rintze Zelle rintze.ze...@gmail.com wrote:

 @Charles, it would e.g. be relatively simple to convert all our
 dependent styles to independent styles when we transfer them to
 https://github.com/citation-style-language/styles-distribution. That
 would free the CSL software products from having to look up the parent
 styles, but it would complicate contributions to the CSL style
 repository, since users would start to modify and submit changes to
 those monolithic, formerly dependent styles.

 @Bruce, Frank, is there really a need for a general extension
 mechanism? I think it would be of limited use if it only covers XML
 attributes. And wouldn't an uncontrolled extension mechanism encourage
 forking of CSL? How would we deal with arbitrary style extensions that
 are submitted to the style repository? I would also like to stress
 that CSL can already be extended through an extension schema, as we
 did for Frank's CSL-m fork
 (https://github.com/fbennett/schema/blob/master/csl-mlz.rnc), although
 that of course breaks compatibility with the regular CSL schema.

 Rintze

 On Sat, Feb 28, 2015 at 9:00 AM, Frank Bennett biercena...@gmail.com
 wrote:
  My question is more how.
 
  If an extension mechanism is possible, that would be great.


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Macro condition

2015-02-27 Thread Bruce D'Arcus

Yes, that's right. But there's a difference between (I'm not sure what to
call them) back end vs runtime modularity.

It just seems to me if we want to embrace the latter, we probably have a
lot more thinking to do. Frank's mechanism makes certain assumptions about
how he loads modules, for example, that I'm not sure we'd want to
generalize.
On Feb 27, 2015 11:23 AM, Sylvester Keil sylves...@keil.or.at wrote:

 On Fri, 2015-02-27 at 05:14 -0500, Bruce D'Arcus wrote:
  I still think we need to start with first principles: do we really
  want to make CSL modular?
 
  Or do we merely want to make it easy for its most complete and widely
  used implementation to add the benefits of such modularity?

 The main benefit of such modularity would be that it could help with
 style development and maintenance, right? (e.g. by providing a library
 of common macros)

 I was curious to see how many duplicate macros there are currently
 across the official styles, so I wrote a quick script to check for
 macros that have an identical structure. This is just a quick hack, so
 apologies in advance if there are any errors!

 https://gist.github.com/inukshuk/a20c23034c1584252a4a

 In total there are only 44 duplicate macros, so this list does not seem
 to indicate very high demand for macro-reuse across style boundaries.

 Like I said, it's just a quick hack, so please let me know if you spot
 any errors!

 Sylvester



 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Macro condition

2015-02-27 Thread Bruce D'Arcus

Thanks Frank.

I wonder if email is best medium for these more wide-ranging and
complicated topics?
On Feb 27, 2015 5:20 AM, Frank Bennett biercena...@gmail.com wrote:

 On Fri, Feb 27, 2015 at 7:14 PM, Bruce D'Arcus bdar...@gmail.com wrote:
  I still think we need to start with first principles: do we really want
 to
  make CSL modular?
 
  Or do we merely want to make it easy for its most complete and widely
 used
  implementation to add the benefits of such modularity?
 
  Do these benefits only really apply to the legal use case, or are they
  potentially much more general?
 
  How do we imagine this unfolding over next five years vis-à-vis style
  content?
 
  How will it intersect with things like repositories?
 
  My initial answer to first question is no, and that maybe this feature
  should not be core to CSL, but an extension attribute. But this would
 also
  have downsides, and opens up further questions (like, what's our long
 term
  strategy on CSL evolution, extensions, etc.?).

 I'll step aside here, as I have a clear interest that is well known.
 These will be questions for the rest of the group to settle.

 Frank


 
  Bruce
 
 
 
 --
  Dive into the World of Parallel Programming The Go Parallel Website,
  sponsored
  by Intel and developed in partnership with Slashdot Media, is your hub
 for
  all
  things parallel software development, from weekly thought leadership
 blogs
  to
  news, videos, case studies, tutorials and more. Take a look and join the
  conversation now. http://goparallel.sourceforge.net/
  ___
  xbiblio-devel mailing list
  xbiblio-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
 


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Macro condition

2015-02-27 Thread Bruce D'Arcus

I still think we need to start with first principles: do we really want to
make CSL modular?

Or do we merely want to make it easy for its most complete and widely used
implementation to add the benefits of such modularity?

Do these benefits only really apply to the legal use case, or are they
potentially much more general?

How do we imagine this unfolding over next five years vis-à-vis style
content?

How will it intersect with things like repositories?

My initial answer to first question is no, and that maybe this feature
should not be core to CSL, but an extension attribute. But this would also
have downsides, and opens up further questions (like, what's our long term
strategy on CSL evolution, extensions, etc.?).

Bruce
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Macro condition

2015-02-25 Thread Bruce D'Arcus

This is another case I just don't have the time/energy to wrap my head
around fully.

I also agree with others the syntax seems inconsistent with the current
design.

But ... another two, related, questions:

Implementation complexity?

Bigger: the design of CSL has always been premised on monolithic styles.
Why shouldn't we be leery of the potential can of worms this opens up?
 On Feb 25, 2015 8:23 PM, Frank Bennett biercena...@gmail.com wrote:

 Great feedback! Thanks all around. Here are some thoughts and responses:

 Rintze: Implicit suppression with cs:group won't quite work,
 unfortunately, since it's about suppression, not alternative
 rendering. For a specific use case, if the modular style decides that
 a locator does not require a label (for a page, or for a paragraph in
 OSCOLA, which is marked only by braces as [123]), we might want to
 say, Ibid. at [123], whereas if it _does_ supply a label, we might
 want to say Ibid. § 123. If we use cs:group in the modular code, it
 will deliver the label + the locator to the main style, where we will
 have no way of determining if there is a label in there. If we deliver
 the label alone (or not), the failed condition just renders nothing,
 and we lack a means of testing for that.

 Sebastian: A conditional would be possible, but as Aurimas says, a
 straightforward approach to it would require that the macro be
 rendered twice. (Also, it would require six additional lines of CSL
 for each conditional, against zero additional lines for an attribute.)

 Aurimas: _Some_ of the double-rendering burden could be saved by
 running the macro in the condition and then caching the result.
 citeproc-js does some of that already, for name substitution. It gets
 messy, though - and you only save the burden of one phase, the
 generation of the output queue object. Flattening to a string does
 indeed have to happen twice, there's no way around that.

 Phillip: The logic of cs:substitute is significantly different, and it
 would be difficult to repurpose that code for this case. It depends on
 the use of variables in each of the substitution candidates, which may
 not be the case for arbitrary macros. It also suppresses substituted
 variables through the remainder of the cite, which we wouldn't want to
 do for macro alternatives. A similar syntax could be used, with
 separate code under the hood - something like:

 text macro=text-fragment
 substitute
 text macro=other-text-fragment/
 /substitute
 /text

 I don't see an advantage to that, though. In cs:substitute under
 cs:names, the separate node allows us to tweak the parameters that
 control name rendering, but a bare macro doesn't have parameters to
 tweak (apart from affixes, which are easy to control anyway). The
 separate node doesn't seem to contribute much to expressiveness.

 The name alt-macro might not be the best, but all in all I'm still
 liking a simple attribute for this edge case.

 Frank


 On Thu, Feb 26, 2015 at 7:22 AM, Aurimas Vinckevicius
 aurimas@gmail.com wrote:
  The problem with the if test is that you would end up calling the macro
  twice. Once to check it and then to generate the content. Not an issue
 for
  simple macros, but would be unnecessary overhead otherwise. Though
 depending
  on how flexible you want this mechanism to be, there might not be another
  way.
 
  On Wed, Feb 25, 2015 at 4:09 PM, Philipp Zumstein zuphi...@gmail.com
  wrote:
 
  1. I don't like the name alt-macro.
  2. It looks for me like a similar construct as the substitute in the
  names node:
  http://citationstyles.org/downloads/specification.html#substitute
  3. More general a test as Sebastian propose could also work.
  (4. I am somehow missing, why the alternative macro has to be outside
 the
  main macro, maybe more context would help at least me.)
 
  2015-02-25 21:29 GMT+01:00 Sebastian Karcher 
 karc...@u.northwestern.edu:
 
  What Franks wants is
  - if the macro returns a strong -- use the string
  - else, call another macro
  I don't see how the implicit conditional of groups would help here,
 since
  you can't actually test for them?
 
  In a non-modular set-up, there are a number of ways to do this--e.g.
  normally we'd just handle the at in the same macro as the §. But if
 you
  want to modularize that, that's no longer possible.
  Correct me if I'm misunderstanding this, Frank.
 
  On Wed, Feb 25, 2015 at 2:11 PM, Rintze Zelle rintze.ze...@gmail.com
  wrote:
 
  Sorry, I don't follow. Why is this use case not covered by cs:group
  implicitly acts as a conditional: cs:group and its child elements are
  suppressed if a) at least one rendering element in cs:group calls a
  variable (either directly or via a macro), and b) all variables that
  are called are empty.
  (http://citationstyles.org/downloads/specification.html#group)?
  Wouldn't that extend to modular macros?
 
  Rintze
 
  On Tue, Feb 24, 2015 at 8:11 AM, Frank Bennett biercena...@gmail.com
 
  wrote:

Re: [xbiblio-devel] predatory publishers

2015-01-24 Thread Bruce D'Arcus

Agree with others, but the link Sebastian provides includes a link to a
criteria PDF.
On Jan 24, 2015 4:39 PM, Frank Bennett biercena...@gmail.com wrote:

 Excluding predatory publishers from the repo would be good public service,
 but I agree that the policy should be clearly stated on the site. Apart
 from that, no reservations.


 On Sunday, January 25, 2015, Sebastian Karcher karc...@u.northwestern.edu
 wrote:

 This doesn't come up a lot, but we just had a request for such a style,
 so I thought I'd bring it up:
 Rintze and I would like to institute a policy to not accept any styles
 for journals by predatory publishers onto the CSL repository. We'd use the
 list by Jeff Beall as the principal criterion:
 http://scholarlyoa.com/publishers/
 The reasons, I assume, are obvious: we don't want to lend any support
 and/or legitimacy to such publishers.

 Let us know if there are any objections, otherwise we'll adopt this
 policy.

 Thanks!
 Sebastian

 --
 Sebastian Karcher, PhD
 Department of Political Science
 Northwestern University



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Generating formatted Citations for the Web from MODs

2014-12-03 Thread Bruce D'Arcus

To your first question, MODS comes out of the library world, and so is also
a way to bring MARC data into the 21st century. Pretty sure that's why
they're using it.

Also, while MODS is less, shall we say controlled, it's also more
expressive than the alternatives you note.
On Dec 3, 2014 3:13 PM, Nick Bart nickbart1...@gmail.com wrote:

 Matthew,

 I don't know what motivated you or your organization to choose MODS; the
 main problem I see is that MODS is nowhere as standardized as biblatex,
 bibtex (which I would consider to be too limited for serious use though),
 or CSL; so if I were you I'd probably try to use one of these formats for
 my database instead.

 Still, if you must use MODS, some background on citeproc-hs and
 pandoc-citeproc:

 citeproc-hs and pandoc-citeproc incorporate bibutils to first convert all
 bibliography database input formats bibutils recognizes to MODS (with the
 exception of CSL JSON and MODS itself for citeproc-hs, and CSL JSON, CSL
 YAML, bibtex, biblatex, and MODS for pandoc-citeproc).

 Thus, as Andrea Rossato, the citeproc-hs author, has pointed out
 repeatedly, citeproc-hs's MODS parser has been written with the sole aim of
 parsing MODS records generated by bibutils, and nothing else, so depending
 on the MODS flavour you will be using, your mileage may vary considerably.

 Unfortunately, the whatever-to-MODS (bibutils) and MODS-to-CSL JSON
 (citeproc-hs) routines suffered from many bugs, some of which have not been
 fixed to this date (for open bug reports see
 http://sourceforge.net/p/bibutils/discussion/general/ and
 http://code.google.com/p/citeproc-hs/issues).

 pandoc-citeproc inherited the citeproc-hs MODS parser essentially
 unchanged, and since pandoc-citeproc bypasses the MODS-related routines of
 both bibutils and citeproc-hs completely for what appear to be its most
 popular input formats, biblatex and bibtex (CSL JSON or CSL YAML not
 needing conversion anyway), there has never been much demand on the
 pandoc-citeproc forum for fixing MODS-related bugs.

 That being said, if you want to get an idea of whether pandoc-citeproc's
 MODS-to-CSL JSON conversion could work for you, try `pandoc-citeproc
 --bib2json yourbibfile.mods`.

 Best,
 Nick

 On 1 December 2014 at 19:37, Matthew Roth matthew.g.r...@yale.edu wrote:

 Hi List, [NOTE that this is a cross post from the MODS listserv[0]--this
 maybe a better place to post] After careful consideration over the past
 several months our web application has decided to store our citations in
 MODs as opposed to our propriety and often problematic relational
 structure. Great news for sure. We are now able to generate EndNote files,
 RIS files, BibTex files, DC, and MARCXML. With the latter two being less
 desired by our end users. Ideally our board of directors and (more
 importantly) our end users would like to generate formatted HTML citations
 in various formats. For example, the way Google scholar will give the user
 the choice of MLA, ALA, and Chicago. The problem looks to be that while
 there are several leads, no available resource exists for a proper HTML
 transformation. The most promising one is the citeproc project and the
 Citation Style Language[1]. They have projects in various stages in
 multiple languages. However, of the list I am only able to function in
 java, python, and JavaScript. The problem to me is that most expect a JSON
 format that is not too well documented--as best as I can tell, some of the
 discussions I've come across on this format our several years old at this
 point. Only one purports to work with MODs. citeproc-hs[2] a haskell
 library seems to have once expected MODs, but 1. I am not familiar with
 haskell and two it appears to not have been kept to date. I have not ruled
 it out completely, but need to consult a primer on haskell first. The
 python library, citeproc-py[3] claims to work with bibtex. However, they
 are still having issues with UTF-8[4]. Additionally, either the mapping is
 off in their BibTex parser or bibutils[5] is producing poor BibTex files
 from the inputted MODs files. Finally, the library according to the
 README.rst[6] is still not ready for production. Ideally, there would be an
 Xquery/XSL transformation that we could call from our web application which
 is built upon exist-db[7]. I suppose our next step may be writing our own
 transformation, however, it seems like coming to this as a programmer and
 not a librarian I may not be searching in all the right places. Do I need
 to write my own transformation, or has the wheel already been created? Best,
 Matt

 PS I apologize if I have misrepresented anything about CSL and the
 various citeproc projects. I am still only a couple weeks old to this
 project.
 [0]http://listserv.loc.gov/cgi-bin/wa?A1=ind1412L=mods [1]
 http://citationstyles.org/ [2]
 https://hackage.haskell.org/package/citeproc-hs [3]
 https://github.com/brechtm/citeproc-py [4]
 https://github.com/brechtm/citeproc-py/issues/25 [5]

Re: [xbiblio-devel] On-the-fly processing of author list to render one (me) bold?

2014-11-05 Thread Bruce D'Arcus

FWIW, I manually format my CV.
--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Mendeley/Elsevier Donation

2014-10-14 Thread Bruce D'Arcus

Perhaps it's time to take up a more general, rigorous, forward-looking,
analysis of the CSL metadata model, as expressed in the JSON schema and CSL
variable matching? That way, different projects could propose
changes/enhancements based on their needs, but we have a process to resolve
them.

Bruce

PS - I'm fine with the funds proposal too.

On Tue, Oct 14, 2014 at 12:39 PM, Robert Knight robert.kni...@mendeley.com
wrote:

 Hi Rintze, Sebastian,

 Thank-you once again for your continued work on the project. Your
 proposal sounds good to me and
 I think you're best placed to judge how to use it.

  While development of
  CSL has been quiet before the flurry of activity we expect once Zotero
  starts revisiting its metadata model,

 Is there any background info on this that you would recommend reading?
 If changes to Zotero's model filter down to CSL then it will likely
 affect Mendeley as well and future interoperability
 between documents authored with plugins from one tool or the other.

 Regards,
 Rob.

 On 14 October 2014 17:15, Rintze Zelle rintze.ze...@gmail.com wrote:
  Dear all,
 
  Sebastian and I were informed that Elsevier/Mendeley wishes to support
  the CSL project again this year with another $5000 donation, for which
  we are very grateful.
 
  In separate news, we've been pursuing membership to the Software
  Freedom Conservancy (https://sfconservancy.org/). This would allow us
  to receive tax-deductible donations, in exchange for a 10% cut of any
  donations received. They seem legit, and offer some legal support and
  liability protection as well (see
  https://sfconservancy.org/members/services/). However, since it might
  be a few months before we're accepted as a member (if at all), it's
  probably best to keep the same arrangement as before, where Sebastian
  accepts the donation as a private person, and distributes the funds
  that remain after taxes.
 
  As for use of the funds, we think there should be two goals.
 
  First, to reimburse people who either incurred personal expenses
  related to CSL (like the purchase of style guides), and to reward
  those who recently volunteered considerable effort in developing and
  maintaining the project (excluding those paid through other means).
  Project roles are largely the same as last year. While development of
  CSL has been quiet before the flurry of activity we expect once Zotero
  starts revisiting its metadata model, Sebastian and I have again put
  in a reasonable amount of work in maintaining the style and locale
  repositories. In recent months Philipp Zumstein
  (https://github.com/zuphilip) has been kind enough to lend a hand as
  well. In the past year, I also created
  http://validator.citationstyles.org/ and worked on documentation. Let
  me know if I have missed any other significant volunteer
  contributions.
 
  Second, to fund future projects. We contacted Sylvester Keil, who
  previously helped us for free to set up our Travis-CI testing
  framework. He is willing to develop a validation bot for $1000 (+VAT),
  which Sebastian and I find very reasonable. This would allow him to
  dedicate two full weeks to this project (we’re getting a steep
  discount on his usual rate). Such a bot would automatically generate a
  human-readable validation report for every pull request and any
  subsequent commits. This would save us a lot of work and quickly
  provide users with detailed feedback on their style/locale submissions
  (see https://github.com/citation-style-language/styles/issues/1088).
 
  Other bounties could e.g. focus on improving the CSL visual editor. We
  could also spend on marketing CSL, and e.g. pay for attendance fees
  and travel costs to conferences where we can showcase CSL (Carles once
  proposed FOSDEM, https://fosdem.org/2015/). Or we could pay for travel
  costs to allow CSL developers to meet in person, especially if they
  already happen to be in each other's area.
 
  We currently don't have any significant recurring expenses, since most
  of our infrastructure is either available for free (GitHub,
  validator.nu, Read the Docs) or sponsored by Zotero (hosting
  http://citationstyles.org/ and running
  https://github.com/citation-style-language/distribution-updater) and
  Mendeley (hosting http://editor.citationstyles.org/).
 
  Last year's donation of $5000 was effectively split between Sebastian
  and myself in two shares of $2000 after taxes. Our proposal for this
  year is to reserve approximately $1200 as a bounty for Sylvester Keil,
  and support myself and Sebastian with circa $1250 each. We also
  suggest a $200 reward for Philipp, but he still has to check with his
  employer whether he can accept one. We might make some adjustments to
  Sebastian's and my payout based on Sebastian exact tax burden, and we
  might save some money for future expenses. We would also renew the
  offer to pay for Frank’s server expenses related to MLZ/CSL-m. His
  side project is a significant boon to CSL

Re: [xbiblio-devel] Custom CSL validator

2014-08-12 Thread Bruce D'Arcus

Awesome!

One little suggestion based on a glance (will look closer later): somehow
indicate which schema version is current.

Bruce
On Aug 11, 2014 11:36 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

 Hi all,

 I managed to create a custom front-end for Validator.nu, currently
 available at http://rintze.zelle.me/csl-validator/. The code lives at
 https://github.com/rmzelle/csl-validator/. My original post, in which
 I outlined the design, moved to
 http://rintze.zelle.me/csl-validator-frontend/.

 It works pretty well in my hands, and has several advantages:

 - the CSL schema version can now be easily selected via a drop-down menu
 - the necessary options for validator.nu are preselected and hidden,
 reducing user confusion and visual clutter
 - irrelevant validation warnings are now hidden
 - validation now includes the extracted Schematron schema rules from
 the CSL 1.0/1.0.1 schema, which catches calls to undefined macros

 I used the Validator.nu REST API
 (http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface),
 Bootstrap, JQuery and Prism (for syntax highlighting).

 If everybody is happy with it, I would eventually like to move the
 code to the citation-style-language GitHub organization, and make it
 available at validator.citationstyles.org.

 The only drawback I'm aware off are two layout/CSS issues with the
 Prism library, documented at
 https://github.com/LeaVerou/prism/issues/324 . If anyone has any ideas
 how to solve them, or knows of a better syntax highlighter that
 supports both line numbering and line highlighting, please let me
 know.

 Rintze

 P.S. The last webpage I hand-coded was after I read a book on HTML 3.2
 in the late nineties. Things sure have become more interesting in the
 past decade or two.

 On Sun, Feb 23, 2014 at 7:18 PM, Rintze Zelle rintze.ze...@gmail.com
 wrote:
  Hi all,
 
  Currently on my wishlist is a customized front-end for Validator.nu.
  I'm aware that Simon built a custom CSL validator a while back (
  http://simonster.github.io/csl-validator.js/ ), but I like the
  interface and flexibility of Validator.nu (and the Jing XML validator)
  a little better. However, there are a lot of presets and validation
  warnings that could be hidden from our users. Since Validator.nu has a
  RESTful API, I'm imagining a custom front-end shouldn't be too hard to
  develop.
 
  Since I'm rather worthless when it comes to coding, I wrote up my
  thoughts at http://rintze.zelle.me/csl-validator/ (along with a
  mockup), and put up a call for help on the citationstyles.org
  frontpage. If anybody here is interested in this side project, let me
  know.
 
  Rintze


 --
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Custom CSL validator

2014-08-12 Thread Bruce D'Arcus

OK, few more comments after trying the validator:

   1. the address term on the pop-up is confusing; maybe better as link?
   2. my example had only one error, which makes this incorrect: Oops, I
   found 1 errors. Maybe change last word in template to error(s)?

And just a question: does this include a web server aspect? If yes, I say
we move it to the main site, per your suggestion.


On Tue, Aug 12, 2014 at 6:53 AM, Bruce D'Arcus bdar...@gmail.com wrote:

 Awesome!

 One little suggestion based on a glance (will look closer later): somehow
 indicate which schema version is current.

 Bruce
 On Aug 11, 2014 11:36 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

 Hi all,

 I managed to create a custom front-end for Validator.nu, currently
 available at http://rintze.zelle.me/csl-validator/. The code lives at
 https://github.com/rmzelle/csl-validator/. My original post, in which
 I outlined the design, moved to
 http://rintze.zelle.me/csl-validator-frontend/.

 It works pretty well in my hands, and has several advantages:

 - the CSL schema version can now be easily selected via a drop-down menu
 - the necessary options for validator.nu are preselected and hidden,
 reducing user confusion and visual clutter
 - irrelevant validation warnings are now hidden
 - validation now includes the extracted Schematron schema rules from
 the CSL 1.0/1.0.1 schema, which catches calls to undefined macros

 I used the Validator.nu REST API
 (http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface),
 Bootstrap, JQuery and Prism (for syntax highlighting).

 If everybody is happy with it, I would eventually like to move the
 code to the citation-style-language GitHub organization, and make it
 available at validator.citationstyles.org.

 The only drawback I'm aware off are two layout/CSS issues with the
 Prism library, documented at
 https://github.com/LeaVerou/prism/issues/324 . If anyone has any ideas
 how to solve them, or knows of a better syntax highlighter that
 supports both line numbering and line highlighting, please let me
 know.

 Rintze

 P.S. The last webpage I hand-coded was after I read a book on HTML 3.2
 in the late nineties. Things sure have become more interesting in the
 past decade or two.

 On Sun, Feb 23, 2014 at 7:18 PM, Rintze Zelle rintze.ze...@gmail.com
 wrote:
  Hi all,
 
  Currently on my wishlist is a customized front-end for Validator.nu.
  I'm aware that Simon built a custom CSL validator a while back (
  http://simonster.github.io/csl-validator.js/ ), but I like the
  interface and flexibility of Validator.nu (and the Jing XML validator)
  a little better. However, there are a lot of presets and validation
  warnings that could be hidden from our users. Since Validator.nu has a
  RESTful API, I'm imagining a custom front-end shouldn't be too hard to
  develop.
 
  Since I'm rather worthless when it comes to coding, I wrote up my
  thoughts at http://rintze.zelle.me/csl-validator/ (along with a
  mockup), and put up a call for help on the citationstyles.org
  frontpage. If anybody here is interested in this side project, let me
  know.
 
  Rintze


 --
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Expanding Page Range Formats

2014-08-06 Thread Bruce D'Arcus

I don't see a problem with adding new algorithms. That's the whole point
behind that feature.

It would be another issue if we had, say, 20 of them. But we only have a
handful?
On Aug 6, 2014 3:29 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

 On Mon, Aug 4, 2014 at 11:24 AM, Andrew Dunning andunn...@gmail.com
 wrote:
  I’m wondering whether the next version of CSL could provide expanded
 support
  for page range formats.

  I’m sure that one could find some other strange circumstances; there is
  probably some question of how thorough CSL should be with this.

 I'm a bit hesitant to keep adding more and more page range formats.

  Additionally, could the concept of page ranges within CSL be expanded to
  number ranges in general? I can’t think of any reason, for instance, why
 one
  wouldn’t want the style’s number range format to apply to a date range as
  well, and there are some odd cases where it would be applicable to a
 volume,
  issue, or series number range.

 My gut feeling is that it's better to have separate definitions of
 range formatting for dates and all other numbers, so that they can be
 configured separately. Volume, issue, and series number ranges don't
 come up very often (in practice and in citation manuals), so we
 haven't really thought about whether the page-range-format should
 affect them.

 Rintze


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] interviews?

2014-08-05 Thread Bruce D'Arcus

It's been a long time, but we've previously discussed interviews. Alas, I
can't remember where! Anyone?
On Aug 5, 2014 2:05 PM, Joseph Reagle joseph.2...@reagle.org wrote:

 What kind of entry data and data fields are necessary to represent
 interviews such as:

   https://owl.english.purdue.edu/owl/resource/717/07/


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Embedding citation-specific metadata in PDF files

2014-07-13 Thread Bruce D'Arcus

You could do option 5: use bibo?

http://bibliontology.com/


On Wed, Jun 25, 2014 at 1:17 PM, johnmie miesc...@bizdata.com wrote:

 digi-libris Reader http://digi-libris.com   can export all Metadata of
 an
 object including CSL-specific variables (those that cannot be mapped 1:1 to
 Dublin Core Terms. e.g. pageRange, event, genre etc.) as XMP sidecar file
 which can be imported into PDF files (with Acrobat.exe) and which other
 software might be able to read.

 Until now we have stored these CSL variables as attribute/value pairs under
 custom entries which appear in Acrobat.exe under /File  Properties 
 Additional Metadata  Advanced/ and are stored in the XMP file as

 /rdf:Description rdf:about= xmlns:pdfx=http://ns.adobe.com/pdfx/1.3/;
 pdfx:citation_pageRange7-9/pdfx:citation_pageRange
 /rdf:Description/

 I am now considering changing this to include a proper CSL namespace which
 could look line
 /
 rdf:Description rdf:about= xmlns:cs=http://purl.org/net/xbiblio/csl/;
 cs:pageRange7-9/cs:pageRange
 /rdf:Description/

 but unfortunately this URL returns a 404 error or automatically re-directs
 you to http://citationstyles.org. No way to see a list of variables.

 What do you recommend:

1 stay with pdfx
2 change to xbiblio even though the latter does not reveal a valid
 namespace
3 register a new domain with purl.org (under purl.org/digi/csl/ or
 similar)
4 as nbr 3 above but use a proprietary prefix (e.g. digicita: or
 similar)
 ?




 --
 View this message in context:
 http://xbiblio-devel.2463403.n2.nabble.com/Embedding-citation-specific-metadata-in-PDF-files-tp7579100.html
 Sent from the xbiblio-devel mailing list archive at Nabble.com.


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck#174;
Code Sight#153; - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Disambiguation in note styles

2014-06-12 Thread Bruce D'Arcus

I get confused by long messages ;-)

Can we start with big picture? Please confirm the following:

1) this question is driven by the idiosyncrasies of supra referencing?*

2) CSL doesn't currently support supra referencing, and so this is an
extension in MLZ?

If both are true, perhaps you should go with your suggestion (which seems
reasonable), see how it works, and use that experience to suggest possible
additions or changes to CSL proper?

Bruce

* I do know this is an important feature, but man I hate it; not only is it
a PITA to implement, it's hostile to readers (me!). One additional wrinkle
here related to both: what's the scope for back referencing in 600 page
book? The book? The chapter? The page? Do you need to allow this to be
configured? If yes, how would you even implement it. ;-)
On Jun 11, 2014 8:31 PM, Frank Bennett biercena...@gmail.com wrote:

A note on some fresh developments in citeproc-js land that affect the CSL
test suite.

In response to feedback on the MLZ Bluebook style, I put in some work in
citeproc-js to get backreference glosses working. The form implemented for
Bluebook support looks like this:

Smith, His Very Long Book Title (2000) [hereinafter Smith, His Book]

The tricky bits are that (a) the gloss should be applied only if there are
subsequent back-references; and (b) the note number should be included for
disambiguation purposes. A test that captures the behaviour is here:

https://bitbucket.org/bdarcus/citeproc-test/src/737afd7171005f9d53cf221f8a71f21007d10386/processor-tests/humans/disambiguate_BasedOnSubsequentFormWithBackref2.txt

A question for the list is whether first-reference-note-number should
always be included for disambiguation purposes, or whether it should be
discretionary. In the current implementation, it is included only if
givenname-disambiguation-rule=by-cite (the default). When another rule is
used, the cite to Roe in the test fixture linked above would have the
gloss, and the backreference would show the title.

While the name of givenname-disambiguation-rule suggests that it affects
only given names, the general effect of the by-cite rule is to make
citations as compact as possible; and dropping the gloss where is is not
strictly necessary has that effect.

While testing the implementation, I found it necessary, in styles that use
disambiguate=true, to force a rerun of disambiguation for first
references that are moved in the document, together with all
back-references that point to it, to assure that the document reflects the
actual disambiguation state of each reference in the set. This change in
behaviour affected three tests in the test suite:

https://bitbucket.org/bdarcus/citeproc-test/commits/737afd7171005f9d53cf221f8a71f21007d10386

Finally, to control the appearance of the gloss on first references, I had
to introduce a test condition (which I've added to the CSL-m schema) that
returns true only if there are subsequent references to the item:

https://github.com/fbennett/schema/commit/6881c98ae752e106b9c62673c5aa42d743fc0c7b

A condition that tests for subsequent back-references is needed to
implement back-reference glosses, regardless of whether note numbers are
included for disambiguation purposes.

Frank

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] How to define in-text CSL format for HTML citations?

2014-06-12 Thread Bruce D'Arcus

Maybe one of those days, but I'm not following this discussion at all.

Can you just describe what you're trying to do, and we can talk about
possible solutions and workarounds?
On Jun 12, 2014 12:00 PM, Christoph Bersch use...@bersch.net wrote:


 Zitat von Sebastian Karcher karc...@u.northwestern.edu:

  The solution provided by Sebastian doesn't work, because it is invalid
  XML (using prefix=a href=').
  This is mainly a technical discussion list for an XML based format, so
  I assume people know how to escape XML. See e.g.
  http://www.freeformatter.com/xml-escape.html

 I know how to escape XML, but not how escaping in this specific case
 would solve the problem, i.e. get a valid br/ tag after processing.
 Using e.g. citeproc-node with something like suffix=lt;br/gt; for
 testing, gives me #60;br/#62;, which is a verbatim br/ and not a
 line break, what one would need.

 Christoph



 --
 HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
 Find What Matters Most in Your Big Data with HPCC Systems
 Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
 Leverages Graph Analysis for Fast Processing  Easy Data Exploration
 http://p.sf.net/sfu/hpccsystems
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] How to define in-text CSL format for HTML citations?

2014-05-27 Thread Bruce D'Arcus

What Sebastian said. CSL is agnostic about output format, and it's up to
implementations to sort out these details.
On May 27, 2014 2:47 PM, Sebastian Karcher karc...@u.northwestern.edu
wrote:

 My tendency would be for CSL to stay out of the styling/linking
 issue and leave that to individual implementations (in other words,
 citeproc-hs or citerproc-js etc could accept flags for hyperlinking
 citations etc.) The main reason would be that otherwise we'd have to
 start duplicating styles with various styling implementations and that
 sounds like a nightmare.

 That said, for your particular issue:
 I'm not sure what you're suggesting makes sense - the layout is for an
 entire citation, which can contain multiple item, each of which can
 have a URL, so you wouldn't want the URL in the layout field or rather
 - which one would you want?). But you could, of course, easily do
 something like
 layout prefix=( suffix=) delimiter=; 
 group prefix=a href=' suffix=/a
 text variable=URL suffix='
 text variable=title/
 text macro=author/
 /group
 /layout

 with proper escaping, obviously.

 On Tue, May 27, 2014 at 12:09 PM, Carl Boettiger cboet...@gmail.com
 wrote:
  Hi List,
 
  I posted this question (text below) as a Github issue on the CSL pages
 and
  Rintze suggested I post it to this list as well.
 
  I would like to define a CSL file in which the in-text format includes a
  link to the resource. Can this be done in CSL by say, modifying the
 layout
  element appropriately?  I cannot figure out how to use a variable in the
  prefix/suffix.
 
  I imagine a `citation` element looking something like this:
 
  layout prefix=(a href='URL' suffix=/a) delimiter=; 
text macro=author-short/
text macro=issued prefix= /
  /layout
 
 
  but cannot see how to get URL value from something like `text
 macro=url`
  into the prefix.
 
 
  Given the importance of web-based formats and the ease of using CSL to
  generate citations in markdown and html documents with tools such as
 pandoc,
  it seems natural that individuals would want to style in-text citations
 not
  only to reflect journal norms of author surnames etc, but include such
  features as actual links, perhaps add `title` attributes for mouse-over
  effects, and so forth.  If this is not possible in the current
  implementation, is this something CSL might address in the future?
 
  I imagine that a flexible implementation of this could further be used to
  add semantic data to inline citations, e.g.
 
  a rel=cito:UsesMethodIn
  href=http://doi.org/10.1186/2041-1480-1-S1-S6;Shotton (2010)a/
 
  Can any of this be done using the current schema?  If not, is this a
  reasonable thing to work towards or should it be left to some other tool?
 
 
  Thanks,
 
  Carl
 
  --
  Carl Boettiger
  UC Santa Cruz
  http://carlboettiger.info/
 
 
 --
  The best possible search technologies are now affordable for all
 companies.
  Download your FREE open source Enterprise Search Engine today!
  Our experts will assist you in its installation for $59/mo, no
 commitment.
  Test it for FREE on our Cloud platform anytime!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk
  ___
  xbiblio-devel mailing list
  xbiblio-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
 



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


 --
 The best possible search technologies are now affordable for all companies.
 Download your FREE open source Enterprise Search Engine today!
 Our experts will assist you in its installation for $59/mo, no commitment.
 Test it for FREE on our Cloud platform anytime!

 http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Parsing bibliographies / style predictor

2014-05-18 Thread Bruce D'Arcus

Cool!

So does this get us one step closer to the magic style finder and generator?

Bruce
On May 17, 2014 4:07 PM, Sylvester Keil sylves...@keil.or.at wrote:

 Dear all,

 I've recently completed a long-term project of mine by writing a web
 application that exposes the AnyStyle parser library for ML-powered
 parsing of bibliographies. The web application (and API) is available at
 http://anystyle.io (SSL available too) and is very exciting (if I may
 say so myself) for mainly two reasons:

 1. The parsing process is split into two steps, showing you the output
 of the ML-driven step in an editor that allows you to make changes to
 the parse result.

 2. These changes can be recorded and used directly to train the ML
 model.

 This is exciting, because so far it required a lot of effort and
 know-how to prepare training data. Now there is a single public model
 that everyone can help improve. Obviously, this part is still very
 experimental — it will be interesting to see if the model starts to
 deteriorate at some point if fed too much training data. Meanwhile, we
 now have a publicly available parser that should be fairly easy to train
 to recognize, for example new styles or languages. Please do take a look
 if you're interested! I imagine most of you will be interested in the
 'CiteProc' output format (the 'JSON' format is less interesting, because
 it does not apply as much post-processing to individual fields).

 The parser is also accessible via a JSON API; I wrote a very quick
 prototype for a style-predictor (Rintze's idea!) similar to the one in
 the CSL editor. You can give the predictor a reference, the reference
 will be parsed and the parsed result rendered in all independent CSL
 styles; these formatted references are then compared with the original
 one using the Levenshtein distance and the best matches reported. It's
 just a quick prototype; you can take a look at it here:

 https://gist.github.com/inukshuk/f1d47aeab1f778bca8ce

 The parsing is very fast, but the rendering using citeproc-ruby takes
 quite some time :) But since the parsing API is so simple, it should be
 very easy to recast this example in JavaScript, Haskell or Python.

 I thought this might be of interest to some of you on this list. Just
 let me know if you have any questions!

 Sylvester




 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform
 available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Switch from http to https prefix for CSL style ID and self-links

2014-04-11 Thread Bruce D'Arcus

Yeah, I was going to make that point. Seems really odd to change IDs just
to accommodate some security change.
On Apr 11, 2014 11:11 AM, Charles Parnot charles.par...@gmail.com wrote:

Hi Rintze,

Just to be sure: are the current style going to be changed? If all the IDs
are changed, that would be quite a mess for Papers, as the id is used to...
uniquely identify the style ;-)

Sorry I don’t show up much on the mailing list anymore, just busy with
http://findingsapp.com

Thanks,

Charles

On Apr 10, 2014, at 6:35 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

Hi all,

It looks like the entire zotero.org domain (recently?) switched to
serving everything over HTTPS. We just had our first CSL style
submission that uses https in the style's template-link,
self-link, and style ID, which made our Travis CI tests fail:
https://github.com/citation-style-language/styles/pull/910

We probably want to accept styles that use either http or https as
the URL prefix for the style ID and self, independent-parent, and
template links, and I'm planning to adjust the Travis tests to allow
for this. I'm mentioning this to give people a heads-up of the change,
in case the use of the https prefix breaks anybody's code.

Rintze

PS. we could also use this change as a reason to start hosting all CSL
styles under the citationstyles.org domain, e.g. via
repository.citationstyles.org/apa.csl, as discussed at

http://xbiblio-devel.2463403.n2.nabble.com/call-for-comments-on-base-URI-issue-td6097469.html#a6174119
, which is long-standing item on my wish list.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Charles Parnot
charles.par...@gmail.com
http://app.net/cparnot
twitter: @cparnot

Your Lab Notebook, Reinvented.
http://findingsapp.com

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Multiple publication dates in citations

2014-02-13 Thread Bruce D'Arcus

On Thu, Feb 13, 2014 at 10:45 AM, Gregory Jordan gjugg...@gmail.com wrote:

 Unless the goal is to expand the CSL data spec into a general-purpose 
 metadata format beyond the scope of citation formatting (which is a whole 
 other can of worms), a good question to ask when thinking about adding new 
 variables might be could this reasonably be used by any existing or 
 forthcoming styles?

That absolutely is always our question.

Bruce

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Markup in titles

2014-02-12 Thread Bruce D'Arcus

Not to mention there's broad unicode support.

On Wed, Feb 12, 2014 at 12:28 PM, Maloney, Christopher (NIH/NLM/NCBI)
[C] malon...@ncbi.nlm.nih.gov wrote:
 Yes, I'm aware of the tradeoffs, and the motivation for doing things this 
 way:  mainly so as not to force users to enter every ampersand as amp; and 
 every less-than sign as lt;.

 But I'm also aware of how tricky things can get when you invent your own 
 markup format that looks a lot like html, but isn't.  And I know that a lot 
 of other devs aren't aware of these issues, so I thought I'd mention them.

 From my testing, it looks like citeproc-json does a really good job.


 Chris Maloney
 NIH/NLM/NCBI (Contractor)
 Building 45, 5AN.24D-22
 301-594-2842


 -Original Message-
 From: Bruce D'Arcus [mailto:bdar...@gmail.com]
 Sent: Wednesday, February 12, 2014 12:23 PM
 To: development discussion for xbiblio
 Subject: Re: [xbiblio-devel] Markup in titles

 As you might guess, there are some tricky trade-offs here. We're trying to be
 practical.

 On Wed, Feb 12, 2014 at 12:00 PM, Maloney, Christopher (NIH/NLM/NCBI)
 [C] malon...@ncbi.nlm.nih.gov wrote:
  Great, thanks!
 
 
 
  Chris Maloney
 
  NIH/NLM/NCBI (Contractor)
 
  Building 45, 5AN.24D-22
 
  301-594-2842
 
 
 
  From: Sebastian Karcher [mailto:karc...@u.northwestern.edu]
  Sent: Wednesday, February 12, 2014 11:48 AM
 
 
  To: development discussion for xbiblio
  Subject: Re: [xbiblio-devel] Markup in titles
 
 
 
  and yes to this:
  So, it looks like this is a pseudo-HTML format, that only supports
  the limited set of tags, and no character entity references, right
 
  citeproc-js handles these individually, it doesn't run a html parser
  or anything like that.
 
 
 
  On Wed, Feb 12, 2014 at 9:46 AM, Sebastian Karcher
  karc...@u.northwestern.edu wrote:
 
 
 
  So, it looks like this is a pseudo-HTML format, that only supports the
  limited set of tags, and no character entity references, right?  Is
  this the complete set of elements: i, b, sup, sub, and span?
 
  citeproc-js also accepts sc for legacy reasons, though we advise
  against using it.
 
 
 
 
 
 
 
  But it means (as I guess you all are probably aware) that there are
  certain strings that cannot appear in one of these fields.  For
  example, if I wanted to talk about the literal string “ij/i” in my
  abstract, I don’t think there’s any way it could be represented, is there?
 
  It has never come up, but you can use backslash to escape html tags, i.e.
  \ij\/i renders as ij/i. You can escape backslashes with
  double backslashes. This isn't heavily tested and I don't know to what
  degree escaping via backslash is officially supported, but it works
  if you need it.
 
 
 
 
 
 
 
 
 
  Chris Maloney
 
  NIH/NLM/NCBI (Contractor)
 
  Building 45, 5AN.24D-22
 
  301-594-2842
 
 
 
  From: Sebastian Karcher [mailto:karc...@u.northwestern.edu]
  Sent: Wednesday, February 12, 2014 10:17 AM
  To: development discussion for xbiblio
  Subject: Re: [xbiblio-devel] Markup in titles
 
 
 
  citeproc-js - and hence CSL JSON - accept html markup for subscript,
  superscript, italics, bold, and small caps:
 
  These: http://www.zotero.org/support/kb/rich_text_bibliography
 
  get passed on literally to citeproch, i.e. your example should ideally 
  have:
  title: Solutions of a Lagrangian system on Tsup2/sup,
 
  which is, I see, what's already in the XML output from PMC. I'll look
  at implementing that on the Zotero import side.
 
 
 
  On Wed, Feb 12, 2014 at 7:58 AM, Maloney, Christopher (NIH/NLM/NCBI)
  [C] malon...@ncbi.nlm.nih.gov wrote:
 
  Is there any allowance in the citeproc-json format or in any of the
  tools to deal with articles that have markup in titles?  For example,
  here is an article with a sup element in the title,
  http://www.ncbi.nlm.nih.gov/pmc/articles/PMC26831/.
 
  I suspect that the markup is just dropped, but wanted to double check.
  Has it been discussed before?  I searched the mailing list archives,
  with no luck.
 
 
  Chris Maloney
  NIH/NLM/NCBI (Contractor)
  Building 45, 5AN.24D-22
  301-594-2842
 
 
 
  --
  
  Android apps run on BlackBerry 10
  Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
  Now with support for Jelly Bean, Bluetooth, Mapview and more.
  Get your Android app in front of a whole new audience.  Start now.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.
  clktrk ___
  xbiblio-devel mailing list
  xbiblio-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
 
 
 
 
  --
  Sebastian Karcher
  Ph.D. Candidate
  Department of Political Science
  Northwestern University
 
 
  --
  
  Android apps run on BlackBerry 10
  Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
  Now with support

Re: [xbiblio-devel] Mendeley/Elsevier Donation

2014-01-07 Thread Bruce D'Arcus

Awesome!

On the PRs, a minor thing: my role in CSL was a bit more active (and
time-intensive) than merely conceiving it. I conceived the idea, yes
(though building on other previous work by others), but I also designed the
complete schema, built the first complete implementation, etc.

Simon and I rewrote that initial version, and the rest is history.

Maybe better to say conceived and initially developed or some such?


On Tue, Jan 7, 2014 at 5:01 PM, Sebastian Karcher 
karc...@u.northwestern.edu wrote:

 Dear all,
 happy new year! Just in time for the new year, we finally received the
 Elsevier donation. It went straight to my account and I'll have to pay
 taxes on it as an independent contractor. So far, I've done the
 following (consulting with Rintze, of course):
 Ordered Rintze equipment valued $1962.94
 Ordered 250 6*2 vinyl stickers with the CSL inverted logo:
 http://flachware.github.io/logo/assets/rgb/%C2%ABCSL%C2%BB-inverse.svg
 for $72.96
 Offered Frank money for his server, given what he has written I expect
 to send him ~$200 to cover three years of server costs (haven't heard
 back from him yet)
 Used $1950 for myself.
 I expect to spend some money on sending the stickers to whoever is
 interested.
 That leaves ~$800, which I'm going to save for taxes. If they end up
 being more than that, Rintze and I will split the difference, if it's
 less I'll let you know and we can decide what to do with the money.

 Stickers: Anyone who wants some pretty CSL stickers, please send me an
 e-mail with your mailing address and the number you want. I'm happy to
 send individual stickers or reasonably large quantities - I doubt
 we'll run out quickly.

 PR together with Mendeley. Rintze and I have been working with Alice
 from Mendeley on posts for ours and the CSL blog, I have attached .txt
 files for the version that Mendeley is going to post and the one we
 expect to put on the CSL blog. We're looking at posting them in a week
 or two.

 Please let us know if there are any concerns and don't forget those
 stickers. They're blue. And pretty.
 Sebastian


 On Sun, Sep 22, 2013 at 10:43 PM, Rintze Zelle rintze.ze...@gmail.com
 wrote:
  Dear all,
 
  As most of you know, Sebastian and I have been doing most of the
  maintenance of the CSL styles and locales repositories for quite some
  time now. In particular dealing with style submissions by new
  contributors can be time-consuming (although the automatic testing
  with Travis CI helps a lot), and the number of submissions has been
  increasing steadily over time. The work has become rather repetitive
  as well.
 
  About a month ago I contacted Victor Henning of Mendeley/Elsevier, and
  asked him whether Mendeley could support Sebastian and me in our task,
  either by reducing our workload or by providing some more motivation
  for our volunteer work (I might have mentioned my 2008 workhorse
  laptop is getting a tad slow). A few days ago Victor very generously
  offered to make a $5000 donation to us two with no strings attached.
 
  Sebastian and I quickly agreed that we should use the sum for a
  broader goal: to keep CSL sustainable. In part, this requires that we
  keep our volunteers engaged, since the CSL project largely runs on
  volunteers: in addition to me and Sebastian, there is of course Frank
  Bennett (citeproc-js, CSL development, citeproc test suite), Sylvester
  Keil (Travis CI), Carles Pina and Charles Parnot (dependent styles),
  and Bruce D'Arcus (creator of CSL, CSL development). We could also use
  some of the funds for bounties, or to pay for infrastructure costs
  (e.g. if we want to do some of our own hosting).
 
  We realize figuring out a fair distribution of funds can be tricky. On
  the one hand, we would like to reward people for past contributions.
  On the other hand, we want to use the donation to make CSL even
  better. Perhaps it is best if volunteers speak up for themselves:
  would a donation help your motivation to work on CSL? Have you
  incurred, or are you planning to incur any CSL-related expenses?
  Personally, for example, if I could use these funds for a new laptop,
  I'd be more motivated to stick around in my current roles.
 
  On the logistical side: no money has changed hands yet. Sean Takats
  mentioned that the Corporation for Digital Scholarship might be able
  to act as the middleman, but I haven't heard from him recently. And
  once the donation is made, and we have figured out the destination of
  the funds, we and Mendeley would like to make a public announcement
  (likely a blogpost at Mendeley and a supporter badge on
  citationstyles.org).
 
  Best,
 
  Rintze and Sebastian
 
  P.S. feel free to contact Sebastian or me in private to discuss things.
 
 
 --
  LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
  1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
  2013, SQL

Re: [xbiblio-devel] CSL Style to convert to JATS XML

2013-12-29 Thread Bruce D'Arcus

This.

I think this job is for processors; not the CSL styles.

Along these lines, I once had an idea to create simple JSON maps,
modeled loosely on bibutils C source, to configure output formatting.
Alas, I never got very far, but it's probably viable.

https://github.com/bdarcus/bibmaps

On Sun, Dec 29, 2013 at 5:25 AM, Michel Krämer mic...@undercouch.de wrote:
 Also, converting to CSL JSON would be quite cool. I tried to write a
 style for that but didn't get very far.

 However, in my opinion, changing the specification just to support these
 cases may be counter-productive. It's always the same with
 specifications: people often try to make them as generic as possible in
 order to support a wide range of applications. But then they become too
 complex and are not adopted anymore, which finally means their end. I
 suggest to focus on what CSL is really meant for instead. Converting
 between different formats should be left to tools such as bibutils.

 Just my two cents. Though, as I said, I would find it cool if I could
 export JSON from every reference manager supporting CSL, but that's
 different story :-)

 Cheers,
 Michel


 Am 27.12.2013 12:24, schrieb Charles Parnot:

 I am currently using this style with citeproc-hs (and noted some small 
 inconsistencies with the CSL processing of this style). I’m not sure 
 whether there is enough general interest to use CSL to produce 
 machine-readable output to change the specification. I personally think it 
 is a useful direction as these machine-readable outputs become increasingly 
 important (and CSL could play a role in this), but I’m sure not everyone 
 agrees as it increases the scope.

 While not a main goal of CSL, I find this idea very interesting, and I agree 
 that it would be nice to make sure that reasonable hooks are in place for 
 that purpose. I think it is already quite good at it, and things like JATS 
 or BibTeX are good examples of the kind of things that should be possible 
 (and make for good test cases for the different processors out there ;-)

 Charles


 --
 Charles Parnot
 charles.par...@gmail.com
 http://app.net/cparnot
 twitter: @cparnot


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Separate distribution repo for CSL styles

2013-12-27 Thread Bruce D'Arcus

On Charles' suggestion, I think this has cone up before, but the script
could auto-insert the correct update value.
On Dec 27, 2013 7:29 AM, Rintze Zelle rintze.ze...@gmail.com wrote:

On Friday, December 27, 2013, Charles Parnot wrote:

I can’t help but notice that the only reason for proposing this extra
repo and script is to fix the issue with the ‘updated’ field.

As I wrote, there are two small additional benefits.
* we would only update the second repo when the Travis tests pass. We do
most things via pull request nowadays, but sometimes we still break a few
styles when committing directly to the master branch and not running the
tests locally (although we could just be more careful and not fail the
tests, of course).
* the script doesn't copy over the files related to Travis testing, which
makes the second repo a bit cleaner.

I agree this needs to be fixed and enforced. One other option, then,
would be to make that part of the **validation** itself: comparing the
modification date of the file with the value of the updated field.

But this would require us to demand that contributors provide correct
timestamps, right? That seems really burdensome. The timestamp needs to be
correct with more than day precision, since we not infrequently want to
push multiple updates on a day. And the ISO format isn't the most
approachable to newcomers, especially when dealing with time zones.

In pull requests, we often ask contributors to make some changes. If we
require correct timestamps, they will have to correct the timestamp
multiple times.

I understand why you'd like to avoid a second repo, but I like the
set-and-forget nature of what Carles put together.

Rintze

On Dec 27, 2013, at 4:15 AM, Rintze Zelle rintze.ze...@gmail.com wrote:

I guess the options for storing the timestamp-corrected styles are:

1) different repo
2) same repo, different branch
3) same branch

The problem with using the same repo is that we get double commits in
the repo whenever we make a change, which makes the styles repo
harder to navigate. The problem with using the same branch is that
writing back the updated timestamp changes the file, which would
trigger another timestamp update, ad infinitum, unless you screen
against that.

Rintze

On Thu, Dec 26, 2013 at 10:08 PM, Bruce D'Arcus bdar...@gmail.com
wrote:
Just a question: why a different repo?

On Dec 26, 2013 6:54 PM, Rintze Zelle rintze.ze...@gmail.com
wrote:

Hi all,

One of the outstanding issues with the CSL styles repository is that
the timestamps in cs:updated are often not up-to-date (see

http://xbiblio-devel.2463403.n2.nabble.com/new-zotero-styles-page-td6363622.html
and https://github.com/citation-style-language/schema/issues/50 for
previous discussion). But Zotero for instance needs correct timestamps
so that style auto-updating works properly. They currently update
timestamps themselves for the Zotero Style Repository using a webhook
to the styles repo (see

https://github.com/zotero/styles-repo/blob/e0f07ea38eae76eaae05219e6e85175a67325f08/scripts/generate-index#L220
).

Obviously, it would be preferable if the CSL project could offer its
styles directly with correct timestamps. Carles Pina was kind enough
to follow up on a suggestion of mine to create a dedicated
distribution repo, and has just finished building a working
prototype. It consists of a Python script, currently run on his
private server
(
https://github.com/citation-style-language/utilities/blob/master/styles-distribution.py
),
and a secondary repository (currently
https://github.com/cpina/styles-distribution, but this would move to
citation-style-language/styles-distribution).

Carles's script listens to a Travis CI webhook. The
styles-distribution repo only gets updated after Travis CI clears a
commit made to the styles repo. No more broken styles in the
styles-distribution repo! The script also removes some of the Travis
CI files that clutter up the original styles repo. It's pretty
speedy too. A commit to the styles repo made it to the
styles-distribution repo in 7 minutes, which includes 6 min of
Travis CI testing:

https://github.com/citation-style-language/styles/commit/96fed1362d6e08c456802a5a8a800c8f6f85f1b6
https://travis-ci.org/citation-style-language/styles/builds/16013811

https://github.com/cpina/styles-distribution/commit/24adeeb1681a1885e0b18917c40403a2240ca758

Charles Parnot
charles.par...@gmail.com
http://app.net/cparnot
twitter: @cparnot

http

Re: [xbiblio-devel] Separate distribution repo for CSL styles

2013-12-26 Thread Bruce D'Arcus

Just a question: why a different repo?
On Dec 26, 2013 6:54 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

Hi all,

One of the outstanding issues with the CSL styles repository is that
the timestamps in cs:updated are often not up-to-date (see

https://github.com/zotero/styles-repo/blob/e0f07ea38eae76eaae05219e6e85175a67325f08/scripts/generate-index#L220
).

Obviously, it would be preferable if the CSL project could offer its
styles directly with correct timestamps. Carles Pina was kind enough
to follow up on a suggestion of mine to create a dedicated
distribution repo, and has just finished building a working
prototype. It consists of a Python script, currently run on his
private server (
https://github.com/citation-style-language/utilities/blob/master/styles-distribution.py
),
and a secondary repository (currently
https://github.com/cpina/styles-distribution, but this would move to
citation-style-language/styles-distribution).

https://github.com/citation-style-language/styles/commit/96fed1362d6e08c456802a5a8a800c8f6f85f1b6
https://travis-ci.org/citation-style-language/styles/builds/16013811

https://github.com/cpina/styles-distribution/commit/24adeeb1681a1885e0b18917c40403a2240ca758

With this setup, we can keep using the styles repo in the exact same
way. The only change is that Zotero, Mendeley, etc. should pull their
styles from the styles-distribution repo.

There are some things that have to be decided:

- Is everybody on board? Please speak up if you see problems with this
solution.
- Somebody will have to host the script. I think it makes most sense
if Dan Stillman of Zotero can take care of this. Dan, how do you feel
about this?
- Any preferences on a name for the repo? I'm fine with
styles-distribution.

Best,

Rintze

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL Style to convert to JATS XML

2013-12-13 Thread Bruce D'Arcus

Hi Martin,

If I understand right, this is effectively formatted citations wrapped in
metadata elements?

If yes, I would point out this is the same type of case as earlier
discussions about RDFa output. I think the solution is not in styles, but
in formatting engines outputting HTML with enough structure that it can be
easily converted to other, related, formats.

Bruce
On Dec 13, 2013 6:56 AM, Martin Fenner mfen...@plos.org wrote:

 Dear list,

 although it seems obvious that someone must have thought about using CSL
 to format citations for the JATS XML, I can’t find information about this
 topic. Specifically I am using pandoc-citeproc with Pandoc and have created
 the pandoc-jats [1] writer to generate JATS XML. I would like to generate
 JATS element-citation elements [2].

 Has there been any work on something like this? Would it be a reasonable
 approach to generate a CSL style that outputs JATS -conformant XML? I am
 currently not interested in the opposite direction, going from JATS XML to
 Citeproc.

 [1] https://github.com/mfenner/pandoc-jats
 [2]
 http://www.ncbi.nlm.nih.gov/pmc/pmcdoc/tagging-guidelines/article/dobs.html#dob-refs

 Best,

 Martin


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Question about types for online news sites

2013-12-06 Thread Bruce D'Arcus

I actually disagree on the first suggestion.

Yes, it's a webpage, but those items are published in a serial manner, much
like a periodical. The post type was designed for just that, where it's
unclear if it's a more specific subtype.


On Fri, Dec 6, 2013 at 1:53 PM, Sebastian Karcher 
karc...@u.northwestern.edu wrote:

 I would treat them as webpage, though it's always a bit of a judgment
 call. My second choice would be article-magazine. (one criterium I use is
 e.g. the existence of an ISSN - Slate, e.g. has one, so I treat it as a
 Magazine, Ars Technica doesn't, so I'd put it in the webpage category). I
 disagree with Bruce on post, not least because that's not really been
 taken up by any of the major implementers and so will be a fallback in
 every single existing citation style.


 On Fri, Dec 6, 2013 at 11:12 AM, Joseph Reagle joseph.2...@reagle.orgwrote:


 In the CSL scheme, would sites like Ars Technica and the Verge be
 considered more of a webpage, post-weblog, or article-newspaper?


 --
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!

 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




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


 --
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!

 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] title casing skip words

2013-11-20 Thread Bruce D'Arcus

On Wed, Nov 20, 2013 at 6:42 PM, Frank Bennett biercena...@gmail.com wrote:



 The nocase form has the effect of squiggly braces in BibTeX (as I
 understand it): it prevents changes to the case of the enclosed text
 when title case or text case are applied to the field. The idea was
 (and I guess I would say is) to use a markup syntax that can be easily
 represented in a UI without additional levels of external parsing by
 the client.

That's right. Not only represented, though, but also easily UI-ified
(think, say, a client like zotero with a context menu that allows one
to select how to treat particular sub-field text).

Any discussion of changes to this particular solution should probably
consider the goals, too.

Bruce

 As far as I know the syntax isn't supported in the UI of
 any clients out there, though, and it hasn't seen much use for the
 obvious-enough reason that it's quite an awkward thing to type, and
 distracting when displayed verbatim.

 It should be a simple thing to add a spec line to the parser that
 applies the same methods to squiggly-brace-enclosed text. Backslash
 escaping should just work, without additional coding.

 in citeproc-js, mixing plain text and html approaches isn't
 particularly a problem, but smooth operation with other tools might
 require greater consistency. It would be good to have input from other
 processor developers and consumers of CSL; and in the interest of data
 exchange, it would be good to have a description of preferred markup
 set in an adjunct to the CSL specification before making further
 changes.


 
  On Fri, Nov 15, 2013 at 4:13pm, Aurimas Vinckevicius wrote:
 
 Clearly, string formatting (mostly in titles) is necessary and is getting
 implemented whether CSL specifies it or not. IMO HTML (or XML, which would
 probably be more work for everyone) is the most elegant and broadly
  supported
 approach.
 
 If CSL really wants to remain format-agnostic in this regard, then it could
  just
 specify that substrings can be marked (with possible nesting) for various
 formatting (italics, superscript, forced title-casing, etc.) and leave the
  language
 of the formatting up to the citeproc developers. CSL can then go on to
  specify
 how such substrings are handled when producing citations.
 
  On Thu, Nov 14, 2013 at 9:52 PM, Bruce D'Arcus [hidden email] wrote:
 
  I haven't looked at this issue, but putting html in json files feels
  really wrong as a general proposition.
 
  On Thu, Nov 14, 2013 at 10:02 PM, Rintze Zelle [hidden email] wrote:
   So far the CSL spec is rather format-agnostic when it comes to input.
   It's
   one of the reasons why citeproc-js's support for inline rich text
   formatting
   of titles (http://www.zotero.org/support/kb/rich_text_bibliography)
   isn't
   included in the spec.
  
   I see the use of what you're proposing, but it is rather HTML-oriented.
   Are
   we comfortable including something like this in the spec, or would it be
   better to have a separate (sub)document that focuses on CSL input (which
   could also be used to describe the CSL JSON data model)?
  
   Rintze
 
  --
  Shape the Mobile Experience: Free Subscription
  Software experts and developers: Be at the forefront of tech innovation.
  Intel(R) Software Adrenaline delivers strategic insight and game-changing
  conversations that shape the rapidly evolving mobile landscape. Sign up now.
  http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
  ___
  xbiblio-devel mailing list
  xbiblio-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
 

 --
 Shape the Mobile Experience: Free Subscription
 Software experts and developers: Be at the forefront of tech innovation.
 Intel(R) Software Adrenaline delivers strategic insight and game-changing
 conversations that shape the rapidly evolving mobile landscape. Sign up now.
 http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] French particles

2013-11-06 Thread Bruce D'Arcus

Isn't that a Zotero name parsing issue; not a CSL design issue?

On Wed, Nov 6, 2013 at 8:40 PM, Frank Bennett biercena...@gmail.com wrote:
 There has been another comment on name particles, for French:

 https://forums.zotero.org/discussion/33082/french-name-particles/#Item_1

 I'm not sure how discriminate treatment of lowercase and uppercase particles
 aligns with the schema. If the list can provide guidance, it would be great:
 if the CSL position is that we should always treat uppercase particles as
 part of the name, I can set that up; if the schema doesn't cover it, and
 French specifically requires it, I guess it will need to be specified.


 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Is there an equiv of biblatex:pagination in CSL?

2013-10-07 Thread Bruce D'Arcus

Would help for you to summarize what that variable means in biblatex.

On Mon, Oct 7, 2013 at 5:47 PM, Joseph Reagle joseph.2...@reagle.org wrote:


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Mendeley/Elsevier Donation

2013-09-23 Thread Bruce D'Arcus

Sean - so what do you suggest on our end?

a) we forget about any relationship with CDS, and figure it out
ourselves (which we don't have the expertise to do, I'd say)

b) you check into if there is some feasible relationship with CDS here
(you say you're not clear; am not clear how literally to take that)

c) something else

On Mon, Sep 23, 2013 at 12:37 PM, Sean Takats stak...@gmu.edu wrote:
 I see a number of issues here on the CSL and Omeka side. On the CSL side of
 things, I would say that Sebastian, Rintze, et al should come to some kind
 of a priori agreement as to what constitutes a sponsorship. Should there be
 tiers? Is it on an annual basis? Is it pegged in some way to for-profit, not
 for profit? What about in-kind contributions? Whatever the resolution, the
 CSL authors should be in the driver seat.

 The role for CDS is murkier. Right now we do handle payment processing for
 the Zotero training that Sebastian conducts. But that's essentially
 fee-for-service, as is the case for all of CDS's money matters (primarily
 Zotero and Omeka storage). This is something different, and it's not clear
 how CDS can or should proceed.

 Sean


 Bruce D'Arcus wrote:

 Consensus here makes sense, with at least $4000 of it split between
 Rintze and Sebastian (maybe with whatever remainder set aside for
 things like Frank pointed out?).

 But thinking more broadly, I guess, being on the CDS board, I'm
 wondering about the logistics point you note. It'd be good to get that
 sorted out ahead of time, since I could imagine in the future more
 funds that need a better plan (might, for example, support travel to
 conferences, etc.?).

 Bruce

 On Mon, Sep 23, 2013 at 12:43 AM, Rintze Zelle rintze.ze...@gmail.com
 wrote:

 Dear all,

 As most of you know, Sebastian and I have been doing most of the
 maintenance of the CSL styles and locales repositories for quite some
 time now. In particular dealing with style submissions by new
 contributors can be time-consuming (although the automatic testing
 with Travis CI helps a lot), and the number of submissions has been
 increasing steadily over time. The work has become rather repetitive
 as well.

 About a month ago I contacted Victor Henning of Mendeley/Elsevier, and
 asked him whether Mendeley could support Sebastian and me in our task,
 either by reducing our workload or by providing some more motivation
 for our volunteer work (I might have mentioned my 2008 workhorse
 laptop is getting a tad slow). A few days ago Victor very generously
 offered to make a $5000 donation to us two with no strings attached.

 Sebastian and I quickly agreed that we should use the sum for a
 broader goal: to keep CSL sustainable. In part, this requires that we
 keep our volunteers engaged, since the CSL project largely runs on
 volunteers: in addition to me and Sebastian, there is of course Frank
 Bennett (citeproc-js, CSL development, citeproc test suite), Sylvester
 Keil (Travis CI), Carles Pina and Charles Parnot (dependent styles),
 and Bruce D'Arcus (creator of CSL, CSL development). We could also use
 some of the funds for bounties, or to pay for infrastructure costs
 (e.g. if we want to do some of our own hosting).

 We realize figuring out a fair distribution of funds can be tricky. On
 the one hand, we would like to reward people for past contributions.
 On the other hand, we want to use the donation to make CSL even
 better. Perhaps it is best if volunteers speak up for themselves:
 would a donation help your motivation to work on CSL? Have you
 incurred, or are you planning to incur any CSL-related expenses?
 Personally, for example, if I could use these funds for a new laptop,
 I'd be more motivated to stick around in my current roles.

 On the logistical side: no money has changed hands yet. Sean Takats
 mentioned that the Corporation for Digital Scholarship might be able
 to act as the middleman, but I haven't heard from him recently. And
 once the donation is made, and we have figured out the destination of
 the funds, we and Mendeley would like to make a public announcement
 (likely a blogpost at Mendeley and a supporter badge on
 citationstyles.org).

 Best,

 Rintze and Sebastian

 P.S. feel free to contact Sebastian or me in private to discuss things.

 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

 --
 LIMITED TIME SALE

Re: [xbiblio-devel] CSL editor update

2013-09-13 Thread Bruce D'Arcus

Thanks Steve!

Anyone here willing to take over the editor project? If not, any
thoughts on how to find someone?

On Fri, Sep 13, 2013 at 8:58 AM, Steve Ridout steverid...@gmail.com wrote:
 I've just updated some of the CSL editor dependencies to their latest
 versions:

 - locales
 - styles
 - citeproc-js

 There a few other minor changes too and the updated version is live at
 http://editor.citationstyles.org. Please keep an eye out for any unintended
 breakages and let me know via github issues.

 Steve

 PS: I'm still hoping that someone else will take over responsibility for
 future maintenance and development of the editor. I'm no longer in academia,
 and no longer create reference manager software, so it would be great to see
 it evolve in the hands of someone more suitable. I'm very willing to help
 out if anyone needs help finding their way around the code, assuming I can
 still remember how it works!

 --
 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Styles and locales as Java jar in Maven Central

2013-09-13 Thread Bruce D'Arcus

I'm busy, so lost the thread. But if you, Rintze, and Sebastian agree,
that's fine by me.

On Fri, Sep 13, 2013 at 9:21 AM, Michel Krämer mic...@spamihilator.com wrote:
 Any objections? Otherwise I would upload the files as suggested by Rintze.

 Cheers,
 Michel

 Am 11.09.2013 19:28, schrieb Michel Krämer:
 Yes, although with my proposed scheme there would always be a snapshot
 of a higher version than any of the releases, so it would be clear
 that the snapshot would be the tip.
 I totally agree.

 @all: should I do it like this now?

 Michel


 Rintze

 On Wed, Sep 11, 2013 at 11:14 AM, Avram Lyon ajl...@gmail.com wrote:
 It would be good to provide guidance to JAR users indicating that the
 snapshot is usually the best version to use, since a so-called release
 happens only upon revision of the specification.

 On Sep 11, 2013 7:10 AM, Michel Krämer mic...@undercouch.de wrote:

 Is there any significant drawback to only having snapshots? How about
 only having a 1.0.1-SNAPSHOT for now.
 Sounds great. I would create a 1.0 release for the 1.0 branch in GitHub
 and a 1.0.1-SNAPSHOT that is updated daily or weekly or so. Later when
 1.0.2 has been released we can create a 1.0.1 release and a
 1.0.2-SNAPSHOT. Sounds reasonable to me.

 Michel


 Rintze


 --

 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks

 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk

 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



 --

 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks

 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk

 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


 --

 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk

 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


 --

 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk

 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


 --
 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL editor update

2013-09-13 Thread Bruce D'Arcus

So how about Mendeley taking responsibility for maintaining the repos/projects?

;-)

On Fri, Sep 13, 2013 at 10:02 AM, Steve Ridout steverid...@gmail.com wrote:
 I know it's a bit confusing, I'll try to explain.

 # The Different Repos

 The motivation for having different repos was that different ref-managers or
 clients should be able to share common code, but also be able to customise
 their instance to work within their own websites or applications. So we
 have:

 ## Core Library - https://github.com/citation-style-editor/csl-editor

 - The vast majority of code is here
 - Load and Save style functions *not* provided, this is up to the specific
 instance to implement
 - All ref-manager instances should use and contribute back to this
 - No reference manager specific code allowed!

 ## Demo Instance
 https://github.com/citation-style-editor/csl-editor-demo-site

 - The instance hosted by github pages at http://editor.citationstyles.org
 - Contains the Core Library as a git submodule
 - Adds the top navigation bar and /about page
 - Code to load and save styles to disk
 - Script to deploy to github pages
 - Intended to be forked by others and changed completely to suit their needs

 ## Mendeley Instance - http://csl.mendeley.com/about/

 - Forked from the csl-editor-demo-site
 - Contains the Core Library as a git submodule
 - Code to authorise and load/save styles to Mendeley's web service
 - Ask Carles for more info

 # Deployment

 1. If you alter the core library
 https://github.com/citation-style-editor/csl-editor, you may need to
 re-convert the schema files and re-generate the example citations. To do
 this, you'll need node.js and it's package manager npm installed, and then
 you simply run ./configure.sh
 It takes a good few minutes to generate all the example citations, but
 results of the configure are committed to the repo here:
 https://github.com/citation-style-editor/csl-editor/tree/master/generated so
 you'll only need to reconfigure if you actually change the schema, or
 anything affecting the example citations.

 2. To re-deploy the demo-site to gh-pages:
 https://github.com/citation-style-editor/csl-editor-demo-site#to-deploy

 (you'll have to be a member of the github organisation to do this:
 https://github.com/citation-style-editor - ask myself or Carles if you want
 to join)


 On 13 September 2013 15:08, Rintze Zelle rintze.ze...@gmail.com wrote:

 Thanks, Steve. By the way, I'm always a bit confused about the exact
 relationship between the
 https://github.com/citation-style-editor/csl-editor and
 https://github.com/citation-style-editor/csl-editor-demo-site
 repositories, and the live versions at
 http://editor.citationstyles.org/ and http://csl.mendeley.com/ . Could
 you give a brief explanation? Are there any differences between the
 versions at the two domains? And what is the current workflow to
 deploy at http://editor.citationstyles.org/ ?

 Rintze

 On Fri, Sep 13, 2013 at 8:58 AM, Steve Ridout steverid...@gmail.com
 wrote:
  I've just updated some of the CSL editor dependencies to their latest
  versions:
 
  - locales
  - styles
  - citeproc-js
 
  There a few other minor changes too and the updated version is live at
  http://editor.citationstyles.org. Please keep an eye out for any
  unintended
  breakages and let me know via github issues.
 
  Steve
 
  PS: I'm still hoping that someone else will take over responsibility for
  future maintenance and development of the editor. I'm no longer in
  academia,
  and no longer create reference manager software, so it would be great to
  see
  it evolve in the hands of someone more suitable. I'm very willing to
  help
  out if anyone needs help finding their way around the code, assuming I
  can
  still remember how it works!


 --
 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks

 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



 --
 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Styles and locales as Java jar in Maven Central

2013-09-10 Thread Bruce D'Arcus

Awesome effort Michel!

My first thought is to take you up on your offer setup and maintain
the org.citationstyles group (which doesn't exist, since nobody here
does Java).

Any objections out there?

On Tue, Sep 10, 2013 at 9:03 AM, Michel Krämer mic...@undercouch.de wrote:
 Hi folks,

 This message is a follow-up to my pull request:
 https://github.com/citation-style-language/styles/pull/690

 I'm currently working on a project called citeproc-java. It's a wrapper
 around citeproc-js with a little extra stuff. You can find the draft
 documentation of the yet unfinished library here:
 http://michel-kraemer.github.io/citeproc-java/

 In my pull request I was asking to include a pom.xml file to be able to
 upload the styles and locales as jar files to Maven Central. So I could
 use them in citeproc-java as regular Maven dependencies.

 I understand that the CC BY-SA 3.0 license generally allows me to
 distribute the files myself. However I first wanted to get your feedback
 on this. In particular I wanted to ask if I should upload the files to
 Maven Central using my existing user id (which would be a matter of a
 couple of minutes) or if citationstyles.org has already got its own one.
 Basically there are three ways to go:

 * I can upload the files under my own group id de.undercouch
or de.fhg.igd with an artifact id of
citation-style-language-styles or something like this
(I don't prefer this way)
 * I ask the Maven Central guys to assign the group id
org.citationstyles to my user id, so I would be the
maintainer and can upload files whenever I want (this would
be the easiest one for me, but here I need your permission.
Of course it's always possible to add more maintainers in
the future)
 * Someone of you already is the maintainer of this group id
or volunteers to become one. (this may be the preferred
option for you, but updating the files in Maven Central
might also mean more work for you)

 As I said, I'm absolutely OK with being the maintainer of
 org.citationstyles in Maven Central, if this is also OK for you. I will
 regularly update the files there. Of course the pom.xml files will
 contain the correct license information and a link back to the project.
 I even created a small Gradle script that adds all contributors from the
 .csl files to the pom.xml file:
 https://github.com/michel-kraemer/styles/blob/gradle/build.gradle

 What do you think?

 Cheers,
 Michel

 --
 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Styles and locales as Java jar in Maven Central

2013-09-10 Thread Bruce D'Arcus

On Tue, Sep 10, 2013 at 2:14 PM, Michel Krämer mic...@undercouch.de wrote:

...

 I will try to upload changes from time to time, but I would suggest to
 think about a better versioning scheme, because once an artifact is
 released under a specific version it should not be changed anymore
 (unless you want to break clients that use it). Something like
 1.0.1.DATE (i.e. 1.0.1.20130910) would work, for example. But I guess it
 would be better to create real releases from time to time (1.1, 1.2,
 2.0, etc.).

Although, it may be worth reminding ourselves that CSL (and git) is
designed to be distributed, which rather conflicts with the notion of
a centralized, versioned, repository.

...

Bruce

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Proposal: add volume-title as a CSL variable

2013-09-05 Thread Bruce D'Arcus

I'm not at this point making any particular recommendation. All I'm
saying is that we need to step back and consider the use cases, and we
need to do that within the context of the existing design.

If we're talking about multi-volumed books, we have: item (book),
volume (what is actually a collection of books), and optionally,
series (also a collection of books, and/or book volumes). So that's
awkward, particularly if you consider possibility of edited books.

If we're talking special journal issues, we have: item (article),
issue (what I'd say is a container), and journal (a collection). I
made a design decision, that may or may not have been conscious at the
time, to effectively through out the issue level in terms of its
mapping to the basic logical levels.

I don't much like at first glance adding something quite so concrete
and orthogonal as volume-title.

On Thu, Sep 5, 2013 at 10:58 AM, Sebastian Karcher
karc...@u.northwestern.edu wrote:
 yeah, I'm with Nick here - using container-title for volume title is a
 _very_ uncomfortable fit.


 On Thu, Sep 5, 2013 at 12:59 AM, Nick Bart nickbart1...@gmail.com wrote:

 On Wednesday, 4 September 2013 13:00:47 UTC+2, Bruce D'Arcus wrote, on
 https://groups.google.com/forum/#!topic/pandoc-discuss/-SajbqoPX8k:

 Yeah, I'm saying that a journal is (should be) really a collection,
  as is a book series, a legal code, etc.

 But let's move this to the CSL venues.


 I dont't actually think so. Monographs and journals are conceptually
 on the same level: they are the major independent bibliographic units,
 most bibliographic conventions dictate that their titles (and only
 their titles) are italicized, etc.

 Thus, I do not see a problem in continuing to use container-title
 for journal titles.

 Some journals do include series information, but this is conceptually
 very much unlike book series information: For journals, this is
 typically of the form New series, or 2nd series, and indicates a
 subdivision of one journal, and appears immediately after the journal
 title, and in databases sometimes even as part of the title. It seems
 CSL does not have a variable for his kind of information yet. The CSL
 variable section comes close, but not quite.

 Upshot: I do not feel existing title variables (title,
 container-title, collection-title) would need to be changed; it's
 only that one that is missing so far (volume-title) needs to be
 added.

 Variable names of course, could be reconsidered. Even volume-title
 is not ideal since in the context of an article it would rather mean
 issue-title, but for the sake of simplicity this could prabably be
 accepted.


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft
 technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!

 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




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

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Proposal: add volume-title as a CSL variable

2013-09-04 Thread Bruce D'Arcus

But the fact remains, the zotero-bit discussion focuses on the needs
of zotero users. By definition, it does not include other communities.

That's all I really meant to say.

Bruce

On Wed, Sep 4, 2013 at 1:57 PM, Sebastian Karcher
karc...@u.northwestern.edu wrote:
background for re-posting is here:
http://osdir.com/ml/general/2013-09/msg04463.html
I actually disagree with Bruce on the nature of the discussion on
zotero-bits: It has a specific tag for csl changes and everyone who writes
or helps to write the specs is active there. Before we make any spec changes
(and certainly before we introduce new variables) we'll write them up and
post about them here so implementers can comment. We'd also likely move
things over to the CSL issue tracker once work on a new version of specs
begins (which isn't currently the case). But until then, zotero-bits,
inspite of its name, seems like a perfectly apt place for such details.

On Tue, Sep 3, 2013 at 12:27 PM, Nick Bart nickbart1...@gmail.com wrote:

I'd like to repeat a proposal first made by adam3smith in Jan 2013 at
https://github.com/ajlyon/zotero-bits/issues/54, which apparently has
not been posted on a CSL list or issue tracker before.

The proposal is to add volume-title as a CSL variable, intended to
hold (a) the title of a single volume that is itself part of a
multi-volume monograph, or (b) the title of a special issue of a
journal.

Rationale: CMoS requires a distinction between the title of a single
volume (CSL: volume-title) and the title of a multi-volume monograph
(CSL: title, or container-title for book chapters etc.), and both
need to be distinguished from series (CSL: collection-title).

adam3smith's original post follows:

http://forums.zotero.org/discussion/26476/helpfeature-request-individual-volumes-as-parts-of-multivolume-works/#Item_3

Examples from Chicago Manual include:
Pelikan, Jaroslav. The Christian Tradition: A History of the Development
of Doctrine. Vol. 1, The Emergence of the Catholic Tradition (100–600).
Chicago: University of Chicago Press, 1971.

http://www.chicagomanualofstyle.org/16/ch14/ch14_sec124.html

and

Barrows, Herbert. Reading the Short Story. Vol. 1 of An Introduction to
Literature, edited by Gordon N. Ray. Boston: Houghton Mifflin, 1959.

http://www.chicagomanualofstyle.org/16/ch14/ch14_sec127.html

Note that these are different from (and can, in fact co-occur with)
series and series title.

Proposal: add a field Volume Title to Book and Book Section, map it to
new CSL variable volume-title

This could be combined with #36 - if we create a field Issue Title we
can use that as an indicator of a special issue and map it to the same
volume-title CSL variable.

http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

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

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] title casing skip words

2013-08-26 Thread Bruce D'Arcus

I will only say that I worry that this is a longer list than I'd like, and
that it may result in a fair bit of complaining from users, who get
unexpected results.

Am not sure I'm right, and I don't feel really strong about this; just
sayin'.


On Mon, Aug 26, 2013 at 11:38 AM, Sebastian Karcher 
karc...@u.northwestern.edu wrote:

 resending without all the thread at the bottom - sourceforge is complaining
 this is the list from Wikipedia (WP) narrowed down manually by me as
 described.
 If there are not objections against the list itself, yes, putting these in
 the documentation as JSON sounds good.
 Frank and other proc maintainers - any issues/wishes for implementing this?


 --
 Introducing Performance Central, a new site from SourceForge and
 AppDynamics. Performance Central is your source for news, insights,
 analysis and resources for efficient Application Performance Management.
 Visit us today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Rename xbiblio mailing list?

2013-08-22 Thread Bruce D'Arcus

My solution to the spam problem (on the bibo list) was to moderate
membership (something I guess we can't do now). This requires people to
write a short description of why they're joining, and for an admin to
approve it. I can also force moderation on new member posts, although
that's not generally necessary.

Bruce


On Thu, Aug 22, 2013 at 12:08 PM, Rintze Zelle rintze.ze...@gmail.comwrote:

 On Thu, Aug 22, 2013 at 4:44 AM, Robert Knight
 robert.kni...@mendeley.com wrote:
  My main worry is be that Google might shuts down Google Groups at some
  point
 
  This is always some risk but Google does actively use Google Groups
 itself
  for development mailing lists for Blink, Chrome and Go so
  the situation isn't the same as it was with Reader for example.

 Also, is this still relevant? I don't administer a Google Group, so I
 don't know if things have improved since 2009.

 http://ejohn.org/blog/google-groups-is-dead/
 https://groups.google.com/forum/#!topic/jquery-en/_GgR8UkoqpE

 Rintze


 --
 Introducing Performance Central, a new site from SourceForge and
 AppDynamics. Performance Central is your source for news, insights,
 analysis and resources for efficient Application Performance Management.
 Visit us today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] title casing skip words

2013-08-02 Thread Bruce D'Arcus

Great; thanks.

I still think the notion of a preposition in their rules may not be
entirely clear. But what seemed to be the emerging consensus on how to
deal with this should allow us to get what we need. If it were me, I'd
only include the obvious core prepositions, and examples they include
in CMoS. E.g. I would not include every word or group of words that's
listed in WikiPedia.

I would also leave room for the possibility there are other rules on
this in the future. Certainly that's been the case with things like
shortening number ranges.

BTW, the stop words phrase is just something I borrowed from
programming. It may or may not be the best phrase here.

https://en.wikipedia.org/wiki/Stop_words

On Thu, Aug 1, 2013 at 11:32 AM, Sebastian Karcher
karc...@u.northwestern.edu wrote:
 yes, I do indeed think so. Here are the full rules from CMoS, followed by
 some examples.
 Notice the explicit regardless of length in rule three and the lower
 casing of according to in the 4th example.
 As I mention in my original mail, we won't be able to get everything right
 all the time (see example 5), but that's already the case now.


 The conventions of headline style are governed mainly by emphasis and
 grammar. The following rules, though occasionally arbitrary, are intended
 primarily to facilitate the consistent styling of titles mentioned or cited
 in text and notes:

 1. Capitalize the first and last words in titles and subtitles (but see
 rule 7), and capitalize all other major words (nouns, pronouns, verbs,
 adjectives, adverbs, and some conjunctions—but see rule 4).

2.  Lowercase the articles the, a, and an.

3.  Lowercase prepositions, regardless of length, except when they are
 used adverbially or adjectivally (up in Look Up, down in Turn Down, on in
 The On Button, to in Come To, etc.) or when they compose part of a Latin
 expression used adjectivally or adverbially (De Facto, In Vitro, etc.).

 4. Lowercase the conjunctions and, but, for, or, and nor.

5.  Lowercase to not only as a preposition (rule 3) but also as part of
 an infinitive (to Run, to Hide, etc.), and lowercase as in any grammatical
 function.

 6. Lowercase the part of a proper name that would be lowercased in text,
 such as de or von.

 7. Lowercase the second part of a species name, such as fulvescens in
 Acipenser fulvescens, even if it is the last word in a title or subtitle.



 Mnemonics That Work Are Better Than Rules That Do Not
 Singing While You Work
 A Little Learning Is a Dangerous Thing (2)
 Four Theories concerning the Gospel according to Matthew (2, 3)
 Taking Down Names, Spelling Them Out, and Typing Them Up (3, 4)
 Tired but Happy (4)
 The Editor as Anonymous Assistant (5)
 From Homo erectus to Homo sapiens: A Brief History (3, 7)
 Defenders of da Vinci Fail the Test: The Name Is Leonardo (2, 3, 6)
 Sitting on the Floor in an Empty Room (2, 3), but Turn On, Tune In, and
 Enjoy (3, 4)
 Ten Hectares per Capita, but Landownership and Per Capita Income (3)
 Progress in In Vitro Fertilization (3)





 On Thu, Aug 1, 2013 at 9:22 AM, Bruce D'Arcus bdar...@gmail.com wrote:

 On #1, did you look at the list of prepositions on wikipedia I link
 to? If yes, do you really think the CMoS editors expect ALL of those
 words to not be capitalized?

 I guess my point is preposition appears to not be so straightforward
 thing, so we should be careful, and that CMoS editors make mistakes
 too.

 Bruce

 On Thu, Aug 1, 2013 at 11:06 AM, Sebastian Karcher
 karc...@u.northwestern.edu wrote:
  1. The CMoS doesn't provide a _de_scription of title case, it provides a
  _pre_scription. If we want correct title case according to CMoS we'll
  need
  to follow it. If someone wants to put in the work to find out if other
  style
  manuals define other capitalization rules I'd be happy to discuss those,
  but
  I've never seen them clearly defined anywhere but in the CMoS (which we
  also
  follow otherwise, e.g. by always capitalizing the last word).
 
  2. CMoS does not give a comprehensive list of words. So while on the
  technical side, prepositions are indeed just a subset of the stop words,
  I
  don't think we should prescribe what processors regard as preposition in
  the
  specs - not least because that would mean changing the specs every time
  we
  notice a preposition we didn't include. I like Rintze's idea of just
  supplying them in a separate file.
 
 
  On Thu, Aug 1, 2013 at 7:50 AM, Bruce D'Arcus bdar...@gmail.com wrote:
 
  I will also add that, looking at this list of english prepositions (is
  this correct?), I'm not sure I accept the CMoS description.
 
  https://en.wikipedia.org/wiki/List_of_English_prepositions
 
  Bruce
 
  On Thu, Aug 1, 2013 at 9:43 AM, Rintze Zelle rintze.ze...@gmail.com
  wrote:
   Does CMoS give a comprehensive list of words? If not, we could change
   the language in the spec to something more general (e.g. a mention
   that we follow CMoS on this topic), and provide

Re: [xbiblio-devel] Journal Abbreviations file

2013-07-22 Thread Bruce D'Arcus

My opinion is less important than the implementers here, but given
that we already do XML and JSON, I'd suggest JSON would be better than
adding a third.

Bruce

On Mon, Jul 22, 2013 at 1:56 PM, Rintze Zelle rintze.ze...@gmail.com wrote:
 FYI, I inquired at NCBI whether their abbreviation list is indeed in
 the public domain, and they confirmed it is:

 --- (quote)
 These table/files:
 http://www.ncbi.nlm.nih.gov/books/NBK3827/table/pubmedhelp.pubmedhelptable45/
 are NCBI generated and therefore in the public domain,  so you do not
 need a permission for use:

 http://www.ncbi.nlm.nih.gov/About/disclaimer.html
 ---

 As an aside, does anybody have a preference for the format used to
 store abbreviations in the CSL repo? Tab-delimited CSV or JSON?

 Rintze

 On Mon, Jul 8, 2013 at 12:39 PM, Carles Pina carles.p...@mendeley.com wrote:
 Here I show what I meant:
 https://github.com/cpina/abbreviations/tree/master/ncbi

 See the result:
 https://raw.github.com/cpina/abbreviations/master/ncbi/abbreviations.txt
 (it's the previous lists, deduplicated)

 May this be useful?

 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Meet thousands of cheating milfs in your area.

2013-05-17 Thread Bruce D'Arcus

We're getting increasing amounts of spam. I wish this ML system was
better, where we could configure a la Google Groups to force new
members to apply, and they can only post if we explicitly approve.

On Fri, May 17, 2013 at 9:31 AM, Frank Bennett biercena...@gmail.com wrote:
 On Wed, May 15, 2013 at 11:43 AM, root@swwkbufc root@swwkbufc wrote:
 Millions of wet ladies are looking for cocks. Join today.

 http://redirect.yandrewantop.com

 Gosh, I had no idea. Thanks for the tip.













 628971
 qlbuivie


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Syntax proposal: conditions [take two]

2013-05-13 Thread Bruce D'Arcus

I've created this place holder page.

https://github.com/citation-style-language/styles/wiki/Versioning

If you want to add to it, and don't have permission, let us know.

On Mon, May 13, 2013 at 11:58 AM, Rintze Zelle rintze.ze...@gmail.com wrote:
 On Mon, May 13, 2013 at 11:52 AM, Robert Knight
 robert.kni...@mendeley.com wrote:
 Suggestion: can we marshal this into some document,
 say on the wiki, that we can refer to later?

 I would appreciate this. I haven't had time to fully read and digest
 this thread yet.  The gist Frank posted above really does make me
 wonder quite what kind of rabbit hole we're going down.

 I think the most productive way would be to start by identifying the
 various possible release strategies (rolling vs. versioned updates,
 etc.), taking into account how they would work with maintenance of
 styles/locales in the repositories and those in the wild. I'll leave
 it to others to take the lead on this, though.

 Rintze

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their applications. This 200-page book is written by three acclaimed
 leaders in the field. The early access version is available now.
 Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Syntax proposal: conditions [take two]

2013-05-08 Thread Bruce D'Arcus

I'd like to ask an orthogonal question. See below ...

 As this is backward-compatible, deployment in a CSL 1.0.2 version
 should be possible (but I have no strong opinion).

Do we have a common understanding of how we define
backward-compatible for CSL?

Do we maybe need to make that explicit if it's not now?

Bruce

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Syntax proposal: conditions

2013-04-28 Thread Bruce D'Arcus

To clarify ...

On Sun, Apr 28, 2013 at 8:07 AM, Sylvester Keil sylves...@keil.or.at wrote:
 Bruce, I am in full agreement with your points regarding the design process.

 The concerns you raised are very important (who does the change benefit and 
 how? what are the costs? do the benefits outweigh the costs?) but the one on 
 which most emphasis was placed in the discussion (or so it seemed to me) was 
 the proposal's alleged disruptiveness.

 That's what I wanted to draw attention to.

 Or, more to the point: how exactly does the trailing '-all' etc. make things 
 more complicated in a meaningful way?

 Currently we have something like: variable=x y z and a processor must:

 - split the value into tokens
 - fetch data from the citation item according to those tokens
 - join the evaluated data based on the value of the 'match' attribute

 Now, with variable-all=x y z the processor must:

 - split the value into tokens
 - fetch data from the citation item according to those tokens
 - join the evaluated data using logical AND semantics

 Why is that so disruptive as opposed to the current specification?

When I used the word disruptive in this context, I was meaning WRT
to compatibility, and therefore style and schema versioning. I realize
for developers, it's not that big a deal.

Do we have a clear policy on this? Does a change like this go in a 1.1
schema and spec, and do we create 1.1 variants of all 5000+ styles?

Notwithstanding details, I think this is the core issue I see.

On the detail you identify here, I see no problem with that example
apart from the above 

 The main change required to implement the original proposal was actually that 
 the evaluation of all conditions can not be calculated in a single iteration 
 anymore, but with one iteration per attribute (variable, is-numeric etc.). 
 This leads to a slight change in how the 'none' matcher must be handled to 
 avoid double negations. In my experience this was the most disruptive aspect 
 of the proposal, but was not even tackled in the present discussion.

 The even bigger change is probably caused by the 'not:' prefix (at least in 
 the Ruby implementation that was the case).

Right. This is an example that conflicts with current design
foundations in CSL.

Now, if you all think that's a good idea, that's fine. All I'm saying
is *be aware you are doing this, and be very careful.*

CSL is now a mature specification, and elegant change management is
the key challenge for you all going forward.

Bruce

 Please don't get me wrong; I fully agree with what you're saying about the 
 process in general and I realize that new features should only be added if 
 they bring a real benefit to the language – all this should be discussed in 
 turn.

 But if we are dismissing requests because of implementation-level concerns I 
 would like to see more examples explaining those concerns. Especially when 
 the request comes with two concrete implementations, with unit tests, is 
 backwards compatible (in the sense that a processor can process styles with 
 or without the new feature using the same algorithm) and when the ensuing 
 discussion puts alternatives on the table that personally I find to be far 
 more disruptive than the originally requested changes, which, in my opinion 
 strike a good balance between the two possible approaches (i.e., putting 
 conditional logic into attribute values at the cost of more difficult 
 validation and putting the logic into additional attributes or nodes at the 
 cost of reduced readability and – in my personal opinion – less elegant 
 implementations).

 Sylvester

 On Apr 27, 2013, at 5:50 PM, Bruce D'Arcus wrote:

 With the caveat that I'm distracted with other things, and so have not
 followed this in detail ...

 But part of what I will say below is suggesting that the process
 should be easy to follow for people who aren't following closely.
 Right now, it's not.

 On Sat, Apr 27, 2013 at 11:12 AM, Sylvester Keil sylves...@keil.or.at 
 wrote:

 I'm sorry I'm a little late to join the discussion. I'm very much in 
 support of the idea of more expressive and powerful conditionals. As Frank 
 mentioned, I already implemented the original proposal. I also like 
 Andrea's and Frank's version that would go towards a single condition 
 attribute – that would be more complicated to implement but probably easier 
 for style authors to write.

 What I do like about the current conditionals (and also about Frank's 
 proposal) is the high-level structure:

 choose
  conditonal block … /conditonal block
  conditonal block … /conditonal block
  …
  conditonal block … /conditonal block
 /choose

 That is to say, one clearly defined root element per conditional branch 
 with no nested children. I think this is easy to read and easy to implement.

 I am not in favor at all of adding new (optional) child elements like and 
 or etc. In my experience, dependencies between nodes always lead to less 
 straight forward

Re: [xbiblio-devel] PKP conference call

2013-04-20 Thread Bruce D'Arcus

First, thanks to those of you that attended the call. I've kind of been
slammed this term.

Second, can we step back a bit and talk high-level vision? So, for example
...

Frank, from a user perspective, what sorts of scenarios would your proposal
enable?

Make it much easier for style editors to manage style additions and
changes? So much so that it would open up style editing to a much wider
range of users?

Something else?

Bruce


On Sat, Apr 20, 2013 at 6:07 AM, Frank Bennett biercena...@gmail.comwrote:

 On Sat, Apr 20, 2013 at 4:58 PM, Sebastian Karcher
 karc...@u.northwestern.edu wrote:
  Hi,
 
  last Thursday, Rintze, Frank, and I had a conference call with Alex
  Garnett and Juan Pablo Alperin of the Public Knowledge Project
  http://pkp.sfu.ca .
  We wanted to explore if (and if so how) CSL could find an
  institutional host at the PKP and what that would entail. Generally
  the conversation was very positive, the PKP folks know CSL and
  actually have started using it in one of their projects. They seemed
  quite positive about the general prospect of providing a home to CSL.
  They don't have much in terms of developer time to offer, but said
  that short term some advice and time for grant writing would be
  possible. They said they would want to be included in some way in the
  CSL decision-making process, though more in terms of knowing what's
  going on than to influence decisions (we did describe said process as
  open and consensus-based, which they seemed fine with). As for grants,
  as other have said, they said that it's basically impossible to get
  grants to cover day-to-day operations. Grant institutions want to fund
  something specific and new, so we'd have to think about that. Rintze
  and I came up with three areas on the spot:
  1. Specifications - while the syntax is well specified, all the little
  things like eliminating double spaces/punctuation etc. that the
  processors do (or not) isn't. It should be
  2. Legal CSL - incorporating Frank's modification for legal support
  3.  Other CSL 1.1/2.0 developments including field updates, potential
  multilingual improvements etc.
  Perhaps the biggest concern in all of this is that Rintze and I don't
  see how this is going to reduce our work (which, after all, was one of
  the original reasons we started talking about this).

 That's a big one.

 I had an idea today, though, that might catch both objectives. Here's
 the pitch. I think it's as original as casting the CSL editor. See
 what you think about the idea, though.

 ***

 CSL is a carefully designed language. The potential for CSL to become
 a de facto standard for defining and automating document referencing
 formats has been proven through performance: several implementations
 of the language are running in the wild, and user-contributed styles
 have brought the CSL Style Repository to 800+ styles covering 4000+
 journals. Major projects, including Mendeley, Papers and Zotero rely
 upon the language to serve a large user community, many working in
 research or at the PhD level.

 In the community's drive to satisfy user needs, the focus has been on
 individual styles. This has spread attention across an expanding
 codebase, slowing efforts to refine and improve styles across the
 archive as a whole.

 This challenge can be addressed by drawing upon a latent potential for
 modularity in CSL that has not heretofore played a part in style
 maintenance and distribution. At the most basic level, CSL cleanly
 separates four elements of style design:

   * Citation formats
   * Citation format parameters
   * Bibliography formats
   * Bibliography format parameters

 Although each style in the CSL Style Repository is currently stored as
 an atomic unit, each is composed of these four elements, and they can
 easily be separated and remixed, resulting in a smaller base of code,
 higher quality in many styles, and potential for more rapid coverage
 of remaining publisher and university styles. There is deeper
 potential for modularity in CSL (through a shared macro library).
 Implementing this simple modular break-out in the current repository
 infrastructure will make it possible to explore those avenues in
 future.

 Moving to a modular archive design would require the following:

   * Style-level test suites to confirm current style behaviour;
   * Tools for breaking out the current code base:
  - Separating current styles into citation-format and
 bibliography-format elements for separate validation;
  - Extracting and storing bibliography and citation format IDs and
 parameters on a per-style basis.
   * Tools for exploring commonalities between citation and
 bibliography formats, and merging IDs;
   * A middle layer for recombining styles from modular code and
 testing the result.

 For simplicity, this back-office functionality should be masked from
 users and style designers, who understand CSL styles (either when
 using the CSL editor, or when directly editing

Re: [xbiblio-devel] CSL sytles graphic

2013-04-19 Thread Bruce D'Arcus

Cool!

What's a real style? One that's non-dependent?


On Fri, Apr 19, 2013 at 9:22 AM, Carles Pina carles.p...@mendeley.comwrote:

 Hi,

 Some weeks or months ago I generated a static graphic of the number
 of the styles in the CSL repo (it was a script that generated a CSV
 and then I had to import into LibreOffice, etc.).

 Today is hackday day here at Mendeley and I've done a better version:
 http://pinux.info/csls_counter/

 So, everyday, a 1:20am British time, it will regenerate the graph.

 You can see the constant work of Rintze and Sebastian and also the
 pushes from Charles Parnott :-) (I hope to be able to do some other
 big push as mentioned some days ago).

 If you wish something else there let me know!

 Ah, the script generates a static .CSV file and a Javascript library
 uses it. So this could be pushed to some other place if we wished.

 Regards,

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


 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Syntax proposal: conditions

2013-04-15 Thread Bruce D'Arcus

Correction:

On Mon, Apr 15, 2013 at 12:10 PM, Bruce D'Arcus bdar...@gmail.com wrote:

 admittedly, the processing is simple here; just split on a colon and treat
 as key-value ...

Not so; the trailing -all etc proposal makes things more complicated.

Bruce

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] How should publishers link to CSL styles

2013-04-10 Thread Bruce D'Arcus

Question: what's involved in getting the style into the user's app?

For sake of argument, why can't we have a simple general solution like:

CSL styles go into a common directory; on linux, say ~/.cslstyles or some such.

Apps then simply watch that directory.

I'm not a developer, so probably missing some detail, but I think
simple is better all around.

On Wed, Apr 10, 2013 at 7:43 AM, Robert Knight
robert.kni...@mendeley.com wrote:
 Hello,

 I think I might be re-stating Frank's suggestion here.

 For mendeley:// links, we have an intermediate URL at
 open.mendeley.com (eg.
 http://open.mendeley.com/library/filter/mendeley-suggest) which
 forwards to mendeley:// or gives the user further steps if they do not
 have Mendeley installed.

 We could provide a similar page on citationstyles.org which would
 handle the details of getting the style into the user's app.  A simple
 implementation would present a list of apps and clicking one would
 forward to that app (eg. via a mendeley:// link, or a direct CSL link
 for Zotero) or provide suitable instructions.

 Regards,
 Rob.

 On 10 April 2013 09:42, Carles Pina carles.p...@mendeley.com wrote:
 Hi,

 In Mendeley: the publisher could host the style in any place and then
 have a link like:
 mendeley://csl://http://publisher.com/style/style1.csl

 The browser will invoke Mendeley to handle this link, which one will
 download the style, install and select it.

 We always push the publishers to add the styles to citationstyles.org
 github repository (with more or less success).

 Regards,

 On 9 April 2013 19:47, Sebastian Karcher karc...@u.northwestern.edu wrote:
 I'm not sure about 2 - I see a lot of potential downsides to that, too, but
 I thought
 1) was in general already possible - Zotero (and I believe Mendeley) will
 install CSLs server with the right mime-type - I believe text/x-csl for
 Zotero.
 Charles - what about Papers?


 On Tue, Apr 9, 2013 at 12:37 PM, Bruce D'Arcus bdar...@gmail.com wrote:

 Great questions!

 Two things, which I've said before:

 1) I still think it'd be great for authors to be able to do a
 one-click install from an author instruction page at a journal site.

 2) that at some point, journals should just self-host the styles

 Can we really not make both of these possible?

 On Tue, Apr 9, 2013 at 2:31 PM, Sebastian Karcher
 karc...@u.northwestern.edu wrote:
  Hi everyone,
  I'm in touch with a rep from Taylor and Francis about getting a
  Journal/style list similar to what we got from Springer so that we can
  add
  their journals to repo (TF started consolidating their styles about a
  year
  ago).
  I also suggested to them linking to CSL styles in their instructions to
  authors and she seemed open to that, but asked what to link to. Since
  every
  major CSL project runs its own version of how to install styles that
  seemed
  tricky. How should we go about that? What should I ask them to put in
  their
  author guides?
 
  Sebastian
 
  --
  Sebastian Karcher
  Ph.D. Candidate
  Department of Political Science
  Northwestern University
 
 
  --
  Precog is a next-generation analytics platform capable of advanced
  analytics on semi-structured data. The platform includes APIs for
  building
  apps and a phenomenal toolset for data science. Developers can use
  our toolset for easy data analysis  visualization. Get a free account!
  http://www2.precog.com/precogplatform/slashdotnewsletter
  ___
  xbiblio-devel mailing list
  xbiblio-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
 


 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




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

 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] How should publishers link to CSL styles

2013-04-09 Thread Bruce D'Arcus

Great questions!

Two things, which I've said before:

1) I still think it'd be great for authors to be able to do a
one-click install from an author instruction page at a journal site.

2) that at some point, journals should just self-host the styles

Can we really not make both of these possible?

On Tue, Apr 9, 2013 at 2:31 PM, Sebastian Karcher
karc...@u.northwestern.edu wrote:
 Hi everyone,
 I'm in touch with a rep from Taylor and Francis about getting a
 Journal/style list similar to what we got from Springer so that we can add
 their journals to repo (TF started consolidating their styles about a year
 ago).
 I also suggested to them linking to CSL styles in their instructions to
 authors and she seemed open to that, but asked what to link to. Since every
 major CSL project runs its own version of how to install styles that seemed
 tricky. How should we go about that? What should I ask them to put in their
 author guides?

 Sebastian

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

 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Pursuing grants for CSL-related development

2013-04-02 Thread Bruce D'Arcus

On Tue, Apr 2, 2013 at 5:39 PM, Frank Bennett biercena...@gmail.com wrote:

 For an institutional home, maybe (maybe) an active university consortium.

 http://www.universitas21.com/about
 or
 http://www.sakaiproject.org/about-sakai

Having spent a bit too much time with the latter over the past couple
of years, I'd have to say no to that; it's culture and governance
(they just merged with Jasig) seem a poor fit.

Bruce

 Not sure if one could capture the collective attention of one of these
 projects, but the interests seem to align reasonably well.

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Pursuing grants for CSL-related development

2013-04-01 Thread Bruce D'Arcus

Yup, agree with you Charles.

The only thing I would add to your list is a way for your developers
to easily see the impact of a style change. So a preview of a style
diff is you will.

Bruce

On Mon, Apr 1, 2013 at 4:06 PM, Charles Parnot charles.par...@gmail.com wrote:
 1) what the project would be to fix the problem? Is it a full-blown
 repository web app, for example, that could tightly integrate with the
 editor, that had the sort of broader review model I've previously
 advocated (e.g. that makes it easy and attractive for non-technical
 users to become style editors and reviewers)?

 I have recently come to the conclusion that a more attractive style editor, 
 that could be used by regular people is not the way to go. Unfortunately, 
 such a style editor will be really hard to do, and I am not even sure it can 
 be done. I feel like the resources put into such an effort would be better 
 spent in creating new styles, fixing existing ones, and cleaning things up. 
 And yes, writing tools that help with this is also a good thing, but we have 
 to strike the right balance between user-friendly and developer-friendly. 
 The recent Travis stuff has been very very useful, and a great asset for the 
 project. I don't know if I would have dared to create all those Springer 
 styles without it. And it was really set up very quickly, with relatively 
 small efforts (of course, it looked like it from my end!), aided by somebody 
 who knew the setup and approached things in a very pragmatic way.

 A grant to write a great CSL editor might be more sexy than paying somebody 
 to just go through styles, but it would be more efficient for the project IMO.

 If you think of the CSL styles as code, then the distinction between a user 
 and a developer is clear: the user is writing a paper and wants their f**ing 
 bibliography to be done (but is OK reporting a problem) and the developers 
 are the person contributing to the code (the XML!). Now, if we distinguish 
 between the CSL user and the CSL developer, there are still things that 
 could be better done for both categories.

 For the users:

 - a better style browser, including a way to find a style that matches what 
 they want (and yes, the current csl-editor is a good start for that)
 - a better reporting tool for style issues, where such report should have 
 clear fields about the expected output, the actual output, and the value of 
 the different fields (ideally, with citeproc-js showing the output, so a user 
 can reproduce the 'bug')


 For the developers:

 - a better style browser (the same as the one for the users!!)
 - a more strict process for submitting styles (what we discussed about pull 
 requests)
 - a better development environment, and the csl-editor has actually some very 
 interesting components there; but again, we are talking about an editor for 
 technical people, and that's fine, let's focus on that

 Charles


 On Mar 30, 2013, at 8:21 PM, Bruce D'Arcus bdar...@gmail.com wrote:

 On Sat, Mar 30, 2013 at 2:44 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

 ...

 Personally, I would really like to see the process of submitting
 styles to the repository become more automated. Sebastian Karcher,
 Charles Parnot and I spend a lot of time handling style submissions.
 The volume of style submissions has increased quite a bit over the
 past year, and a large fraction of the work is just making sure that
 the submissions are done correctly. While I have tried to document the
 process as clearly as possible for users, we still deal with a lot of
 incorrect GitHub pull requests, submissions of invalid CSL styles and
 style metadata that hasn't been entered correctly. My motivation to
 continue to perform this labor for free has its limits, so I welcome
 any thoughts on how to lessen this burden.

 I think this is the key, and as you suggest, is not really sustainable.

 So the question is how we address:

 1) what the project would be to fix the problem? Is it a full-blown
 repository web app, for example, that could tightly integrate with the
 editor, that had the sort of broader review model I've previously
 advocated (e.g. that makes it easy and attractive for non-technical
 users to become style editors and reviewers)?

 2) how do we fund it?

 On 2, I'm not really sure, but think some kind of logical
 institutional home would be helpful. What would be the appropriate
 medium and forum for us to explore different options (like, if a grant
 app, who would do it, and how?) here?

 Bruce

 --
 Own the Future-Intel(R) Level Up Game Demo Contest 2013
 Rise to greatness in Intel's independent game demo contest. Compete
 for recognition, cash, and the chance to get your game on Steam.
 $5K grand prize plus 10 genre and skill prizes. Submit your demo
 by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
 ___
 xbiblio

[xbiblio-devel] google api

2013-03-19 Thread Bruce D'Arcus

Haven't looked at yet, but wondering if this might enable live
citation/bib functionality?

http://www.engadget.com/2013/03/19/google-drive-realtime-api-lets-developers-make-collaborative-apps/

Bruce

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Names with particles

2013-03-18 Thread Bruce D'Arcus

Hmm ... doesn't this necessarily suggest some spec changes? If yes, don't
we need an issue, with usual documentation (of the use cases, etc.)?

Bruce

On Mon, Mar 18, 2013 at 8:58 PM, Frank Bennett biercena...@gmail.comwrote:

There has been a flurry of activity on the Zotero forums around the
handling of name particles. The citeproc-js processor is being too
aggressive about forcing capitals on particles, and the lack of
control has caused frustration to users.

Discussion has led to a possible solution. It is simple to describe,
but after implementing it in the processor, I find that it causes
quite a few of the existing tests to break. I have made a tentative
checkin of changes to the affected tests, so that they can be reviewed
by the group.

The rules applied in the proposal are:

(1) The first character of a name particle in first position on the
first-listed name in a bibliography is force to a capital letter.
(2) A particle not in first position is always forced to lowercase.

Three new tests provide a compact illustration of the behaviour:

https://bitbucket.org/bdarcus/citeproc-test/src/de13966c0d0c8a6fec4005b46ac6a07f3f614ff7/processor-tests/humans/name_ParticleCaps1.txt?at=default

https://bitbucket.org/bdarcus/citeproc-test/src/de13966c0d0c8a6fec4005b46ac6a07f3f614ff7/processor-tests/humans/name_ParticleCaps2.txt?at=default

https://bitbucket.org/bdarcus/citeproc-test/src/de13966c0d0c8a6fec4005b46ac6a07f3f614ff7/processor-tests/humans/name_ParticleCaps3.txt?at=default

(The ParticleCaps3 test includes a quote-escaped family name, to bind
the name particle as part of the name itself. If quote-escaping of off
the map of the specification, I can remove that data from the test.)

The affected tests are linked below. If members of the group have time
to review them, it would be a great help.

https://bitbucket.org/bdarcus/citeproc-test/commits/ad7cbfa7a378781bc6bfad33871a8a97e701379e

Frank

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Names with particles

2013-03-18 Thread Bruce D'Arcus

That's the point: if we're changing the test suite to respond to
non-documented behavior, then we better document it.

Frank, that'd be my impulse; maybe see what Rintze has to say?

On Mon, Mar 18, 2013 at 9:14 PM, Sebastian Karcher
karc...@u.northwestern.edu wrote:

I don't see where we address capitalization of name-particles at all in
the specs. Which part of the specs do you think this would affect, Bruce?
Maybe we should cover this - but if I see that correctly currently
citeproc does something that's not in the specs either.

On Mon, Mar 18, 2013 at 7:09 PM, Frank Bennett biercena...@gmail.comwrote:

The tests illustrate use cases.

You want me to repost this as an issue on the specification tracker?

On Tue, Mar 19, 2013 at 10:07 AM, Bruce D'Arcus bdar...@gmail.com
wrote:
Hmm ... doesn't this necessarily suggest some spec changes? If yes,
don't we
need an issue, with usual documentation (of the use cases, etc.)?

Bruce

On Mon, Mar 18, 2013 at 8:58 PM, Frank Bennett biercena...@gmail.com
wrote:

The rules applied in the proposal are:

Three new tests provide a compact illustration of the behaviour:

https://bitbucket.org/bdarcus/citeproc-test/src/de13966c0d0c8a6fec4005b46ac6a07f3f614ff7/processor-tests/humans/name_ParticleCaps1.txt?at=default

https://bitbucket.org/bdarcus/citeproc-test/src/de13966c0d0c8a6fec4005b46ac6a07f3f614ff7/processor-tests/humans/name_ParticleCaps2.txt?at=default

https://bitbucket.org/bdarcus/citeproc-test/src/de13966c0d0c8a6fec4005b46ac6a07f3f614ff7/processor-tests/humans/name_ParticleCaps3.txt?at=default

The affected tests are linked below. If members of the group have time
to review them, it would be a great help.

https://bitbucket.org/bdarcus/citeproc-test/commits/ad7cbfa7a378781bc6bfad33871a8a97e701379e

Frank

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

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https

Re: [xbiblio-devel] Ignoring name variable labels for sorting, subsequent author substitution

2013-03-14 Thread Bruce D'Arcus

Going back to this:

On Tue, Mar 12, 2013 at 10:44 AM, Rintze Zelle rintze.ze...@gmail.com wrote:

...

 2) Should name variable labels be ignored when applying subsequent
 author substitution?

 Previously, citeproc-js would produce

 Jones, Jim. 2011a. *A Title*. Location: Publisher.
 ———. 2011b. *C Title*. Location: Publisher.
 Jones, Jim, ed. 2011c. *B Title*. Location: Publisher.

 with subsequent-author-substitute active. The Zotero thread consensus
 seems to be that it would be preferable to get

 Jones, Jim. 2011a. *A Title*. Location: Publisher.
 ———. 2011b. *C Title*. Location: Publisher.
 ———, ed. 2011c. *B Title*. Location: Publisher.

Both to decide on the details, and also to ponder any particular
specification language, I'd go back to first principles, and logic.

The subsequent-author-substitute feature refers to author groups,
which are defined by names of the people in question; not their roles,
or any other descriptors.

Bruce

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Wanted: New home for CSL Editor

2012-12-07 Thread Bruce D'Arcus

http://editor.citationstyles.org/about/

;-)

On Fri, Dec 7, 2012 at 11:38 AM, Rintze Zelle rintze.ze...@gmail.com wrote:
 On Wed, Nov 28, 2012 at 3:45 AM, Dan Stillman dstill...@zotero.org wrote:
 This is great, and sorry for the lack of response from our end earlier.
 The PHP dependency was indeed the main impediment—hosting externally
 maintained server-side code in citationstyles.org's current location was
 problematic from a security perspective. Having it served straight from
 a GitHub branch is fantastic.

 Dan, Steve, would it be possible to similarly host the (Zotero) Style
 Repository at an address like repository.citationstyles.org (or
 styles.citationstyles.org ) and run the code
 (https://github.com/zotero/styles-repo) from GitHub?

 Rintze

 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] using in instead of and to separate authors

2012-11-30 Thread Bruce D'Arcus

The use case is indirect citation. I cite Doe, who is citing (or more
commonly quoting) Smith.

So either we cover this:

1) now, using a free text prefix
2) we add a new feature to processors to support this

Bruce
On Nov 30, 2012 7:57 AM, Carles Pina carles.p...@mendeley.com wrote:

 Hi,

 I don't know the final use case, but one of our users would like to
 use in instead of and in some inline citations. Like (Smith and
 Murphy) would be (Smith in Murphy).

 I read:
 http://citationstyles.org/downloads/specification.html#name
 
 and
 Specifies the delimiter between the second to last and last name
 of the names in a name variable. Allowed values are text (selects
 the and term, e.g. Doe, Johnson and Smith) and symbol (selects
 the ampersand, e.g. Doe, Johnson  Smith).
 

 I'll get more information about the use case. I wonder if some of you
 have thought about it.

 Regards,

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


 --
 Keep yourself connected to Go Parallel:
 TUNE You got it built. Now make it sing. Tune shows you how.
 http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] using in instead of and to separate authors

2012-11-30 Thread Bruce D'Arcus

+1
On Nov 30, 2012 8:40 AM, Sebastian Karcher karc...@u.northwestern.edu
wrote:

 some citations or all citations?
 For all citations, it'd be easily possible to just change the term in the
 style. But for some citation we'd need a trigger of some sort that would
 have to be send and understood by CSL and that's not currently possible
 (and I'd say probably not something we'd want to do?).
 I imagine the use case is a cited in type scenario - but if we do want
 to address that (and it does come up a fair amount esp. in the humanities)
 I imagine we'd want something cleaner  more comprehensive


 On Fri, Nov 30, 2012 at 7:30 AM, Carles Pina carles.p...@mendeley.comwrote:

 Hi,

 I don't know the final use case, but one of our users would like to
 use in instead of and in some inline citations. Like (Smith and
 Murphy) would be (Smith in Murphy).

 I read:
 http://citationstyles.org/downloads/specification.html#name
 
 and
 Specifies the delimiter between the second to last and last name
 of the names in a name variable. Allowed values are text (selects
 the and term, e.g. Doe, Johnson and Smith) and symbol (selects
 the ampersand, e.g. Doe, Johnson  Smith).
 

 I'll get more information about the use case. I wonder if some of you
 have thought about it.

 Regards,

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


 --
 Keep yourself connected to Go Parallel:
 TUNE You got it built. Now make it sing. Tune shows you how.
 http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




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


 --
 Keep yourself connected to Go Parallel:
 TUNE You got it built. Now make it sing. Tune shows you how.
 http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Locale files - script variants

2012-11-29 Thread Bruce D'Arcus

Minor thing: shouldn't file names be lower-case generally?

On Thu, Nov 29, 2012 at 4:09 PM, Frank Bennett biercena...@gmail.com wrote:
 Off-list, Rintze and I came to the conclusion that a processor can
 just treat the RS-Latn pair as a single tag, with the same fallback
 behaviour as a single element. In this case, sr-RS-Latn would fall
 back to plain-vanilla sr, with whatever default mapping defined for it
 in the processor (so sr-RS). That covers script variants under the RFC
 5646 specificaton, and should be simple to implement in processors.
 citeproc-js needs a small adjustment to handle the filename in that
 case, but it should be easy to do.

 So I'm fine with including the file in the repo, if others are happy with it.

 Frank


 On Fri, Nov 30, 2012 at 5:35 AM, Frank Bennett biercena...@gmail.com wrote:
 On Fri, Nov 30, 2012 at 1:14 AM, Avram Lyon ajl...@gmail.com wrote:
 I know that Frank built citeproc-js to be aware of BCP 47 semantics, which
 are used extensively in MLZ, but can we do this without demanding the same
 of other processors?

 Avram,

 I think that in locale filenames, citeproc-js will only handle the
 first two elements of a tag at the moment. What sort of syntax do you
 have in mind?

 Frank


 On Nov 28, 2012 7:33 PM, Rintze Zelle rintze.ze...@gmail.com wrote:

 A user wishes to contribute a Latin variant of the Serbian CSL locale
 file (in addition to the existing Cyrillic variant). See

 https://github.com/citation-style-language/locales/pull/46#issuecomment-10813711

 Is it acceptable to add a script subtag to the locale file name and
 xml:lang value? E.g. locales-sr-RS-Latn.xml (for Latin) and
 locales-sr-RS-Cyrl.xml (for Cyrillic) (I guess we could omit the
 script subtag from one variant, e.g. we could keep the Cyrillic
 variant as locales-sr-RS.xml). See also

 http://www.w3.org/International/articles/language-tags/Overview.en.php#script

 Rintze


 --
 Keep yourself connected to Go Parallel:
 VERIFY Test and improve your parallel project with help from experts
 and peers. http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


 --
 Keep yourself connected to Go Parallel:
 VERIFY Test and improve your parallel project with help from experts
 and peers. http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


 --
 Keep yourself connected to Go Parallel:
 VERIFY Test and improve your parallel project with help from experts
 and peers. http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Wanted: New home for CSL Editor

2012-11-28 Thread Bruce D'Arcus

Great; thanks everyone!

On Wed, Nov 28, 2012 at 6:04 AM, Steve Ridout steverid...@gmail.com wrote:
 Although there are only three votes I sensed a consensus forming so
 I've gone ahead and put it at http://editor.citationstyles.org, try it
 out, it works!

 On 28 November 2012 11:06, Charles Parnot charles.par...@gmail.com wrote:
 My vote also goes to http://editor.citationstyles.org



 The site also allows searching so maybe the last one is the most
 appropriate, but a bit long.

 Opinions please!

 On 28 November 2012 09:45, Dan Stillman dstill...@zotero.org wrote:
 On 11/27/12 10:37 AM, Steve Ridout wrote:
 Hello everyone,

 Continuing the earlier discussion started by Carles, I think it would
 be great for the CSL editor currently at steveridout.com/csl to move
 home to csleditor.citationstyles.org. To make this easy, I've removed
 the php dependency of the CSL editor site so it can be hosted on
 github pages.

 What this means:
 - Hosting is now free, in terms of money and admin hassle, by hosting
 it via github at any subdomain, e.g. csleditor.citationstyles.org.
 It's super-simple to set up, all you'd need to do is add a CNAME
 record and alter the CNAME text file in the repo.
 - Deploying is simple. Just commit the built version to the gh-pages
 branch in github. (contact myself or Carles if you'd like to be a
 member of the citation-style-editor github organisation)

 My hope is that this new setup will make it more attractive for other
 developers to get involved.

 If you agree, whoever is responsible for administrating the
 citationstyles.org domain (Dan Stillman?), please get in touch with me
 personally and we can set things up. I can set up redirects from the
 steveridout.com/csl to pages so the old links will still work.

 This is great, and sorry for the lack of response from our end earlier.
 The PHP dependency was indeed the main impediment—hosting externally
 maintained server-side code in citationstyles.org's current location was
 problematic from a security perspective. Having it served straight from
 a GitHub branch is fantastic.

 Steve, I've sent you an e-mail separately regarding the CNAME setup.

 - Dan

 --
 Keep yourself connected to Go Parallel:
 INSIGHTS What's next for parallel hardware, programming and related areas?
 Interviews and blogs by thought leaders keep you ahead of the curve.
 http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

 --
 Keep yourself connected to Go Parallel:
 INSIGHTS What's next for parallel hardware, programming and related areas?
 Interviews and blogs by thought leaders keep you ahead of the curve.
 http://goparallel.sourceforge.net
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



 On Nov 28, 2012, at 10:51 AM, Carles Pina carles.p...@mendeley.com wrote:

 Hi,

 There are two hard things in computer science: cache invalidation,
 naming things, and off-by-one errors.
 ( http://martinfowler.com/bliki/TwoHardThings.html )

 Ok, let's tackle naming things...

 On 28 November 2012 09:38, Steve Ridout steverid...@gmail.com wrote:
 Dan and I are having trouble deciding on the best subdomain name to
 use, here are some options:

 csleditor.citationstyles.org
 editor.citationstyles.org
 edit.citationstyles.org
 searchandedit.citationstyles.org

 I like editor.citationstyles.org


 The site also allows searching so maybe the last one is the most
 appropriate, but a bit long.

 Opinions please!

 On 28 November 2012 09:45, Dan Stillman dstill...@zotero.org wrote:
 On 11/27/12 10:37 AM, Steve Ridout wrote:
 Hello everyone,

 Continuing the earlier discussion started by Carles, I think it would
 be great for the CSL editor currently at steveridout.com/csl to move
 home to csleditor.citationstyles.org. To make this easy, I've removed
 the php dependency of the CSL editor site so it can be hosted on
 github pages.

 What this means:
 - Hosting is now free, in terms of money and admin hassle, by hosting
 it via github at any subdomain, e.g. csleditor.citationstyles.org.
 It's super-simple to set up, all you'd need to do is add a CNAME
 record and alter the CNAME text file in the repo.
 - Deploying is simple. Just commit the built version to the gh-pages
 branch in github. (contact myself or Carles if you'd like to be a
 member of the citation-style-editor github organisation)

 My hope is that this new setup will make it more attractive for other
 developers to get involved.

 If you agree, whoever is responsible for administrating the
 citationstyles.org domain (Dan Stillman?), please get in touch with me
 personally and we can

Re: [xbiblio-devel] Wanted: New home for CSL Editor

2012-11-27 Thread Bruce D'Arcus

+1.

So is the current editor instance served via github pages?

On Tue, Nov 27, 2012 at 10:37 AM, Steve Ridout steverid...@gmail.com wrote:
 Hello everyone,

 Continuing the earlier discussion started by Carles, I think it would
 be great for the CSL editor currently at steveridout.com/csl to move
 home to csleditor.citationstyles.org. To make this easy, I've removed
 the php dependency of the CSL editor site so it can be hosted on
 github pages.

 What this means:
 - Hosting is now free, in terms of money and admin hassle, by hosting
 it via github at any subdomain, e.g. csleditor.citationstyles.org.
 It's super-simple to set up, all you'd need to do is add a CNAME
 record and alter the CNAME text file in the repo.
 - Deploying is simple. Just commit the built version to the gh-pages
 branch in github. (contact myself or Carles if you'd like to be a
 member of the citation-style-editor github organisation)

 My hope is that this new setup will make it more attractive for other
 developers to get involved.

 If you agree, whoever is responsible for administrating the
 citationstyles.org domain (Dan Stillman?), please get in touch with me
 personally and we can set things up. I can set up redirects from the
 steveridout.com/csl to pages so the old links will still work.

 Regards,
 Steve

 PS: In case anyone is curious how much use the site is getting, here
 are the numbers from last month, Oct 27th - Nov 26th:

 Visits: 2,001
 Unique Visitors: 957
 Pageviews: 6,957
 Pages / Visit: 3.48
 Avg. Visit Duration:00:06:58
 Bounce Rate: 52.32%
 % New Visits: 41.93%

 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Keep yourself connected to Go Parallel: 
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL Editor in Mendeley Desktop 1.7

2012-11-17 Thread Bruce D'Arcus

On Sat, Nov 17, 2012 at 12:16 PM, Carles Pina carles.p...@mendeley.com wrote:

 I'd like to add, in our documentation, some information for our users
 with the steps to submit changes to the repository. I don't expect all
 the changes to be pushed back to the repository since it needs some
 extra work and back and forth. Indeed we should help the users who
 wants to do it.

I haven't looked at your integration, but is it feasible at some point
to allow users to submit styles to github with something close to one
click from within the editor?

I think we're still going to need better previewing to ensure quality,
but obviously it'd be good to lower barriers to sharing as low as
possible.

Bruce

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL Editor in Mendeley Desktop 1.7

2012-11-17 Thread Bruce D'Arcus

On Sat, Nov 17, 2012 at 6:43 PM, Carles Pina carles.p...@mendeley.com wrote:
 Hi,

 On 17 November 2012 18:38, Sebastian Karcher karc...@u.northwestern.edu 
 wrote:
 Hi,
 looks like Carles is fixing this. To explain: For the repository we need the
 styles to conform to the standard ID format - it seems easiest to just save
 all styles to conform to repository guidelines (as Steve's version does),
 but if you prefer to have different IDs like csl.mendeley.com/... for custom

 in this case is not if we prefer but we really need. The style id
 is used in Microsoft Word/Libreoffice documents, and needs to point to
 a URL where the style is served. This is what is happening at the
 moment (e.g. http://csl.mendeley.com/styles/16825/apa would download
 an apa style that I did for testing).

 Indeed, having an option to help the user to export the styles to the
 repository could change the style id.

Then maybe we need to rethink all of this business of style
identification and resolution, and where we want to be in the future
as a community of implementers?

The style ID is intended to be a globally unique, stable, identifier
for the style. It makes no sense for there to be 50 ids for each of 50
copies.

I guess what you really need is to know how to get a copy of the
style so that live formatting is consistent when sharing documents?

At the same time, we ideally really want CSL development and
distribution to be distributed, and so by definition to involve many
arbitrary URL domains (not just, as it is now in the repo,
zotero.org).

Bruce

 styles, it'd be nice to have an easy way for users to export the style with
 the ID (and link) set to the repository convention.

 I take note (see also some other email that I'll write in some minutes)

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

 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL Editor in Mendeley Desktop 1.7

2012-11-17 Thread Bruce D'Arcus

On Sat, Nov 17, 2012 at 7:13 PM, Carles Pina carles.p...@mendeley.com wrote:
 Hi,

 On 18 November 2012 00:07, Bruce D'Arcus bdar...@gmail.com wrote:
 On Sat, Nov 17, 2012 at 6:43 PM, Carles Pina carles.p...@mendeley.com 
 wrote:
 Hi,

 On 17 November 2012 18:38, Sebastian Karcher karc...@u.northwestern.edu 
 wrote:
 Hi,
 looks like Carles is fixing this. To explain: For the repository we need 
 the
 styles to conform to the standard ID format - it seems easiest to just save
 all styles to conform to repository guidelines (as Steve's version does),
 but if you prefer to have different IDs like csl.mendeley.com/... for 
 custom

 in this case is not if we prefer but we really need. The style id
 is used in Microsoft Word/Libreoffice documents, and needs to point to
 a URL where the style is served. This is what is happening at the
 moment (e.g. http://csl.mendeley.com/styles/16825/apa would download
 an apa style that I did for testing).

 Indeed, having an option to help the user to export the styles to the
 repository could change the style id.

 Then maybe we need to rethink all of this business of style
 identification and resolution, and where we want to be in the future
 as a community of implementers?

 The style ID is intended to be a globally unique, stable, identifier
 for the style. It makes no sense for there to be 50 ids for each of 50
 copies.

 50 ids for each 50 modifications of the given style makes sense, no?

Yeah, that's where thing get interesting and complicated!

Perhaps we need a way to indicate that a style is some revision of
another style? With documents and Dublin Core, this is done with
versionOf properties.

 Who is doing 50 copies of the style?

Sorry, I wasn't meaning there actually is 50 copies; just making a
conceptual point.

 In Mendeley we use the styleId from the repository
 (http://www.zotero.org/styles/ ones, would be ore clear to have the
 styleIds to http://citationstyles.org/styles/ ?). We only use the
 http://csl.mendeley.com/styles when a user edits the style.

OK; gotcha.

Bruce

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Sort collation question

2012-11-10 Thread Bruce D'Arcus

Frank - your impulse to look into broader (unicode) sorting collations
seems to me right. I don't want to get into rolling our solutions for
this kind of thing.

Bruce

On Sat, Nov 10, 2012 at 1:31 AM, Frank Bennett biercena...@gmail.com wrote:
A user on the Zotero forums has reported a sort result that apprently
differs from an example given in MLA Handbook 7th ed. The cause is inclusion
of a space in the sort, so that De Quincey (treating the De as part of the
last name) sorts as:

De Quincy
Deniehy

If the space were ignored, the order would be:

Deniehy
De Quincey

http://forums.zotero.org/discussion/20926/double-surnames-alphabetical-order-in-bibliography-solved/#Comment_138951

This behaviour appears to be a feature of the English Unicode collation.
I've scratched around a little for information on preferred sort methods,
but haven't found anything to add to the MLA example cited by user iselim in
the discussion linked above.

Stripping spaces from the processor sort keys would align behaviour with the
MLA example, but I don't know what general expectations are for sorting of
space characters (and hyphens...).

Can anyone offer clues on the specifics of bibliographic sort requirements,
and whether they vary across styles and locales?

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL in production chains?

2012-10-16 Thread Bruce D'Arcus

Is it even feasible to do that? I doubt it, since documents aren't
portable (they've have to mandate use of Zotero, or Mendeley).

On Tue, Oct 16, 2012 at 7:01 PM, Frank Bennett biercena...@gmail.com wrote:
 I have received a query about the use of CSL in production chains.

 Does anyone know of publishers or publishing projects that encourage
 or require the use of CSL tools?

 (I checked the FAQ on http://citationstyles.org/faq and came up dry,
 but maybe there have been developments since the last revision of the
 page?)

 Frank

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_sfd2d_oct
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL editor instance in http://citationstyles.org?

2012-10-11 Thread Bruce D'Arcus

On Thu, Oct 11, 2012 at 6:25 AM, Carles Pina carles.p...@mendeley.com wrote:

...

 We chose these tasks after reading and summarising support queries to
 Mendeley support (I think that it's quite aligned with the Zotero's
 forum questions). We found that the majority of the requests says I
 want this style but with this small change (because some particular
 need) or This style has this problem, how can I fix it?.

 I don't think that the CSL Editor is useful to create styles from the
 scratch (I hope that with the current number of styles no one will
 think a completely new approach to cite!), and probably it's not very
 useful to do major changes to the styles.

Wouldn't you agree, then, that this research suggests that a
productive next step for developers to explore would be something
higher-level to capture both of these classes of use cases: the simple
minor change in formatting, and the more radical major changes
(though I'm skeptical these actually exist when you consider the full
range of extant styles)?

E.g. for the first case, from the user perspective: see example
possibilities, and choose which they want?

Bruce

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL editor instance in http://citationstyles.org?

2012-10-11 Thread Bruce D'Arcus

On Thu, Oct 11, 2012 at 9:58 AM, Carles Pina carles.p...@mendeley.com wrote:
 Hi,

 On 11 October 2012 13:43, Bruce D'Arcus bdar...@gmail.com wrote:
 On Thu, Oct 11, 2012 at 6:25 AM, Carles Pina carles.p...@mendeley.com 
 wrote:

 ...

 We chose these tasks after reading and summarising support queries to
 Mendeley support (I think that it's quite aligned with the Zotero's
 forum questions). We found that the majority of the requests says I
 want this style but with this small change (because some particular
 need) or This style has this problem, how can I fix it?.

 I don't think that the CSL Editor is useful to create styles from the
 scratch (I hope that with the current number of styles no one will
 think a completely new approach to cite!), and probably it's not very
 useful to do major changes to the styles.

 Wouldn't you agree, then, that this research suggests that a
 productive next step for developers to explore would be something
 higher-level to capture both of these classes of use cases: the simple
 minor change in formatting, and the more radical major changes
 (though I'm skeptical these actually exist when you consider the full
 range of extant styles)?

 Some thoughts about creating styles from the scratch and the
 non-existing editor that facilities this task:
 My *personal* opinion (I'd be happy if someone proves that I'm
 wrong!): CSL is so complex and so rich that an editor to create styles
 from the scratch without knowing some advanced CSL concepts (macros,
 choose, variables, types) cannot be done... or, at least, I don't see
 at the moment how can be done. Again, I may be wrong.

I wonder: can we imagine some way to test this hypothesis? Maybe
making use of some previous work (say by Sylvester) that can analyze
style data?

My basic observation is we have 2000+ styles, with some hundreds of
unique styles. But those unique styles are often small variations on
what are no doubt a very small number of core/base styles.

If there was a way to quantify that somehow, it could help us
understand opportunities and constraints for future development?

Bruce

 We could build tools that may help someone to create styles from the
 scratch. For example, and we mentioned it here some time ago, based in
 re-using existing macros (e.g. list all the available macros in the
 repository, allow the user to re-use macros easily). But I don't see a
 way to start with an empty style and easily and friendly without
 understanding what happens internally build a style. I don't think
 also that this is a common use case that we should tackle now (perhaps
 some years ago yes).

 I know different attempts to do a graphical programming language (e.g.
 http://code.google.com/p/blockly/?redir=1 , and others). It helps to
 explain programming to people, but I don't see people using it too
 much. I know that it's a different scope, but I hope that it helps to
 explain my thoughts.

 Somehow it would be like building a Python/any programming language
 user interface. It can be done, but if you want to build things from
 the scratch you really need to understand what's underneath... tools
 helps, IDEs helps, but doesn't avoid of studying the programming
 language.

 (another way of thinking: lot of people doesn't agree that there is a
 good HTML editor. Lot of money and time has been invested in HTML
 editors and not everyone is satisfied. Recently it seems that the most
 common approach is to create tools like BaseKit
 -http://www.basekit.com- that offers different templates and then the
 users changes the templates. This is the way to go with getting macros
 together, and I still have doubts that this would work well enough).

 Regards,

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

 --
 Don't let slow site performance ruin your business. Deploy New Relic APM
 Deploy New Relic app performance management and know exactly
 what is happening inside your Ruby, Python, PHP, Java, and .NET app
 Try New Relic at no cost today and get our sweet Data Nerd shirt too!
 http://p.sf.net/sfu/newrelic-dev2dev
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists

Re: [xbiblio-devel] CSL editor instance in http://citationstyles.org?

2012-10-10 Thread Bruce D'Arcus

I definitely think it'd be a good idea. The site is hosted by the Zotero
guys. Am not sure whether we need their help to get it setup (perhaps not
because no db), or whether Rintze could do it (with help)?
On Oct 10, 2012 7:00 AM, Carles Pina carles.p...@mendeley.com wrote:

 Hi,

 Here at Mendeley we are working to integrate the CSL editor with our
 desktop application.

 But I still think that would make sense to have an instance of the CSL
 editor which one is not reference manager specific. In some place like
 http://citationstyles.org/editor

 Reference managers could send the users to this CSL editor instance
 instead of the http://steveridout.com/csl/visualEditor/ . And maybe
 Steve Ridout would like to not host it endless :-)

 I feel that it's important to keep the editor used by a wide
 community, to get feedback and ideas to improve it, bugs, etc. and
 also to build a community around it to see what next could happen.

 I'm happy to assist or install the editor in some server (I've done in
 a couple of test servers here). It requires an Apache, PHP server.
 Mysql not needed. The editor is mainly all done in Javascript. It's
 not complicated to install. If you want some help just write to me in
 private (instructions

 https://github.com/citation-style-editor/csl-editor-demo-site/blob/master/README.md
 but some experience may be handy).

 Is this possible? Does some of you think that could be useful?

 Regards,

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


 --
 Don't let slow site performance ruin your business. Deploy New Relic APM
 Deploy New Relic app performance management and know exactly
 what is happening inside your Ruby, Python, PHP, Java, and .NET app
 Try New Relic at no cost today and get our sweet Data Nerd shirt too!
 http://p.sf.net/sfu/newrelic-dev2dev
 ___
 xbiblio-devel mailing list
 xbiblio-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] Developing a CSL processor

2012-09-21 Thread Bruce D'Arcus

Are these mutually exclusive though?
On Sep 21, 2012 9:14 AM, Charles Parnot charles.par...@gmail.com wrote:

 Hi Rob,

 While the idea of pseudo-algorithms is attractive, I very much like the
 idea of fixtures being the specification instead. In the case of
 bibliogprahic software, this seems like a really good fit, as it's easy to
 discuss the output, and compare those to what's actually in books and
 articles (or common sense). The fixtures can be read by people that are not
 programmers, and this is a big plus as well: you can show them and discuss
 them with non-technical people that know the field. Discussing the
 algorithms to get to the actual results is not as useful IMO. Or at least
 if should not come first, and only be formalized when enough examples of
 the issue at hand have been produced. The disambiguation process is another
 one of the hair-rising issue.

 My 2 cents :-)

 Charles



 On Sep 21, 2012, at 11:44 AM, Robert Knight robert.kni...@mendeley.com
 wrote:

  For those reasons, the cull function can't work on the output string:
  it needs to analyse the nested structure before collapsing to identify
 adjacent
  punctuation. With content strings, delimiters and affixes in the mix,
  it's pretty hair-raising.
 
  W3C specifications often include pseudo-algorithms that
  implementations should follow.
  Perhaps it would make sense to try and do the same in the CSL spec?
 
  Regards,
  Rob.
 
  On 21 September 2012 10:22, Frank Bennett biercena...@gmail.com wrote:
  On Fri, Sep 21, 2012 at 4:16 PM, Rönkkö Mikko mikko.ron...@aalto.fi
 wrote:
  Hi
 
  Thanks for the response.
 
  On Sep 21, 2012, at 0:20 , Frank Bennett wrote:
 
  On Fri, Sep 21, 2012 at 4:47 AM, Rönkkö Mikko mikko.ron...@aalto.fi
 wrote:
  Hi
 
  I decided to develop a simple CSL processor to convert Zotero json
 strings
  to APA citations. The code will be used in ZotPad and after the
 processor
  works, I will publish the code as a separate project in gihub.
 
  I am using json strings from Zotero server  as data and validating
 the
  output against formatted citations from Zotero server. The citations
 are
  formatted using the APA style from
 
 https://github.com/citation-style-language/styles/blob/master/apa.cslusing
  the CSL 1.0.1 specification.
 
  I am using the following bibliography item as my test data
 
  Cadogan, J. W.,  Lee, N. (Forthcoming). Improper Use of Endogenous
  Formative Variables. iJournal of Business Research/i.
 
  There is one thing that I do not understand. In the APA style (lines
  429-434) there is a group
 
group delimiter=. 
  text macro=author/
  text macro=issued/
  text macro=title prefix= /
  text macro=container/
/group
 
 
  The macro author has a names element with initialize-with=.  and
 the
  macro issued contains a group with prefix  (. Now to my
 understanding,
  this means that
 
  - The author macro will end with . [Cadogan, J. W.,  Lee,
 N.]
  - The issued macro will start with  (   [ (Forthcoming)]
  - The macros are delimited with . 
 
  This results in a bibliographic item that starts by
 
  Cadogan, J. W.,  Lee, N..  (Forthcoming).
 
  This is obviously not correct. There should not be a double period
 followed
  by a double space, but I do not understand which part of the
 formatting
  logic is incorrect.
 
  Mikko
 
  Mikko,
 
  Below I've assumed that the output is from your project code. If I
  have it backwards, let me know.
 
  You are correct.
 
  The problem was that my implementation produces incorrect bibliography
 items even though the implementation follows the CSL specification. (Or a
 subset of the CSL specification, that is sufficient to produce bibliography
 items in the APA style). I did not know that strictly following the
 specification will not result in correct formatting, but the processor
 needs to be smart about spaces and punctuation. I could not find this in
 the documentation. But now that I know this, it should not be difficult to
 fix.
 
  I posted my code to https://github.com/mronkko/CSLProcessor
 
  At this point the goal is to format single citations and single
 bibliography items using the APA style. In the future I may make it more
 generic.
 
  Mikko
 
  This may be more distraction than you need at this point, but just in
 case ...
 
  There is a set of test fixtures covering space-suppression in the
  citeproc-js sources (scroll down to the fixtures prefixed with
  spaces_):
 
 
 https://bitbucket.org/fbennett/citeproc-js/src/5cc7cff350ee/tests/fixtures/local
 
  I didn't put the tests into the main test suite, because the
  discussion I linked above was inconclusive about whether it would be
  appropriate to recognise space-suppression in the official
  specification. The main test suite is here:
 
   https://bitbucket.org/bdarcus/citeproc-test
 
  The future of CSL processor testing probably lies in work by Sylvester
  Keil, which is here:

Re: [xbiblio-devel] csl-training - ideas for methods, good practice etc.

2012-09-19 Thread Bruce D'Arcus

On Wed, Sep 19, 2012 at 9:45 AM, Franziska Heimburger
franziska.heimbur...@gmail.com wrote:
Hello everyone,

I have come to source people's ideas for a 'codesprint' I have suggested for
next week's THATCamp Paris. The potted description in French is here
http://barcamp.org/w/page/54813952/Codesprint%20et%20Booksprint%2027-28%20septembre%20%28cliquer%20ici%29
, but the general idea is to explain the basics of csl style language and
then see how many styles we can turn out for French humanities and social
sciences. This takes up the initiative explained here
http://www.boiteaoutils.info/p/csl-france-styles-pour-zotero.html and hosted
here https://trello.com/board/csl-france/4e8f4ee92adc2a9616d3 which
never really took off.

I originally suggested this a long time ago and then started wondering
whether it was still a good idea when I saw the progress that had been made
on the visual style editor. In the end I decided to maintain the codesprint,
including actual code, because I reckon with the fairly tech-literate public
at the THATCamp it makes sense and it would be an excellent opportunity to
get more good French styles into the repository.

That makes sense. Hand coding for people confortable will yield better styles.

Great idea, BTW! More below

So far my plan is to assemble links to all the available documentation on
the page mentioned above with the necessary explanations in French, to start
the codesprint with a walk-through of adapting an existing style (located
using the visual editor tool), while explaining the structure of csl-styles.
I may well produce a very basic style with in-line comments in French
explaining what happens at each point.

So, this is where my questions come in :

has anyone ever held a similar initiative - and have any useful hints to
share?
What guidelines for good csl-practice would you want to teach a bunch of
beginners?

I only have one, two-part, suggestion here:

1) good styles exploit macros heavily to avoid duplication; you can
see evidence of this by the relative percentage of code dedicated to
macros vs. the citation and bibliography templates.
2) use an example style that is well-written to demonstrate. Rintze
and Sebastian may have good suggestions, but I tend to think a widely
used style like APA or Chicago is a good bet.

Bruce

finally, more specifically, when writing French styles, I got used to
including codes like #160; for non-breaking spaces and #232; for è - in
good part because I got tired of people opening/saving styles on different
operating systems and breaking accented character encodings. I remember that
being discouraged at some point on this list. What are people's opinions on
this?

I'd be very grateful for any advice you might have.
Thanks in advance,
Franziska Heimburger

--
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
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] csl-training - ideas for methods, good practice etc.

2012-09-19 Thread Bruce D'Arcus

On Wed, Sep 19, 2012 at 12:28 PM, Sebastian Karcher
karc...@u.northwestern.edu wrote:



 Where I somewhat disagree is that coding by hand is preferable. I think
 teaching how to work the visual editor effectively might be more useful and
 lend itself better to spread the word and the code it puts out is pretty
 clean.

This is an interesting strategic question. I'm open to having my mind
changed on this.

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
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL style content type (was: CSL editor update)

2012-09-13 Thread Bruce D'Arcus

On Thu, Sep 13, 2012 at 2:10 PM, Dan Stillman dstill...@zotero.org wrote:
 On 9/13/12 1:26 PM, Dan Stillman wrote:

 While we're on the subject, though, we should agree on a different
 content type for .csl files. Among other things, Safari (and possibly
 other browsers) will display text/* types rather than downloading
 them.*  x- is also considered bad practice these days.
 application/vnd.citationstyles.style? Zotero is using
 application/vnd.citationstyles.csl+json for CSL JSON data.


 It could also be application/vnd.citationstyles.style+xml,

I say we go with this.

Bruce

 since RFC3023
 recommends the use of +xml for XML-based media types. I don't think
 there's much to be gained from that, but there's also no particular reason
 not to do it.

 From http://www.ietf.org/rfc/rfc3023.txt:

 A.15 Why must I use the '+xml' suffix for my new XML-based media type?

You don't have to, but unless you have a good reason to explicitly
disallow generic XML processing, you should use the suffix so as not
to curtail the options of future users and developers.

Whether the inventors of a media type, today, design it for dispatch
to generic XML processing machinery (and most won't) is not the
critical issue.  The core notion is that the knowledge that some
media type happens to use XML syntax opens the door to unanticipated
kinds of processing beyond those envisioned by its inventors, and on
this basis identifying such encoding is a good and useful thing.

Developers of new media types are often tightly focused on a
particular type of processing that meets current needs.  But there is
no need to rule out generic processing as well, which could make your
media type more valuable over time.  It is believed that registering
with the '+xml' suffix will cause no interoperability problems
whatsoever, while it may enable significant new functionality and
interoperability now and in the future.  So, the conservative
approach is to include the '+xml' suffix.


 I don't have a strong preference here.

 --
 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
 xbiblio-devel@lists.sourceforge.net
 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
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Re: [xbiblio-devel] CSL style content type (was: CSL editor update)

2012-09-13 Thread Bruce D'Arcus

Does that really present any practical problems here though? We use
the csl. extension for the style files, which servers can use to
associate the correct mimetype with.

On Thu, Sep 13, 2012 at 2:19 PM, Charles Parnot
charles.par...@gmail.com wrote:
Nice. It's too bad we can't get github to serve specific mime types for raw
files:

http://stackoverflow.com/questions/3537575/can-git-store-the-mime-type-of-a-file-like-svn-does-for-browsing-html

charles

On Sep 13, 2012, at 8:15 PM, Bruce D'Arcus bdar...@gmail.com wrote:

On Thu, Sep 13, 2012 at 2:10 PM, Dan Stillman dstill...@zotero.org wrote:
On 9/13/12 1:26 PM, Dan Stillman wrote:

While we're on the subject, though, we should agree on a different
content type for .csl files. Among other things, Safari (and possibly
other browsers) will display text/* types rather than downloading
them.* x- is also considered bad practice these days.
application/vnd.citationstyles.style? Zotero is using
application/vnd.citationstyles.csl+json for CSL JSON data.

It could also be application/vnd.citationstyles.style+xml,

I say we go with this.

Bruce

since RFC3023
recommends the use of +xml for XML-based media types. I don't think
there's much to be gained from that, but there's also no particular reason
not to do it.

From http://www.ietf.org/rfc/rfc3023.txt:

A.15 Why must I use the '+xml' suffix for my new XML-based media type?

You don't have to, but unless you have a good reason to explicitly
disallow generic XML processing, you should use the suffix so as not
to curtail the options of future users and developers.

Whether the inventors of a media type, today, design it for dispatch
to generic XML processing machinery (and most won't) is not the
critical issue. The core notion is that the knowledge that some
media type happens to use XML syntax opens the door to unanticipated
kinds of processing beyond those envisioned by its inventors, and on
this basis identifying such encoding is a good and useful thing.

Developers of new media types are often tightly focused on a
particular type of processing that meets current needs. But there is
no need to rule out generic processing as well, which could make your
media type more valuable over time. It is believed that registering
with the '+xml' suffix will cause no interoperability problems
whatsoever, while it may enable significant new functionality and
interoperability now and in the future. So, the conservative
approach is to include the '+xml' suffix.

I don't have a strong preference here.

--
Charles Parnot
charles.par...@gmail.com
twitter: @cparnot
http://mekentosj.com

[xbiblio-devel] node-elementtree

2012-09-10 Thread Bruce D'Arcus

IIRC, the lack of a good XML parser has presented some impediments to
citeproc-node. Here's a new one that might be promising?

https://github.com/racker/node-elementtree

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
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

1 2 >

1 - 100 of 188 matches

Mail list logo