[CODE4LIB] marc in json
Martin Czygan recently added JSON support to pymarc [1]. Before this gets rolled into a release I was wondering if it might make sense to bring the implementation in line with Ross Singer's proposed JSON serialization for MARC [2]. After quickly looking around it seems to be what got implemented in ruby-marc [3] and PHP's File_MARC [4]. It also looked like there was a MARC::Record branch [5] for doing something similar, but I'm not sure if that has been released yet. It seems like a no-brainer to bring it in line, but I thought I'd ask since I haven't been following the conversation closely. //Ed [1] https://github.com/edsu/pymarc/commit/245ea6d7bceaec7215abe788d61a0b34a6cd849e [2] http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/ [3] https://github.com/ruby-marc/ruby-marc/blob/master/lib/marc/record.rb#L227 [4] http://pear.php.net/package/File_MARC/docs/latest/File_MARC/File_MARC_Record.html#methodtoJSON [5] http://marcpm.git.sourceforge.net/git/gitweb.cgi?p=marcpm/marcpm;a=shortlog;h=refs/heads/marc-json
Re: [CODE4LIB] Library News (à la ycombinator's hackernews)
On Wed, Nov 30, 2011 at 10:51 PM, Matthew Phillips mphill...@law.harvard.edu wrote: I'm the guy that did the hacking (with help from my coworkers, Jeff and David) to get Hacker News up and running. If you have technical questions about the site, shoot them my way. Nice work. It's great to see it starting to get used. Mark is right, Library News is running the news.arc source from https://github.com/nex3/arc I had to do a little customization, but the code worked out of the box for me. I'm really interested in seeing Library News blossom. If you have input, please share it. I'd also be excited to get a couple of community leaders to become moderators for the site (drop me an email if you want to volunteer yourself/someone). I noticed that news.arc has some RSS functionality [1]. Does it seem easy/possible to add a link element to the RSS feeds to the HTML, e.g. link rel=alternate type=application/rss+xml title=Library News href=http://news.librarycloud.org/rss; //Ed [1] https://github.com/nex3/arc/blob/master/news.arc#L2239
Re: [CODE4LIB] Pandering for votes for code4lib sessions
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I have mixed feelings on the idea of requiring a minimum weight in the voting process. Vote pandering is definitely a real issue, but I think imposing strictures on the voting process goes a little bit against something fundamental about Code4Lib's anarcho-democratic underpinnings. I think one of the values of the weighted approval voting is that there's the flexibility to use the weightings to vote with a particular agenda -- in this case we happen not to care for the agenda, but one could imagine many agenda-ized voting approaches that are totally aboveboard. I don't know if ecorrado's suggestion of moving the presentation voting before registration would be a true fix, but it might smooth out the process a little bit. On the other hand, it might just shift the vote pandering from one group of people to another. Here's another idea: maybe we can set a deadline for new Code4Lib accounts, after which newly created accounts are not eligible for voting. This deadline could be some time after proposals are due but before voting opens. This might help stop a flood of new ballotstuffing accounts and help to mitigate this sort of problem. -dre. On Thu, Dec 1, 2011 at 8:06 AM, Lynch,Katherine ke...@drexel.edu wrote: I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] Professional development advice?
On Thu, Dec 1, 2011 at 2:13 AM, Seth Robbins robbins...@gmail.com wrote: Which brings me to my original reason for posting: Is there, at present, a publicly available subject guide for librarian coders that anyone knows of? and would anyone be interested in collaborating on such a guide even if just to give feedback. As a starting point, there's A Guide for the Perplexed on the Code4lib wiki: http://wiki.code4lib.org/index.php/A_Guide_for_the_Perplexed I'd be strongly in favor of us fleshing that out significantly. Mark
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I disagree with this suggestion. Personally I vote for only those I find interesting and useful to me, but I don't put an response for every talk listed. I only respond on those I'm interested. Everyone else gets 0 points. I would expect that others do this, too. Katherine's suggestion also puts an burden on those who are legitimately participating while doing nothing to prevent those who are misbehaving. I like Edwards's suggestions, which are easy to implement and don't really impact the process that much. Personally, I believe that the proper response to this is to: 1. Publicly shame those who are participating in this. :) 2. Delete their votes, or at least those you can identify. 3. Disqualify the person who is receiving illegitimate votes. See #1. 4. Eliminate voting altogether and have a committee of 10-15 people from the community select from the proposed talks. Isn't this what other conferences do? In the end, the conference organizers can invite whoever they want to speak. The voting ends up being a courtesy to the rest of us. --Joel Joel Richard Lead Web Developer, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | richar...@si.edu On Dec 1, 2011, at 8:06 AM, Lynch,Katherine wrote: I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] Pandering for votes for code4lib sessions
Deleting votes is a risky business, and disqualifying the speaker is somewhat harsh. What would be the criteria for votes eliminated, if we can't factor the number of sessions they vote for into the process? Wouldn't giving encouragement to vote on all sessions--even if your vote is 0--not put a burden on any one group, but rather encourage people who are voting to not just give input on the sessions they like, but on all sessions? Also to clarify, this is not a suggestion to enforce a minimum number of votes before anything gets counted. Just as there are machine-readable ways to tell if a user is human, this could be a machine-readable way for the system to tell if the human is someone interested in actually attending Code4Lib, or at the very least is truly interested in evaluating the sessions, rather than a colleague, friend, or coworker of someone stumping for votes, who will register to vote for one session then fall off the face of the earth. Sincerely, Katherine On 12/1/11 8:32 AM, Richard, Joel M richar...@si.edu wrote: I disagree with this suggestion. Personally I vote for only those I find interesting and useful to me, but I don't put an response for every talk listed. I only respond on those I'm interested. Everyone else gets 0 points. I would expect that others do this, too. Katherine's suggestion also puts an burden on those who are legitimately participating while doing nothing to prevent those who are misbehaving. I like Edwards's suggestions, which are easy to implement and don't really impact the process that much. Personally, I believe that the proper response to this is to: 1. Publicly shame those who are participating in this. :) 2. Delete their votes, or at least those you can identify. 3. Disqualify the person who is receiving illegitimate votes. See #1. 4. Eliminate voting altogether and have a committee of 10-15 people from the community select from the proposed talks. Isn't this what other conferences do? In the end, the conference organizers can invite whoever they want to speak. The voting ends up being a courtesy to the rest of us. --Joel Joel Richard Lead Web Developer, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | richar...@si.edu On Dec 1, 2011, at 8:06 AM, Lynch,Katherine wrote: I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] Pandering for votes for code4lib sessions
As unwilling commissioner of elections, I'm shocked, SHOCKED, I say, to hear of improprieties with the voting process. That said, I'm not shocked (and we've seen it before). I am absolutely opposed to: 1) Setting weights on voting. 0 is just as valid a vote as 3. 2) Publicly shaming the offenders in Code4Lib. If you run across impropriety in a forum, make a friendly, yet firm, reminder that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib. Sometimes it just takes a simple reminder for people to realize what they're doing is wrong (it certainly works for me). 3) Selection committees. We are, as Dre points out, anarcho-democratic as our core. anarcho-bureaucratic just sounds silly. This current situation is largely our doing. We even publicly said that getting your proposal voted in is the backdoor into the conference. The first allotment of spaces sold out in an hour. This is, literally, the only way that a person that was not able to register and is buried on the wait list is going to get in. And we've basically told them that. One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? -Ross. On Thu, Dec 1, 2011 at 8:32 AM, Richard, Joel M richar...@si.edu wrote: I disagree with this suggestion. Personally I vote for only those I find interesting and useful to me, but I don't put an response for every talk listed. I only respond on those I'm interested. Everyone else gets 0 points. I would expect that others do this, too. Katherine's suggestion also puts an burden on those who are legitimately participating while doing nothing to prevent those who are misbehaving. I like Edwards's suggestions, which are easy to implement and don't really impact the process that much. Personally, I believe that the proper response to this is to: 1. Publicly shame those who are participating in this. :) 2. Delete their votes, or at least those you can identify. 3. Disqualify the person who is receiving illegitimate votes. See #1. 4. Eliminate voting altogether and have a committee of 10-15 people from the community select from the proposed talks. Isn't this what other conferences do? In the end, the conference organizers can invite whoever they want to speak. The voting ends up being a courtesy to the rest of us. --Joel Joel Richard Lead Web Developer, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | richar...@si.edu On Dec 1, 2011, at 8:06 AM, Lynch,Katherine wrote: I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Dec 1, 2011, at 8:34 AM, Richard, Joel M richar...@si.edu wrote: In the end, the conference organizers can invite whoever they want to speak. The voting ends up being a courtesy to the rest of us. --Joel Joel Richard Lead Web Developer, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | richar...@si.edu This indicates a massive misunderstanding of how code4lib works. -Sean On Dec 1, 2011, at 8:06 AM, Lynch,Katherine wrote: I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
Re: [CODE4LIB] marc in json
Ed, I think this would be great. Obviously, there's zero standardization around MARC/JSON (Andrew Houghton has come the closest by writing up the most RFC-y proposal: http://www.oclc.org/developer/content/marc-json-draft-2010-03-11). I generally fall more in the camp of working code wins, though, which, solely on the basis of MARC parser support, would put my proposal in front. In the end, I don't think it matters which style is adopted; it's an interchange format, any one of them works (and they all, including Bill Dueber's) has their pluses and minuses. The more important thing is that we pick -one- and go with it so we can use it with some confidence. While we're on the subject, if there are any other serializations of MARC that people are legitimately interested in (TurboMARC, for example: https://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records) and wish ruby-marc supported, let me know. Thanks, -Ross. On Thu, Dec 1, 2011 at 5:57 AM, Ed Summers e...@pobox.com wrote: Martin Czygan recently added JSON support to pymarc [1]. Before this gets rolled into a release I was wondering if it might make sense to bring the implementation in line with Ross Singer's proposed JSON serialization for MARC [2]. After quickly looking around it seems to be what got implemented in ruby-marc [3] and PHP's File_MARC [4]. It also looked like there was a MARC::Record branch [5] for doing something similar, but I'm not sure if that has been released yet. It seems like a no-brainer to bring it in line, but I thought I'd ask since I haven't been following the conversation closely. //Ed [1] https://github.com/edsu/pymarc/commit/245ea6d7bceaec7215abe788d61a0b34a6cd849e [2] http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/ [3] https://github.com/ruby-marc/ruby-marc/blob/master/lib/marc/record.rb#L227 [4] http://pear.php.net/package/File_MARC/docs/latest/File_MARC/File_MARC_Record.html#methodtoJSON [5] http://marcpm.git.sourceforge.net/git/gitweb.cgi?p=marcpm/marcpm;a=shortlog;h=refs/heads/marc-json
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Thu, Dec 1, 2011 at 08:47, Ross Singer rossfsin...@gmail.com wrote: One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1 to the proposal, and I agree completely with Ross. -Mike
Re: [CODE4LIB] marc in json
FWIW, I wrote a proof of concept for this when there was discussion about it on perl4lib: http://search.cpan.org/dist/MARC-Utils-MARC2MARC_in_JSON/ It also includes code for iterating over a multi-record file based on my ideas here: http://en.wikipedia.org/wiki/User:Baxter.brad/Drafts/JSON_Document_Streaming_Proposal The caveat here is that my ideas came from a misunderstanding of what Ross meant by advertise in the following sentence. I think he was really referring to content type headers. It’s hard to justify newline delimited JSON until there is some standardized way to advertise it. So, again, FWIW. Regards, Brad On Thu, Dec 1, 2011 at 5:57 AM, Ed Summers e...@pobox.com wrote: Martin Czygan recently added JSON support to pymarc [1]. Before this gets rolled into a release I was wondering if it might make sense to bring the implementation in line with Ross Singer's proposed JSON serialization for MARC [2]. After quickly looking around it seems to be what got implemented in ruby-marc [3] and PHP's File_MARC [4]. It also looked like there was a MARC::Record branch [5] for doing something similar, but I'm not sure if that has been released yet. It seems like a no-brainer to bring it in line, but I thought I'd ask since I haven't been following the conversation closely. //Ed [1] https://github.com/edsu/pymarc/commit/245ea6d7bceaec7215abe788d61a0b34a6cd849e [2] http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/ [3] https://github.com/ruby-marc/ruby-marc/blob/master/lib/marc/record.rb#L227 [4] http://pear.php.net/package/File_MARC/docs/latest/File_MARC/File_MARC_Record.html#methodtoJSON [5] http://marcpm.git.sourceforge.net/git/gitweb.cgi?p=marcpm/marcpm;a=shortlog;h=refs/heads/marc-json
Re: [CODE4LIB] Pandering for votes for code4lib sessions
One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1 to the proposal to have some sort of honor statement splash page before the ballot. This seems like a good first step at trying to address this, and may be as much as we want to do. Jason
Re: [CODE4LIB] marc in json
I've worked to deprecate marc-hash (what tends to be referred to as Bill Dueber's JSON format) in favor of Ross's marc-in-json. To the best of my knowledge, there is marc-in-json support for ruby (current ruby-marc), PHP (current File_MARC), marc4j (currently in trunk, soon to be released, I think), and perl (MARC::Record in the next release). I think that covers all the major players except the IndexData yaz- stuff. [Galen, any word on that next release of the perl module?] I, at least, already use marc-in-json in production (It's a great way to store MARC in solr). It would be great if folks would have the confidence to use it, at least as a single-record format. I think for wider adoption we'll need to all have either (a) json pull-parsers to read in a file that contains an array of marc-in-json objects, or (b) a decision to use newline-delimited-json (or some other record-delimiter), so folks can put more than one of these in a file and be able to get them out without running out of memory. -Bill- On Thu, Dec 1, 2011 at 9:11 AM, Ross Singer rossfsin...@gmail.com wrote: Ed, I think this would be great. Obviously, there's zero standardization around MARC/JSON (Andrew Houghton has come the closest by writing up the most RFC-y proposal: http://www.oclc.org/developer/content/marc-json-draft-2010-03-11). I generally fall more in the camp of working code wins, though, which, solely on the basis of MARC parser support, would put my proposal in front. In the end, I don't think it matters which style is adopted; it's an interchange format, any one of them works (and they all, including Bill Dueber's) has their pluses and minuses. The more important thing is that we pick -one- and go with it so we can use it with some confidence. While we're on the subject, if there are any other serializations of MARC that people are legitimately interested in (TurboMARC, for example: https://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records) and wish ruby-marc supported, let me know. Thanks, -Ross. On Thu, Dec 1, 2011 at 5:57 AM, Ed Summers e...@pobox.com wrote: Martin Czygan recently added JSON support to pymarc [1]. Before this gets rolled into a release I was wondering if it might make sense to bring the implementation in line with Ross Singer's proposed JSON serialization for MARC [2]. After quickly looking around it seems to be what got implemented in ruby-marc [3] and PHP's File_MARC [4]. It also looked like there was a MARC::Record branch [5] for doing something similar, but I'm not sure if that has been released yet. It seems like a no-brainer to bring it in line, but I thought I'd ask since I haven't been following the conversation closely. //Ed [1] https://github.com/edsu/pymarc/commit/245ea6d7bceaec7215abe788d61a0b34a6cd849e [2] http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/ [3] https://github.com/ruby-marc/ruby-marc/blob/master/lib/marc/record.rb#L227 [4] http://pear.php.net/package/File_MARC/docs/latest/File_MARC/File_MARC_Record.html#methodtoJSON [5] http://marcpm.git.sourceforge.net/git/gitweb.cgi?p=marcpm/marcpm;a=shortlog;h=refs/heads/marc-json -- Bill Dueber Library Systems Programmer University of Michigan Library
Re: [CODE4LIB] Pandering for votes for code4lib sessions
One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1 I agree with Ross on all points here. In this age of blatant viral campaigns -- e.g., a band putting a link on their homepage asking their fans to vote them up in a best of category -- I don't feel outrage on this issue ... although I think it coasts along the edge of ethicality. And I have to ask the question (since I really don't know): was the amount of ballot stuffing that occurred sufficiently large that it could actually swamp legitimate votes? Tom
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Dec 1, 2011, at 8:47 AM, Ross Singer wrote: I am absolutely opposed to: 1) Setting weights on voting. 0 is just as valid a vote as 3. 2) Publicly shaming the offenders in Code4Lib. If you run across impropriety in a forum, make a friendly, yet firm, reminder that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib. Sometimes it just takes a simple reminder for people to realize what they're doing is wrong (it certainly works for me). Good point, forums are public, too. 'Nuff said. :) 3) Selection committees. We are, as Dre points out, anarcho-democratic as our core. anarcho-bureaucratic just sounds silly. Even though I suggested it, I am also ambivalent about it. Selection committees can often seem arbitrary, but then so is rigging an election. :) This current situation is largely our doing. We even publicly said that getting your proposal voted in is the backdoor into the conference. The first allotment of spaces sold out in an hour. This is, literally, the only way that a person that was not able to register and is buried on the wait list is going to get in. And we've basically told them that. I agree with this sentiment, too. But I feel that if someone wanted votes for their talk, they could have campaigned on this very mailing list. Hey, I was REALLY hoping to go, but I was in a confounded meeting all morning and missed registration! P-p-p-lease vote for my talk so I can go! I promise I'll bring cookies and pictures of monkeys and robots. Maybe it would have worked, but we'll never know. Nor will we be certain to have pictures of monkeys and robots. One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1. Nothing wrong with gentle reminders. I feel this whole situation has tainted things somewhat. :( --Joel
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I too agree that the two things we should do are: present a clear statement on how session selection works; and craft a statement on ethics that will be so artful as to actually discourage virtual ballot box stuffing and not just put evil ideas in folks; heads. On my part, I have had my dogs sign a pledge that they will never vote on any of my proposed sessions. Cary On Thu, Dec 1, 2011 at 6:40 AM, Jason Ronallo jrona...@gmail.com wrote: One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1 to the proposal to have some sort of honor statement splash page before the ballot. This seems like a good first step at trying to address this, and may be as much as we want to do. Jason -- Cary Gordon The Cherry Hill Company http://chillco.com
Re: [CODE4LIB] Software Developer position @ Penn State
-Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael J. Giarlo Sent: Thursday, December 01, 2011 9:55 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] Software Developer position @ Penn State Come hack on Ruby on Rails, jQuery, Hydra, Blacklight, Fedora, and Solr with our team: http://j.mp/rudzTl The Libraries and Information Technology Services are working together to create institutional curation and publishing services. This position is part of a five-person software development team working on web applications and tools, in support of these services, to track bits, publish bits to the web, and care for the bits so that they remain hale and hearty. We 3 the bits; do you? Working at the University Park campus of Penn State has its perks: generous benefits, great public schools, affordable real estate, proximity to things natural, and neighborhoods lined with trees and views of the Alleghenies. -Mike
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Thu, Dec 1, 2011 at 10:09 AM, Richard, Joel M richar...@si.edu wrote: I feel this whole situation has tainted things somewhat. :( Let's not blow things out of proportion. The aforementioned wrong-doing actually seems pretty innocent (there is backstory in the IRC channel, I'm not going to bring it up here). There is a valid case for advertising interest in your talks (or location, or t-shirt design, etc.), especially in an extremely crowded field, and we've never explicitly set a policy around what is appropriate and what isn't. I think a simple edit on the part of the accused would clear up any ambiguity of intention. Our one known incident was handled privately, but didn't really cause us to address the potential for impropriety. We seem to have quite a bit of support for the splash page. If people will help me draft up the wording -- ideally something we can point to when we want to guide people in the right direction in other forums -- I think we can put this issue to bed. -Ross.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Dec 1, 2011, at 8:47 AM, Ross Singer wrote: As unwilling commissioner of elections, I'm shocked, SHOCKED, I say, to hear of improprieties with the voting process. It could be worse ... I'm an unwilling elected official. (and the re-election for my third term is next month ... anyone want to move to Upper Marlboro, MD, so they can run against me? I think you still have about a week to make the 30 day residency deadline) (maybe 'unwilling' is the wrong word, before this shows up in the local newspaper ... I'll do it, but I think someone with more free time to commit might be able to do a better job) That said, I'm not shocked (and we've seen it before). I am absolutely opposed to: 1) Setting weights on voting. 0 is just as valid a vote as 3. 2) Publicly shaming the offenders in Code4Lib. If you run across impropriety in a forum, make a friendly, yet firm, reminder that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib. Sometimes it just takes a simple reminder for people to realize what they're doing is wrong (it certainly works for me). 3) Selection committees. We are, as Dre points out, anarcho-democratic as our core. anarcho-bureaucratic just sounds silly. It'd be (anarcho-)?republican, as you'd have a smaller body that's appointed or elected to make the decisions. This current situation is largely our doing. We even publicly said that getting your proposal voted in is the backdoor into the conference. The first allotment of spaces sold out in an hour. This is, literally, the only way that a person that was not able to register and is buried on the wait list is going to get in. And we've basically told them that. Perhaps if registration were done after the talk selection, this wouldn't be a problem? Or some sort of lottery, rather than first-come-first served? ... and the real way to ensure a slot is to help with the conference planning ... if you've agreed to man the table where people get their badges, they normally let you come. One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? I'd like to know if this is even a problem -- is there some way to tell if we have people who only voted for one paper? (although, just putting that as a restriction just makes 'em likely to vote for a few random ones, which really does taint the whole process) -Joe
Re: [CODE4LIB] Pandering for votes for code4lib sessions
Also, I should note, that the alleged pandering has not helped them much, if at all, so far. -Ross. On Thu, Dec 1, 2011 at 10:29 AM, Ross Singer rossfsin...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:09 AM, Richard, Joel M richar...@si.edu wrote: I feel this whole situation has tainted things somewhat. :( Let's not blow things out of proportion. The aforementioned wrong-doing actually seems pretty innocent (there is backstory in the IRC channel, I'm not going to bring it up here). There is a valid case for advertising interest in your talks (or location, or t-shirt design, etc.), especially in an extremely crowded field, and we've never explicitly set a policy around what is appropriate and what isn't. I think a simple edit on the part of the accused would clear up any ambiguity of intention. Our one known incident was handled privately, but didn't really cause us to address the potential for impropriety. We seem to have quite a bit of support for the splash page. If people will help me draft up the wording -- ideally something we can point to when we want to guide people in the right direction in other forums -- I think we can put this issue to bed. -Ross.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Dec 1, 2011, at 10:29 AM, Ross Singer wrote: On Thu, Dec 1, 2011 at 10:09 AM, Richard, Joel M richar...@si.edu wrote: I feel this whole situation has tainted things somewhat. :( Let's not blow things out of proportion. The aforementioned wrong-doing actually seems pretty innocent (there is backstory in the IRC channel, I'm not going to bring it up here). There is a valid case for advertising interest in your talks (or location, or t-shirt design, etc.), especially in an extremely crowded field, and we've never explicitly set a policy around what is appropriate and what isn't. I think a simple edit on the part of the accused would clear up any ambiguity of intention. Our one known incident was handled privately, but didn't really cause us to address the potential for impropriety. We seem to have quite a bit of support for the splash page. If people will help me draft up the wording -- ideally something we can point to when we want to guide people in the right direction in other forums -- I think we can put this issue to bed. It depends on how harsh you want be ... I mean, if you're on the fence about ballot stuffing, you could go with something like: When voting, we expect you to actually read through the list, and pick the best ones. So yes, go ahead and vote for your friends and colleagues, but also read through the others to find other equally good proposals. -Joe
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Thu, Dec 1, 2011 at 9:08 AM, Michael J. Giarlo leftw...@alumni.rutgers.edu wrote: On Thu, Dec 1, 2011 at 08:47, Ross Singer rossfsin...@gmail.com wrote: One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1 to the proposal, and I agree completely with Ross. I'll add a +1 to this as well. After all, my two suggestions are only helpful in the future. However, I really still would like to see one of the two implemented (only registered people vote or vote before registration). Edward -Mike
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Thu, Dec 1, 2011 at 10:35, Ross Singer rossfsin...@gmail.com wrote: Also, I should note, that the alleged pandering has not helped them much, if at all, so far. And, also also, this happens just about every year with just about every vote; if Code4Lib is tainted, it happened years ago and we've still put on excellent conferences. -Mike
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Thu, Dec 1, 2011 at 6:59 AM, Tom Keays tomke...@gmail.com wrote: One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? +1 I agree with Ross on all points here. I'm also a +1 with all the points Ross makes and with the splash page idea. Kevin
Re: [CODE4LIB] Pandering for votes for code4lib sessions
This is true, and something I didn't even think of. Ballot stuffers don't seem to be able to have the impact of a good proposal. If they did, some pretty strange schedules would probably have emerged by now. :) On 12/1/11 10:35 AM, Ross Singer rossfsin...@gmail.com wrote: Also, I should note, that the alleged pandering has not helped them much, if at all, so far. -Ross. On Thu, Dec 1, 2011 at 10:29 AM, Ross Singer rossfsin...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:09 AM, Richard, Joel M richar...@si.edu wrote: I feel this whole situation has tainted things somewhat. :( Let's not blow things out of proportion. The aforementioned wrong-doing actually seems pretty innocent (there is backstory in the IRC channel, I'm not going to bring it up here). There is a valid case for advertising interest in your talks (or location, or t-shirt design, etc.), especially in an extremely crowded field, and we've never explicitly set a policy around what is appropriate and what isn't. I think a simple edit on the part of the accused would clear up any ambiguity of intention. Our one known incident was handled privately, but didn't really cause us to address the potential for impropriety. We seem to have quite a bit of support for the splash page. If people will help me draft up the wording -- ideally something we can point to when we want to guide people in the right direction in other forums -- I think we can put this issue to bed. -Ross.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I will speak to this one time and then I am done. My attempts at advertising the vote were to make more people aware of it and to get more votes in general. That is the democratic way. In fact there have been comments added to these posts on our OLE blog from code4lib members. During my time in hosting the event I met many new comers to the conference who were unaware of the voting no matter how much publicity we did for that for the proposals as well as for the keynotes. I was just trying to get some publicity for the conference, especially since I am a sponsor. If my posts are causing you problems I am glad to change them to fit to whatever policy you may have on voting but that is the thing this is an unconference so there are not really any policies on voting other than an interest and a code4ilb account, and in fact this process is confusing to first timers. Ross is right this has not really helped our OLE proposals but it has gotten more votes for the conference I bet and more publicity for the upcoming conference which is as stated sold out. Please do let me know if your policy changes and I can reflect that in posts I use to publicize your event or if there are other policies on publicizing your event that myself or other sponsors or even event volunteers should know about. My efforts were only done with the best intentions of getting the word out about your event and those of you who know me I am sure will understand that. Cheers Robert ** Robert H. McDonald Associate Dean for Library Technologies and Digital Libraries Associate Director, Data to Insight Center-Pervasive Technology Institute Executive Director, Kuali OLE Indiana University Herman B Wells Library 234 1320 East 10th Street Bloomington, IN 47405 Phone: 812-856-4834 Email: rob...@indiana.edu Skype/GTalk: rhmcdonald AIM/MSN: rhmcdonald1
Re: [CODE4LIB] Pandering for votes for code4lib sessions
Ross: +1 to the disclaimer splash page. That seems to be the best way to maintain our faith in humanity to do the right thing. Dan
Re: [CODE4LIB] marc in json
Yes, use marc-in-json. We should add read support as well while we're at it. On Thu, Dec 1, 2011 at 5:57 AM, Ed Summers e...@pobox.com wrote: Martin Czygan recently added JSON support to pymarc [1]. Before this gets rolled into a release I was wondering if it might make sense to bring the implementation in line with Ross Singer's proposed JSON serialization for MARC [2]. After quickly looking around it seems to be what got implemented in ruby-marc [3] and PHP's File_MARC [4]. It also looked like there was a MARC::Record branch [5] for doing something similar, but I'm not sure if that has been released yet. It seems like a no-brainer to bring it in line, but I thought I'd ask since I haven't been following the conversation closely. //Ed [1] https://github.com/edsu/pymarc/commit/245ea6d7bceaec7215abe788d61a0b34a6cd849e [2] http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/ [3] https://github.com/ruby-marc/ruby-marc/blob/master/lib/marc/record.rb#L227 [4] http://pear.php.net/package/File_MARC/docs/latest/File_MARC/File_MARC_Record.html#methodtoJSON [5] http://marcpm.git.sourceforge.net/git/gitweb.cgi?p=marcpm/marcpm;a=shortlog;h=refs/heads/marc-json
Re: [CODE4LIB] Pandering for votes for code4lib sessions
Robert, you raise an extremely valid point. Last year we had 129 unique voters for the proposals, roughly unchanged from Asheville (119). Both cases FAR fewer than the number of delegates (and more importantly, the number of people that wanted to be delegates). Now, any citizen of a western-style democracy knows that 40-something percent turnout for an election is generally an indicator of electoral ambivalence (or a general trust that their fellow citizens aren't going to elect Pol Pot), but I have a sinking feeling that Code4Lib (based on the crush to get in the door) is no western-style democracy. These numbers, to me, sound far more like ignorance of the system than antipathy. The lack of emails I get every year about the diebold-o-tron from people that don't understand how to sign up, vote, etc. also makes my spidey sense tingle. As I stated previously, I would expect people to advertise their talks to differentiate themselves from the pack (and, in this year's case, a VERY large pack). That fact that we don't have any consistent policy written anywhere, if somebody has a grievance with somebody else's actions, is our own fault. We have some guidelines in the CFP: Prepared talks are 20 minutes (including setup and questions), and focus on one or more of the following areas: * tools (some cool new software, software library or integration platform) * specs (how to get the most out of some protocols, or proposals for new ones) * challenges (one or more big problems we should collectively address) The community will vote on proposals using the criteria of: * usefulness * newness * geekiness * diversity of topics Please follow the formatting guidelines: == Talk Title: == * Speaker's name, affiliation, and email address * Second speaker's name, affiliation, email address, if second speaker Abstract of no more than 500 words. but if people feel strongly about this, we should really have something we can point to (not saying anything's enforceable, of course) to try to rectify the situation before people start complaining publicly over nothing. Honestly, we should have quite a few more policies, as well (conduct/behavior, harassment, etc. -- things you don't want to have to address after the fact), but the precedent needs to start somewhere. -Ross. p.s. 133 voters, so far, this year. On Thu, Dec 1, 2011 at 11:23 AM, McDonald, Robert H. rhmcd...@indiana.edu wrote: I will speak to this one time and then I am done. My attempts at advertising the vote were to make more people aware of it and to get more votes in general. That is the democratic way. In fact there have been comments added to these posts on our OLE blog from code4lib members. During my time in hosting the event I met many new comers to the conference who were unaware of the voting no matter how much publicity we did for that for the proposals as well as for the keynotes. I was just trying to get some publicity for the conference, especially since I am a sponsor. If my posts are causing you problems I am glad to change them to fit to whatever policy you may have on voting but that is the thing this is an unconference so there are not really any policies on voting other than an interest and a code4ilb account, and in fact this process is confusing to first timers. Ross is right this has not really helped our OLE proposals but it has gotten more votes for the conference I bet and more publicity for the upcoming conference which is as stated sold out. Please do let me know if your policy changes and I can reflect that in posts I use to publicize your event or if there are other policies on publicizing your event that myself or other sponsors or even event volunteers should know about. My efforts were only done with the best intentions of getting the word out about your event and those of you who know me I am sure will understand that. Cheers Robert ** Robert H. McDonald Associate Dean for Library Technologies and Digital Libraries Associate Director, Data to Insight Center-Pervasive Technology Institute Executive Director, Kuali OLE Indiana University Herman B Wells Library 234 1320 East 10th Street Bloomington, IN 47405 Phone: 812-856-4834 Email: rob...@indiana.edu Skype/GTalk: rhmcdonald AIM/MSN: rhmcdonald1
Re: [CODE4LIB] marc in json
On Thu, Dec 1, 2011 at 9:41 AM, Bill Dueber b...@dueber.com wrote: I, at least, already use marc-in-json in production (It's a great way to store MARC in solr). It would be great if folks would have the confidence to use it, at least as a single-record format. I think for wider adoption we'll need to all have either (a) json pull-parsers to read in a file that contains an array of marc-in-json objects, or (b) a decision to use newline-delimited-json (or some other record-delimiter), so folks can put more than one of these in a file and be able to get them out without running out of memory. I suspect newline-delimited will win this race.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I would also mention that we generally expect people voting to either plan to at least potentially attend the conference, or have a prior participation/affiliation/interest in the Code4Lib Community. We're not expecting random people to be voting just for the hell of it, or to help our a freind with a proposal. (I also don't think the 'incident' of 'vote pandering' is all that awful or there was much reason for the 'perpetrator' to have expected anyone would have a problem with it. I do think when we have a system of open voting like we have, we should have a statement of what we expect from voters, however, that they have to read before voting. Which will keep people from accidentally violating community standards they didn't even know existed. ) On 12/1/2011 10:40 AM, Joe Hourcle wrote: On Dec 1, 2011, at 10:29 AM, Ross Singer wrote: On Thu, Dec 1, 2011 at 10:09 AM, Richard, Joel Mrichar...@si.edu wrote: I feel this whole situation has tainted things somewhat. :( Let's not blow things out of proportion. The aforementioned wrong-doing actually seems pretty innocent (there is backstory in the IRC channel, I'm not going to bring it up here). There is a valid case for advertising interest in your talks (or location, or t-shirt design, etc.), especially in an extremely crowded field, and we've never explicitly set a policy around what is appropriate and what isn't. I think a simple edit on the part of the accused would clear up any ambiguity of intention. Our one known incident was handled privately, but didn't really cause us to address the potential for impropriety. We seem to have quite a bit of support for the splash page. If people will help me draft up the wording -- ideally something we can point to when we want to guide people in the right direction in other forums -- I think we can put this issue to bed. It depends on how harsh you want be ... I mean, if you're on the fence about ballot stuffing, you could go with something like: When voting, we expect you to actually read through the list, and pick the best ones. So yes, go ahead and vote for your friends and colleagues, but also read through the others to find other equally good proposals. -Joe
Re: [CODE4LIB] Pandering for votes for code4lib sessions
On Thu, Dec 1, 2011 at 5:19 AM, Andreas Orphanides andreas_orphani...@ncsu.edu wrote: I think imposing strictures on the voting process goes a little bit against something fundamental about Code4Lib's anarcho-democratic underpinnings. Agreed. But as the size of the community increases, you eventually get to the point where using popularity as the ultimate gauge waters things down. The thing I've always liked best about c4l is the opportunity to get exposed to questions/things that I didn't know I needed to think about in first place. Word gets around, so if I know that people are working on something that's relevant to what I'm doing, I'll just read up and maybe contact a few knowledgeable people directly. If too many people come just to learn about what interests them, I'm trying to figure out how that doesn't undermine the community since things only work when enough people are contributing whatever they have to offer. To me, the real value of c4l is talking to people who are lit up about something that's totally off my radar -- they help me understand what I need to be interested in. In return, I share cornball ideas which may have applications that would not otherwise be apparent to me or the person I'm talking with. For stuff that's already on my radar, the internet strikes me a handy tool... As the population increases, the weird, difficult to understand, and edgy stuff gets weeded out and if we're not careful, the result will just another online conference. After all, if popularity is the path to the best stuff, Mickey D's serves the best food and Bud Light is the best beer. I don't know what should be done, but the splash screen is a good step if it helps remind people what the real point is. kyle
Re: [CODE4LIB] marc in json
On Thu, Dec 1, 2011 at 11:56 AM, Gabriel Farrell gsf...@gmail.com wrote: I suspect newline-delimited will win this race. Yes. Everyone please cast a vote for newline-delimited JSON. Is there any consensus on the appropriate mime type for ndj? Keith
[CODE4LIB] conference voting and registration
On Thu, Dec 1, 2011 at 11:57 AM, Ross Singer rossfsin...@gmail.com wrote: Last year we had 129 unique voters for the proposals, roughly unchanged from Asheville (119). Both cases FAR fewer than the number of delegates (and more importantly, the number of people that wanted to be delegates). Just a thought: If we ever wanted to move to a lottery-based registration for the conference, perhaps those who take time to cast votes for presentation proposals could be weighted slightly. Keith (who sadly missed out on the whole Black Wednesday rush for Code4Lib 2012)
[CODE4LIB] server side vs client side
As I was struggling with the syntax trying to figure out how to use javascript to load a .txt file, process it and then spit out some html on a web page, I suddenly found myself asking why I was trying to do it with javascript rather than PHP. Is there a right/wrong or better/worse approach for doing something like that? Why would I want to choose one approach rather then the other? As always, apologies if I'm asking a terribly basic question. -- Nate Hill nathanielh...@gmail.com http://www.natehill.net
Re: [CODE4LIB] marc in json
+1 to marc-in-json +1 to newline-delimited records +1 to read support +1 to edsu, rsinger, BillDueber, gmcharlt, and the other module maintainers On Thu, Dec 1, 2011 at 9:31 AM, Keith Jenkins k...@cornell.edu wrote: On Thu, Dec 1, 2011 at 11:56 AM, Gabriel Farrell gsf...@gmail.com wrote: I suspect newline-delimited will win this race. Yes. Everyone please cast a vote for newline-delimited JSON. Is there any consensus on the appropriate mime type for ndj? Keith
Re: [CODE4LIB] HTML5 Microdata, schema.org, and digital collections
Damn auto-complete :-) Oh well, I guess everyone knows how inept I am now! On Thu, Dec 1, 2011 at 1:03 PM, Ed Summers e...@pobox.com wrote: Excellent! Thanks for working with the situation :-) //Ed On Thu, Dec 1, 2011 at 9:55 AM, Jason Ronallo jrona...@gmail.com wrote: Ed, I'd like to still fit the article into the next issue. I agree that the cultural heritage community needs more exposure to these new web standards. With the increased interest in linked data, the landscape of choices for how to expose your data has become more complex, and I hope the article can get the discussion going and provide some guidance there. I also see this as an opportunity for me to get something out there relatively early on this topic, and coming before my talk is good timing. Jason On Thu, Dec 1, 2011 at 9:06 AM, Ed Summers e...@pobox.com wrote: Hi Jason, Let me just say again how bad I feel for dropping this on the floor. I feel even more guilty because more discussion about the use of html5/microdata in the cultural heritage community is desperately needed. So is it OK to still try to fit your article into the next issue, or should we push it to issue 17? //Ed On Thu, Dec 1, 2011 at 9:00 AM, Jason Ronallo jrona...@gmail.com wrote: Hi, Ed, I'm glad to hear from you and the journal. What I had when I submitted a proposal to the journal was just a proposal and an implementation, so I won't be able to have a draft to you before the end of the month. I'll try to share something with you sooner than that, though. I'll be happy to license the article US CC-BY and the code as open source (hopefully MIT). Thank you, Jason On Thu, Dec 1, 2011 at 3:59 AM, Ed Summers e...@pobox.com wrote: Hi Jason, I'm pleased to tell you that your recent proposal for an article about HTML5 Microdata has been provisionally accepted to the Code4Lib Journal. The editorial committee is interested in your proposal, and would like to see a draft. I have to apologize however, since through an oversight of my own this email should have been sent almost a month ago, and was not (more on this below). As a member of the Code4Lib Journal editorial committee, I will be your contact for this article, and will work with you to get it ready for publication. We hope to publish your article in issue 16 of the Journal, which is scheduled to appear Jan 30, 2012. Incidentally, this is good timing for your code4lib talk on the same topic! The official deadline for submission of a complete draft is Friday, December 2. But since I dropped the ball on getting this email out to you promptly I completely understand if you can't hit that date. Looking at the deadlines [1] for issue 16 I can see that the 2nd draft is due Dec 30th, which is perhaps a more realistic goal for a draft. Please send whatever you have as soon as you can and we can get started. Upon receipt of the draft, I will work with you to address any changes recommended by the Editorial Committee. More information about our author guidelines may be found at http://journal.code4lib.org/article-guidelines. Please note that final drafts must be approved by a vote of the Editorial Committee before being published. We also require all authors to agree to US CC-BY licensing for the articles we publish in the journal. We recommend that any included code also have some type of code-specific open source license (such as the GPL). We look forward to seeing a complete draft and hope to include it in the Journal. Thank you for submitting to us, and feel free to contact me directly with any questions. If you could drop me a line acknowledging receipt of this email, that would be great. //Ed [1] http://wiki.code4lib.org/index.php/Code4Lib_Journal_Deadlines
Re: [CODE4LIB] HTML5 Microdata, schema.org, and digital collections
Excellent! Thanks for working with the situation :-) //Ed On Thu, Dec 1, 2011 at 9:55 AM, Jason Ronallo jrona...@gmail.com wrote: Ed, I'd like to still fit the article into the next issue. I agree that the cultural heritage community needs more exposure to these new web standards. With the increased interest in linked data, the landscape of choices for how to expose your data has become more complex, and I hope the article can get the discussion going and provide some guidance there. I also see this as an opportunity for me to get something out there relatively early on this topic, and coming before my talk is good timing. Jason On Thu, Dec 1, 2011 at 9:06 AM, Ed Summers e...@pobox.com wrote: Hi Jason, Let me just say again how bad I feel for dropping this on the floor. I feel even more guilty because more discussion about the use of html5/microdata in the cultural heritage community is desperately needed. So is it OK to still try to fit your article into the next issue, or should we push it to issue 17? //Ed On Thu, Dec 1, 2011 at 9:00 AM, Jason Ronallo jrona...@gmail.com wrote: Hi, Ed, I'm glad to hear from you and the journal. What I had when I submitted a proposal to the journal was just a proposal and an implementation, so I won't be able to have a draft to you before the end of the month. I'll try to share something with you sooner than that, though. I'll be happy to license the article US CC-BY and the code as open source (hopefully MIT). Thank you, Jason On Thu, Dec 1, 2011 at 3:59 AM, Ed Summers e...@pobox.com wrote: Hi Jason, I'm pleased to tell you that your recent proposal for an article about HTML5 Microdata has been provisionally accepted to the Code4Lib Journal. The editorial committee is interested in your proposal, and would like to see a draft. I have to apologize however, since through an oversight of my own this email should have been sent almost a month ago, and was not (more on this below). As a member of the Code4Lib Journal editorial committee, I will be your contact for this article, and will work with you to get it ready for publication. We hope to publish your article in issue 16 of the Journal, which is scheduled to appear Jan 30, 2012. Incidentally, this is good timing for your code4lib talk on the same topic! The official deadline for submission of a complete draft is Friday, December 2. But since I dropped the ball on getting this email out to you promptly I completely understand if you can't hit that date. Looking at the deadlines [1] for issue 16 I can see that the 2nd draft is due Dec 30th, which is perhaps a more realistic goal for a draft. Please send whatever you have as soon as you can and we can get started. Upon receipt of the draft, I will work with you to address any changes recommended by the Editorial Committee. More information about our author guidelines may be found at http://journal.code4lib.org/article-guidelines. Please note that final drafts must be approved by a vote of the Editorial Committee before being published. We also require all authors to agree to US CC-BY licensing for the articles we publish in the journal. We recommend that any included code also have some type of code-specific open source license (such as the GPL). We look forward to seeing a complete draft and hope to include it in the Journal. Thank you for submitting to us, and feel free to contact me directly with any questions. If you could drop me a line acknowledging receipt of this email, that would be great. //Ed [1] http://wiki.code4lib.org/index.php/Code4Lib_Journal_Deadlines
Re: [CODE4LIB] server side vs client side
Well, you need to use javascript if you want it to run in a browser. So that's one reason to pick it, and the main reason people pick it for it's most popular uses. It will be very difficult to get javascript running in a browser to do what you just said though. Not sure if you were running your js in an arbitrary client's browser, or server-side. You _can_ run javascript server-side, but it requires setting up a JS interpreter of some kind, etc., and most people don't do it just for the heck of it, they do it because they have some specific reason to want javascript for that. They want to be on the cutting edge trying out crazy new things, they just love javascript, they particularly want the non-blocking functionality of the node.js server, they need to interact with other libraries of functions already written in js, they have some crazy plan to share code between server-side and client-side, etc. So, yeah, I think you were on the right track, I'm not sure why you were trying to do that in javascript either!
Re: [CODE4LIB] server side vs client side
My general approach is server-side first. Unless it's wildly easier to accomplish something client-side, then I think it makes sense to go for the consistency of server-side processing. So taking a text file, doing some processing, and spitting out what should behave for the user as if it's a static HTML document, server-side PHP/Perl/DrugOfChoice sounds like the way to go. Save client-side processing for the things it does much better than the server-side alternative; mostly, I think that means use JavaScript for browser-interactivity stuff that's easier to do in the browser. Ken -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Nate Hill Sent: Thursday, December 01, 2011 12:49 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] server side vs client side As I was struggling with the syntax trying to figure out how to use javascript to load a .txt file, process it and then spit out some html on a web page, I suddenly found myself asking why I was trying to do it with javascript rather than PHP. Is there a right/wrong or better/worse approach for doing something like that? Why would I want to choose one approach rather then the other? As always, apologies if I'm asking a terribly basic question. -- Nate Hill nathanielh...@gmail.com http://www.natehill.net
Re: [CODE4LIB] server side vs client side
On Thu, Dec 1, 2011 at 11:49 AM, Nate Hill nathanielh...@gmail.com wrote: As I was struggling with the syntax trying to figure out how to use javascript to load a .txt file, process it and then spit out some html on a web page, I suddenly found myself asking why I was trying to do it with javascript rather than PHP. Is there a right/wrong or better/worse approach for doing something like that? Why would I want to choose one approach rather then the other? I tend to try to do most stuff server-side. Javascript I try to keep just to enhance the GUI system and perhaps do some AJAXy stuff. There is the fact that if you're using an external API that's not crucial you might want to just do it javascript side. So think about cover images in a catalog for example. You could have the server-side script go out, grab the image, put it in a local cache, then prepare the link within the actual html. But if something goes wrong, you might either take really long to return that page or never return it. The approach that most folks do is that they have some javascript that does an AJAX call. So the page loads on the client and then when the image comes back the cover image will be added. If it never happens, you've sent the page at least. I know some who tend to always go to javascript because they're used to not having control of the underlying system except for to add html to templates and sneak in javascript that way. However, that's awkward, difficult to maintain, error-prone, and likely horrible for accessibility. If you control the underlying PHPthen yeah, do it on the PHP side ;). My advice here is somewhat simplistic and general. You do have my curiosity up now though. What was you goal with trying to load that text file? Jon Gorman
Re: [CODE4LIB] server side vs client side
I should have provided a bit more information here. Here's a rough in-progress view of what I'm up to. http://www.natehill.net/loadsketch/donerightclasses.html I was using processing.js to read a file and then visualize some of the data... you can see the circles are being generated from the values in the .txt file. The actual text in the right column isn't being rendered as html, it's being drawn in the canvas... which is stupid, i need it to be html and actually do some stuff with it. I'm going to rethink my approach on this whole thing, it may have been flawed from the start. Thanks folks. N On Thu, Dec 1, 2011 at 10:24 AM, Jonathan Rochkind rochk...@jhu.edu wrote: Well, you need to use javascript if you want it to run in a browser. So that's one reason to pick it, and the main reason people pick it for it's most popular uses. It will be very difficult to get javascript running in a browser to do what you just said though. Not sure if you were running your js in an arbitrary client's browser, or server-side. You _can_ run javascript server-side, but it requires setting up a JS interpreter of some kind, etc., and most people don't do it just for the heck of it, they do it because they have some specific reason to want javascript for that. They want to be on the cutting edge trying out crazy new things, they just love javascript, they particularly want the non-blocking functionality of the node.js server, they need to interact with other libraries of functions already written in js, they have some crazy plan to share code between server-side and client-side, etc. So, yeah, I think you were on the right track, I'm not sure why you were trying to do that in javascript either! -- Nate Hill nathanielh...@gmail.com http://www.natehill.net
[CODE4LIB] Code4Lib 2013 Call for Host Proposals
The Code4Lib Conference Planning Group is calling for proposals to host the 2013 Code4Lib Conference. Information on the kind of venue we seek and the delineation of responsibilities between the host organization and the Planning Group can be found at the conference hosting web page [1] and on the Code4Lib Wiki [2]. The deadline for proposals is Sunday January 22, 2012. The decision will be made over the course of the following weeks by a popular vote. Voting will begin on or around Wednesday January 25, 2012 and will continue through the first three days of Code4Lib 2012 until 11:59PM Pacific on Wednesday, February 8th. The results of the vote will be announced on Thursday, February 9th, the final day of Code4Lib 2012. You can apply by making your pitch to the Code4Lib Conference Planning list [3]; attention to the criteria listed on the conference hosting page is appreciated. May the best site win! Feel free to take a look at the winning proposal from 2012 https://sites.google.com/site/code4lib2012seattle/ and past hosting proposals from 2011 for ideas: https://wiki.dlib.indiana.edu/display/EVENTS/Code4Lib+2011+Proposal http://www.library.yale.edu/~dlovins/c4l/code4lib2011.html http://sites.google.com/site/code4libvancouver2011 and 1. http://code4lib.org/conference/hosting 2. http://wiki.code4lib.org/index.php/How_To_Plan_A_Code4LibCon 3. code4lib...@googlegroups.com
[CODE4LIB] Call for Participation: (DC-2012) International Conference on Dublin Core and Metadata Applications
=== DC-2012 Call for Participation === International Conference on Dublin Core and Metadata Applications: Metadata for Meeting Global Challenges 3-7 September 2012, Kuching, Sarawak, Malaysia Conference Website: http://purl.org/dcevents/dc-2012 -- DEADLINES IMPORTANT DATES: Submission Deadline: 23 March 2012 Author Notification: 25 May 2012 Final Copy: 29 June 2012 -- DC-2012 will explore the global, national and regional roles of metadata in addressing global challenges such as food security, the digital divide, and sustainable development. Metadata plays a significant role globally in information systems shaping how we know, monitor and change social and governmental systems affecting everything from the environment, human rights and justice to education and peace. DC-2012 will bring together in Kuching the community of metadata scholars and practitioners to engage in the exchange of knowledge and best practices in developing languages of description to meet these global challenges. Beyond the conference theme, papers, reports, and poster submissions are welcome on a wide range of metadata topics, such as: -- Metadata principles, guidelines, and best practices -- Metadata quality (methods, tools, and practices) -- Conceptual models and frameworks (e.g., RDF, DCAM, OAIS) -- Application profiles -- Metadata generation (methods, tools, and practices) -- Metadata interoperability across domains, languages, time, structures, and scales. -- Cross-domain metadata uses (e.g., recordkeeping, preservation, curation, institutional repositories, publishing) -- Domain metadata (e.g., for corporations, cultural memory institutions, education, government, and scientific fields) -- Bibliographic standards (e.g., RDA, FRBR, subject headings) as Semantic Web vocabularies -- Accessibility metadata -- Metadata for scientific data, e-Science and grid applications -- Social tagging and user participation in building metadata -- Usage data (paradata/attention metadata) -- Knowledge Organization Systems (e.g., ontologies, taxonomies, authority files, folksonomies, and thesauri) and Simple Knowledge Organization Systems (SKOS) -- Ontology design and development -- Integration of metadata and ontologies -- Search engines and metadata -- Linked data and the Semantic Web (metadata and applications) -- Vocabulary registries and registry services -- SUBMISSIONS --All submissions for papers, reports, extended poster abstracts, community workshop and special sessions must do so through the DCMI Peer Review System at http://dcpapers.dublincore.org/index.php/pubs/. Author registration with the peer review system and instructions for the submission process appear under the Information for Authors link. --All submissions must be in English. --All submissions will be peer-reviewed by the International Program Committee. --Unless previously arranged, accepted papers, project reports and posters must be presented in Kuching by at least one of their authors. Submissions for Asynchronous Participation: With prior arrangement, a few exceptional papers, project reports and extended poster abstracts will be accepted for asynchronous presentation by their authors. Submissions accepted for asynchronous presentation must follow both the general author guidelines for submission as well as additional instructions located at http://purl.org/dcevents/dc-2012/remote. -- START SUBMISSION: Register/Login at http://dcevents.dublincore.org/index.php/IntConf/dc-2012/author/submit?requiresAuthor=1 -- PUBLICATION -- Accepted papers, project reports and poster abstracts will be published in the official Conference Proceedings at http://dcpapers.dublincore.org/ojs/pubs. -- Special session and community workshop session abstracts will be published in the online conference program. -- Papers, research reports and poster abstracts must conform to the appropriate formatting template available through the DCMI Peer Review System. -- Unless previously arranged, accepted papers, project reports and posters must be presented at The Hague by at least one of their authors. -- Submitting authors in all categories must provide basic information regarding current professional positions and affiliations as a condition of acceptance and publication. -- SUBMISSION CATEGORIES FULL PAPERS (8-10 pages; Peer reviewed) Full papers either describe innovative work in detail or provide critical, well-referenced overviews of key developments or good practice in the areas outlined above. Full papers will be assessed using the following criteria: (1) Originality of the approach to the topic and potential for implementation (2) Quality of the contribution to the implementation community (3) Significance of the
Re: [CODE4LIB] server side vs client side
On Thu, Dec 1, 2011 at 12:35 PM, Nate Hill nathanielh...@gmail.com wrote: I should have provided a bit more information here. Here's a rough in-progress view of what I'm up to. http://www.natehill.net/loadsketch/donerightclasses.html I was using processing.js to read a file and then visualize some of the data... you can see the circles are being generated from the values in the .txt file. If you want to be able to interact with the circles (and I would!), I'd recommend d3.js as an interface framework. SVG is slower if you want to draw lots of elements, but your elements are part of the DOM, so you can bind event handlers to them and such. And d3's approach of binding data and elements together is really elegant. It's remarkably easy to do stuff like this: http://mbostock.github.com/d3/ex/population.html With regards to your first question: parse the text into JSON, server-side, and send that. Modern browsers can process obscenely large JSON arrays really fast. You could parse the text client-side, but -n
Re: [CODE4LIB] marc in json
I was a strong proponent of NDJ at one point, but I've grown less strident and more weary since then. Brad Baxter has a good overview of some options[1]. I'm assuming it's a given we'd all prefer to work with valid JSON files if the pain-point can be brought down far enough. A couple years have passed since we first talked about this stuff, and the state of JSON pull-parsers is better than it once was: * yajl[2] is a super-fast C library for parsing json and support stream parsing. Bindings for ruby, node, python, and perl are linked to off the home page. I found one PHP binding[3] on github which is broken/abandoned, and no other pull-parser for PHP that I can find. Sadly, the ruby wrapper doesn't actually expose the callbacks necessary for pull-parsing, although there is a pull request[4] and at least one other option[5]. * Perl's JSON::XS supports incremental parsing * the Jackson java library[6] is excellent and has an easy-to-use pull-parser. There are a few simplistic efforts to wrap it for jruby/jython use as well. Pull-parsing is ugly, but no longer astoundingly difficult or slow, with the possible exception of PHP. And output is simple enough. As much as it makes me shudder, I think we're probably better off trying to do pull parsers and have a marc-in-json document be a valid JSON array. We could easily adopt a *convention* of, essentially, one-record-per-line, but wrap it in '[]' to make it valid json. That would allow folks with a pull-parser to write a real streaming reader, and folks without to cheat (ditch the leading and trailing [], and read the rest as one-record-per-line) until such a time as they can start using a more full-featured json parser. 1. http://en.wikipedia.org/wiki/User:Baxter.brad/Drafts/JSON_Document_Streaming_Proposal 2. http://lloyd.github.com/yajl/ 3. https://github.com/sfalvo/php-yajl 4. https://github.com/brianmario/yajl-ruby/pull/50 5. http://dgraham.github.com/json-stream/ 6. http://wiki.fasterxml.com/JacksonHome On Thu, Dec 1, 2011 at 12:56 PM, Michael B. Klein mbkl...@gmail.com wrote: +1 to marc-in-json +1 to newline-delimited records +1 to read support +1 to edsu, rsinger, BillDueber, gmcharlt, and the other module maintainers On Thu, Dec 1, 2011 at 9:31 AM, Keith Jenkins k...@cornell.edu wrote: On Thu, Dec 1, 2011 at 11:56 AM, Gabriel Farrell gsf...@gmail.com wrote: I suspect newline-delimited will win this race. Yes. Everyone please cast a vote for newline-delimited JSON. Is there any consensus on the appropriate mime type for ndj? Keith -- Bill Dueber Library Systems Programmer University of Michigan Library
Re: [CODE4LIB] Pandering for votes for code4lib sessions
Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't a tolerance, any rules must be made clear. Be just like us isn't such a rule. I personally feel that the reaction to the alleged offense is over the top. If this has happened before, I don't recall this kind of reaction. If c4l were a Marxist organization this is the point where one could call for an intense round of self-study and auto-criticism. Something has gone wrong here, and it is just possible that it is c4l that owes an apology. Not the other way around. I believe that Miss Manners would have suggested that rather than a public drubbing the offender could have been politely contacted off list with an explanation of said unwritten rules. kc Quoting Dan Scott dsc...@laurentian.ca: Ross: +1 to the disclaimer splash page. That seems to be the best way to maintain our faith in humanity to do the right thing. Dan -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] marc in json
On Thu, Dec 1, 2011 at 12:56 PM, Michael B. Klein mbkl...@gmail.com wrote: +1 to marc-in-json +1 to newline-delimited records +1 to read support +1 to edsu, rsinger, BillDueber, gmcharlt, and the other module maintainers All this incrementing is making me want to work on node-marc some more.
Re: [CODE4LIB] server side vs client side
Other Nate, this is *exactly* the advice I needed. indeed, i want to interact with the circles. Much thanks! N On Thu, Dec 1, 2011 at 10:59 AM, Nate Vack njv...@wisc.edu wrote: On Thu, Dec 1, 2011 at 12:35 PM, Nate Hill nathanielh...@gmail.com wrote: I should have provided a bit more information here. Here's a rough in-progress view of what I'm up to. http://www.natehill.net/loadsketch/donerightclasses.html I was using processing.js to read a file and then visualize some of the data... you can see the circles are being generated from the values in the .txt file. If you want to be able to interact with the circles (and I would!), I'd recommend d3.js as an interface framework. SVG is slower if you want to draw lots of elements, but your elements are part of the DOM, so you can bind event handlers to them and such. And d3's approach of binding data and elements together is really elegant. It's remarkably easy to do stuff like this: http://mbostock.github.com/d3/ex/population.html With regards to your first question: parse the text into JSON, server-side, and send that. Modern browsers can process obscenely large JSON arrays really fast. You could parse the text client-side, but -n -- Nate Hill nathanielh...@gmail.com http://www.natehill.net
Re: [CODE4LIB] server side vs client side
On Dec 1, 2011, at 12:49 PM, Nate Hill wrote: As I was struggling with the syntax trying to figure out how to use javascript to load a .txt file, process it and then spit out some html on a web page, I suddenly found myself asking why I was trying to do it with javascript rather than PHP. Is there a right/wrong or better/worse approach for doing something like that? Why would I want to choose one approach rather then the other? As always, apologies if I'm asking a terribly basic question. There's different advantages to each side: JavaScript / JScript / ECMAScript / client side: Scales better (as the clients do their own work) More obnoxious to maintain (as different browsers may have slightly different implementations) Less reliable (I keep mine turned off on my main browser) Better detection of client features (you can always lie in a browser string, or just not send it) May require extra layers of abstraction (APIs that then require extra taint checking) More responsive for simple operations (if doesn't need remote calls) Easier to do some tasks PHP / ColdFusion / CGI / ASP / server side : You can be assured that you know it's working, and error reports when it's not (assuming you log check your logs) the inverse of all of the ones in the 'client side' section (but the inverse of 'Easier to do some things' is till 'Easier to do some things') I'm not going to make any claims about speed, as it's frequently dependent on bandwidth/latency. (if I can send data to the client on a slow link, and have them build the structures around it, it might be faster than my doing it server side, and more so if my server gets bogged down) For some tasks, I'll do it both ways. Eg, form input validation -- Once in javascript, so they get the warning *before* the submit the form, and again on the server side, in case they have javascript off or are being malicious. -Joe
Re: [CODE4LIB] marc in json
Eh, I'm still intuitively opposed to pull parsing. Okay, so there are some useful libraries these days if you are using the right language. If you're using ruby and don't want to use native C code? Just as an example. Seems like we want to arrive at something easy enough to interpret _anywhere_, since you never know where you'll need to process marc. Simply reading a list of json records one at a time -- seems like it's not too much to ask for a solution that does not require complicated code that only has been written for some platforms. This does not seem like a complicated enough problem that you have to resort to complicated solutions like json pull parsers. newline-delimited is certainly one simple solution, even though the aggregate file is not valid JSON. Does it matter? Not sure if there are any simple solutions that still give you valid JSON, but if there aren't, I'd rather sacrifice valid JSON (that it's unclear if there's any important use case for anyway), than sacrifice simplicity. On 12/1/2011 2:47 PM, Bill Dueber wrote: I was a strong proponent of NDJ at one point, but I've grown less strident and more weary since then. Brad Baxter has a good overview of some options[1]. I'm assuming it's a given we'd all prefer to work with valid JSON files if the pain-point can be brought down far enough. A couple years have passed since we first talked about this stuff, and the state of JSON pull-parsers is better than it once was: * yajl[2] is a super-fast C library for parsing json and support stream parsing. Bindings for ruby, node, python, and perl are linked to off the home page. I found one PHP binding[3] on github which is broken/abandoned, and no other pull-parser for PHP that I can find. Sadly, the ruby wrapper doesn't actually expose the callbacks necessary for pull-parsing, although there is a pull request[4] and at least one other option[5]. * Perl's JSON::XS supports incremental parsing * the Jackson java library[6] is excellent and has an easy-to-use pull-parser. There are a few simplistic efforts to wrap it for jruby/jython use as well. Pull-parsing is ugly, but no longer astoundingly difficult or slow, with the possible exception of PHP. And output is simple enough. As much as it makes me shudder, I think we're probably better off trying to do pull parsers and have a marc-in-json document be a valid JSON array. We could easily adopt a *convention* of, essentially, one-record-per-line, but wrap it in '[]' to make it valid json. That would allow folks with a pull-parser to write a real streaming reader, and folks without to cheat (ditch the leading and trailing [], and read the rest as one-record-per-line) until such a time as they can start using a more full-featured json parser. 1. http://en.wikipedia.org/wiki/User:Baxter.brad/Drafts/JSON_Document_Streaming_Proposal 2. http://lloyd.github.com/yajl/ 3. https://github.com/sfalvo/php-yajl 4. https://github.com/brianmario/yajl-ruby/pull/50 5. http://dgraham.github.com/json-stream/ 6. http://wiki.fasterxml.com/JacksonHome On Thu, Dec 1, 2011 at 12:56 PM, Michael B. Kleinmbkl...@gmail.com wrote: +1 to marc-in-json +1 to newline-delimited records +1 to read support +1 to edsu, rsinger, BillDueber, gmcharlt, and the other module maintainers On Thu, Dec 1, 2011 at 9:31 AM, Keith Jenkinsk...@cornell.edu wrote: On Thu, Dec 1, 2011 at 11:56 AM, Gabriel Farrellgsf...@gmail.com wrote: I suspect newline-delimited will win this race. Yes. Everyone please cast a vote for newline-delimited JSON. Is there any consensus on the appropriate mime type for ndj? Keith
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
On 2 December 2011 09:33, Munson, Doris dmun...@ewu.edu wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. I totally just unwrote that down Chris
[CODE4LIB] C4L scholarships available
Equinox Software is offering 2 scholarships to the code4lib conference in February. The scholarships will reimburse travel and accommodation expenses up to $750.00 USD for a full-time employee from public libraries using either Evergreen or Koha to attend the Code4Lib Conference in Seattle, Washington, USA, from February 6-9, 2012. The awardees will also receive free registration to Code4Lib. ELIGIBILITY The applicants must be presently working in a public library that is currently using or is actively committed to moving to either Evergreen or Koha as their ILS. The applicants must indicate any amount and source of additional funding which, combined with the Scholarship, will permit them to cover their expenses to attend the Conference. (This will not reduce the amount of the award.) Preference will be given to underfunded libraries or libraries in budget crisis. DEADLINE FOR APPLICATIONDecember 31, 2011 The email application should include a current resume, including all contact information, education, and experience, along with an essay as described below. The applicants will write up to 750 words of narrative in English to address the following: •Description of the library’s mission and commitment to open source solutions •How attendance may benefit the applicant •How the applicant intends to share the benefit of the experience with colleagues •Description of funding constraints, budgetary limitations, or travel/hiring freezes pertinent to the applicant’s situation APPLICATION ADDRESS: Please send resumes and essays to Grace Dunbar before December 31, 2011 by email attachment to c4lgr...@esilibrary.com NOTIFICATION: The successful applicants will be notified by January 5, 2012. Feel free to re-post this announcement and/or our press release (http://esilibrary.com/esi/newsitem.php?id=2182) Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org http://evergreen-ils.org
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
I'm still not even sure why people think the blog post violated any unwritten rules or expectations. I agree that people kind of unreasonably raked the author over the coals here. I think _maybe_ under some interpretations it's borderline (some of those interpretations are those of the READERS of the blog and how they respond, which the author has limited control over), and DO think a splash page on voting with a few sentences on expectations for who votes, why, and how, would be a very good thing for us to have _in general_, so this is useful for bringing up that idea (nice idea rsinger). But as a thought experiment, let's say I jrochkind had a proposal, and posted to my blog Hey, if you're thinking about going to the conf, consider voting to help make the conf! If you're voting, please consider my proposal, here's why I think it's important. Would you consider that inappropriate too? If not, please elucidate the differences, and we'll be that much closer to understanding/developing consensual community expectations here. Right now, I think some things some of you all think are obvious are far from obvious to others, even others you assume it would be obvious to. On 12/1/2011 3:33 PM, Munson, Doris wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. Regards, Doris Doris Munson Systems/Reference Librarian Eastern Washington University dmun...@ewu.edu 509-359-6395 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Thursday, December 01, 2011 11:56 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't a tolerance, any rules must be made clear. Be just like us isn't such a rule. I personally feel that the reaction to the alleged offense is over the top. If this has happened before, I don't recall this kind of reaction. If c4l were a Marxist organization this is the point where one could call for an intense round of self-study and auto-criticism. Something has gone wrong here, and it is just possible that it is c4l that owes an apology. Not the other way around. I believe that Miss Manners would have suggested that rather than a public drubbing the offender could have been politely contacted off list with an explanation of said unwritten rules. kc Quoting Dan Scottdsc...@laurentian.ca: Ross: +1 to the disclaimer splash page. That seems to be the best way to maintain our faith in humanity to do the right thing. Dan
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
If it is that important, it should be written down! -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Chris Cormack Sent: Thursday, December 01, 2011 3:36 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions On 2 December 2011 09:33, Munson, Doris dmun...@ewu.edu wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. I totally just unwrote that down Chris
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
With the way code4lib works, you realize you just committed yourself to writing them down, right? :) -Mike On Thu, Dec 1, 2011 at 15:51, Wilfred Drew dr...@tc3.edu wrote: If it is that important, it should be written down! -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Chris Cormack Sent: Thursday, December 01, 2011 3:36 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions On 2 December 2011 09:33, Munson, Doris dmun...@ewu.edu wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. I totally just unwrote that down Chris
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
Can't. The first rule of unwritten rules is ... Genny -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Wilfred Drew Sent: Thursday, December 01, 2011 12:51 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions If it is that important, it should be written down! -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Chris Cormack Sent: Thursday, December 01, 2011 3:36 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions On 2 December 2011 09:33, Munson, Doris dmun...@ewu.edu wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. I totally just unwrote that down Chris
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
Well, what is it? What's the first rule? Can't take the suspense...! GAH! On Thu, Dec 1, 2011 at 3:56 PM, Genny Engel gen...@sonoma.lib.ca.us wrote: Can't. The first rule of unwritten rules is ... Genny -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Wilfred Drew Sent: Thursday, December 01, 2011 12:51 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions If it is that important, it should be written down! -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Chris Cormack Sent: Thursday, December 01, 2011 3:36 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions On 2 December 2011 09:33, Munson, Doris dmun...@ewu.edu wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. I totally just unwrote that down Chris
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
So this was what pandering a vote meant all along? And I guess you are supposed to know this to count as a c4l community member? Unwritten rules indeed... ~Bohyun -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind Sent: Thursday, December 01, 2011 3:48 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions I'm still not even sure why people think the blog post violated any unwritten rules or expectations. I agree that people kind of unreasonably raked the author over the coals here. I think _maybe_ under some interpretations it's borderline (some of those interpretations are those of the READERS of the blog and how they respond, which the author has limited control over), and DO think a splash page on voting with a few sentences on expectations for who votes, why, and how, would be a very good thing for us to have _in general_, so this is useful for bringing up that idea (nice idea rsinger). But as a thought experiment, let's say I jrochkind had a proposal, and posted to my blog Hey, if you're thinking about going to the conf, consider voting to help make the conf! If you're voting, please consider my proposal, here's why I think it's important. Would you consider that inappropriate too? If not, please elucidate the differences, and we'll be that much closer to understanding/developing consensual community expectations here. Right now, I think some things some of you all think are obvious are far from obvious to others, even others you assume it would be obvious to. On 12/1/2011 3:33 PM, Munson, Doris wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. Regards, Doris Doris Munson Systems/Reference Librarian Eastern Washington University dmun...@ewu.edu 509-359-6395 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Thursday, December 01, 2011 11:56 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't a tolerance, any rules must be made clear. Be just like us isn't such a rule. I personally feel that the reaction to the alleged offense is over the top. If this has happened before, I don't recall this kind of reaction. If c4l were a Marxist organization this is the point where one could call for an intense round of self-study and auto-criticism. Something has gone wrong here, and it is just possible that it is c4l that owes an apology. Not the other way around. I believe that Miss Manners would have suggested that rather than a public drubbing the offender could have been politely contacted off list with an explanation of said unwritten rules. kc Quoting Dan Scottdsc...@laurentian.ca: Ross: +1 to the disclaimer splash page. That seems to be the best way to maintain our faith in humanity to do the right thing. Dan
Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor)
I feel this whole situation has tainted things somewhat. :( This incident appears to have been blown out of proportion. So to lighten the mood a bit, I offer this doggerel inspired by the above comment and with apologies to Ed Cobb, et al.: Tainted Votes Sometimes I feel I've got to Run away I've got to Get away From the stain you cause with all this pandering The votes were cast Now my session's last We can make this right If the splash page is up by tonight Once I ran to you (I ran) Now I'll run from you The tainted votes have riven All the results diebold had scriven Take my jeers and that's not nearly all Oh...tainted votes Tainted votes -- Michael
Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor)
;-) -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Doran, Michael D Sent: Thursday, December 01, 2011 4:40 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor) I feel this whole situation has tainted things somewhat. :( This incident appears to have been blown out of proportion. So to lighten the mood a bit, I offer this doggerel inspired by the above comment and with apologies to Ed Cobb, et al.: Tainted Votes Sometimes I feel I've got to Run away I've got to Get away From the stain you cause with all this pandering The votes were cast Now my session's last We can make this right If the splash page is up by tonight Once I ran to you (I ran) Now I'll run from you The tainted votes have riven All the results diebold had scriven Take my jeers and that's not nearly all Oh...tainted votes Tainted votes -- Michael
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
It is unwritten rules that lead people to feel excluded from a group. How can the C4L group make other feel part of the group if the important rules are unwritten? That is what makes the group appear elitist to outsiders or newbies. Bill Drew Sort of a newbie but maybe not -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Bohyun Kim Sent: Thursday, December 01, 2011 4:24 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions So this was what pandering a vote meant all along? And I guess you are supposed to know this to count as a c4l community member? Unwritten rules indeed... ~Bohyun -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind Sent: Thursday, December 01, 2011 3:48 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions I'm still not even sure why people think the blog post violated any unwritten rules or expectations. I agree that people kind of unreasonably raked the author over the coals here. I think _maybe_ under some interpretations it's borderline (some of those interpretations are those of the READERS of the blog and how they respond, which the author has limited control over), and DO think a splash page on voting with a few sentences on expectations for who votes, why, and how, would be a very good thing for us to have _in general_, so this is useful for bringing up that idea (nice idea rsinger). But as a thought experiment, let's say I jrochkind had a proposal, and posted to my blog Hey, if you're thinking about going to the conf, consider voting to help make the conf! If you're voting, please consider my proposal, here's why I think it's important. Would you consider that inappropriate too? If not, please elucidate the differences, and we'll be that much closer to understanding/developing consensual community expectations here. Right now, I think some things some of you all think are obvious are far from obvious to others, even others you assume it would be obvious to. On 12/1/2011 3:33 PM, Munson, Doris wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. Regards, Doris Doris Munson Systems/Reference Librarian Eastern Washington University dmun...@ewu.edu 509-359-6395 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Thursday, December 01, 2011 11:56 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't a tolerance, any rules must be made clear. Be just like us isn't such a rule. I personally feel that the reaction to the alleged offense is over the top. If this has happened before, I don't recall this kind of reaction. If c4l were a Marxist organization this is the point where one could call for an intense round of self-study and auto-criticism. Something has gone wrong here, and it is just possible that it is c4l that owes an apology. Not the other way around. I believe that Miss Manners would have suggested that rather than a public drubbing the offender could have been politely contacted off list with an explanation of said unwritten rules. kc Quoting Dan Scottdsc...@laurentian.ca: Ross: +1 to the disclaimer splash page. That seems to be the best way to maintain our faith in humanity to do the right thing. Dan
Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor)
Great... now this song is stuck in my head. ;-) Nicely done, though... Kevin On Thu, Dec 1, 2011 at 1:39 PM, Doran, Michael D do...@uta.edu wrote: I feel this whole situation has tainted things somewhat. :( This incident appears to have been blown out of proportion. So to lighten the mood a bit, I offer this doggerel inspired by the above comment and with apologies to Ed Cobb, et al.: Tainted Votes Sometimes I feel I've got to Run away I've got to Get away From the stain you cause with all this pandering The votes were cast Now my session's last We can make this right If the splash page is up by tonight Once I ran to you (I ran) Now I'll run from you The tainted votes have riven All the results diebold had scriven Take my jeers and that's not nearly all Oh...tainted votes Tainted votes -- Michael
Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor)
I think I like this song, but I won't know for sure until Roy applies the Seal of Approval. Maccabee On 12/1/2011 3:39 PM, Doran, Michael D wrote: I feel this whole situation has tainted things somewhat. :( This incident appears to have been blown out of proportion. So to lighten the mood a bit, I offer this doggerel inspired by the above comment and with apologies to Ed Cobb, et al.: Tainted Votes Sometimes I feel I've got to Run away I've got to Get away From the stain you cause with all this pandering The votes were cast Now my session's last We can make this right If the splash page is up by tonight Once I ran to you (I ran) Now I'll run from you The tainted votes have riven All the results diebold had scriven Take my jeers and that's not nearly all Oh...tainted votes Tainted votes -- Michael -- Maccabee Levine Head of Library Technology Services University of Wisconsin Oshkosh levi...@uwosh.edu 920-424-7332
Re: [CODE4LIB] conference voting and registration
While I understand your frustration, I have come around to accepting the system we have. Many of the folks who attend every year hold the conference as one of their key annual events, and plan to register the instant that tickets become available. I know that it sells out fast, but the folks who are there on the dot pretty much always get in. The alternative, of course is to present, although that can be rolling the dice, or volunteer, which I did this year. If you are on the waiting list, bear in mind that plans frequently change, and waiting list requests often get filled. Cary On Thu, Dec 1, 2011 at 9:40 AM, Keith Jenkins k...@cornell.edu wrote: On Thu, Dec 1, 2011 at 11:57 AM, Ross Singer rossfsin...@gmail.com wrote: Last year we had 129 unique voters for the proposals, roughly unchanged from Asheville (119). Both cases FAR fewer than the number of delegates (and more importantly, the number of people that wanted to be delegates). Just a thought: If we ever wanted to move to a lottery-based registration for the conference, perhaps those who take time to cast votes for presentation proposals could be weighted slightly. Keith (who sadly missed out on the whole Black Wednesday rush for Code4Lib 2012) -- Cary Gordon The Cherry Hill Company http://chillco.com
Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor)
I disagree that the voting procedure is flawed. I voted 12 times, which seems downright generous. Dan -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Kevin S. Clarke Sent: Thursday, December 01, 2011 2:00 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor) Great... now this song is stuck in my head. ;-) Nicely done, though... Kevin On Thu, Dec 1, 2011 at 1:39 PM, Doran, Michael D do...@uta.edu wrote: I feel this whole situation has tainted things somewhat. :( This incident appears to have been blown out of proportion. So to lighten the mood a bit, I offer this doggerel inspired by the above comment and with apologies to Ed Cobb, et al.: Tainted Votes Sometimes I feel I've got to Run away I've got to Get away From the stain you cause with all this pandering The votes were cast Now my session's last We can make this right If the splash page is up by tonight Once I ran to you (I ran) Now I'll run from you The tainted votes have riven All the results diebold had scriven Take my jeers and that's not nearly all Oh...tainted votes Tainted votes -- Michael
Re: [CODE4LIB] Pandering for votes for code4lib sessions (humor)
So applied. Roy On Dec 1, 2011, at 2:20 PM, Maccabee Levine levi...@uwosh.edu wrote: I think I like this song, but I won't know for sure until Roy applies the Seal of Approval. Maccabee On 12/1/2011 3:39 PM, Doran, Michael D wrote: I feel this whole situation has tainted things somewhat. :( This incident appears to have been blown out of proportion. So to lighten the mood a bit, I offer this doggerel inspired by the above comment and with apologies to Ed Cobb, et al.: Tainted Votes Sometimes I feel I've got to Run away I've got to Get away From the stain you cause with all this pandering The votes were cast Now my session's last We can make this right If the splash page is up by tonight Once I ran to you (I ran) Now I'll run from you The tainted votes have riven All the results diebold had scriven Take my jeers and that's not nearly all Oh...tainted votes Tainted votes -- Michael -- Maccabee Levine Head of Library Technology Services University of Wisconsin Oshkosh levi...@uwosh.edu 920-424-7332
Re: [CODE4LIB] C4L scholarships available
Hi, To add one clarification, since Equinox is not holding any registration slots for the conference, the free registration to Code4Lib will be done by reimbursing the awardees $150 each for the registration fee. This reimbursement is in _addition_ to the $750 for travel and accommodations. This does mean that in order to be considered for the scholarship, one must already be registered or on the waitlist, and the awards can only be made to individuals who have an active registration by January 5th. Regards, Galen On 12/01/2011 03:43 PM, Galen Charlton wrote: Equinox Software is offering 2 scholarships to the code4lib conference in February. The scholarships will reimburse travel and accommodation expenses up to $750.00 USD for a full-time employee from public libraries using either Evergreen or Koha to attend the Code4Lib Conference in Seattle, Washington, USA, from February 6-9, 2012. The awardees will also receive free registration to Code4Lib. ELIGIBILITY The applicants must be presently working in a public library that is currently using or is actively committed to moving to either Evergreen or Koha as their ILS. The applicants must indicate any amount and source of additional funding which, combined with the Scholarship, will permit them to cover their expenses to attend the Conference. (This will not reduce the amount of the award.) Preference will be given to underfunded libraries or libraries in budget crisis. DEADLINE FOR APPLICATION December 31, 2011 The email application should include a current resume, including all contact information, education, and experience, along with an essay as described below. The applicants will write up to 750 words of narrative in English to address the following: • Description of the library’s mission and commitment to open source solutions • How attendance may benefit the applicant • How the applicant intends to share the benefit of the experience with colleagues • Description of funding constraints, budgetary limitations, or travel/hiring freezes pertinent to the applicant’s situation APPLICATION ADDRESS: Please send resumes and essays to Grace Dunbar before December 31, 2011 by email attachment to c4lgr...@esilibrary.com NOTIFICATION: The successful applicants will be notified by January 5, 2012. Feel free to re-post this announcement and/or our press release (http://esilibrary.com/esi/newsitem.php?id=2182) Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org http://evergreen-ils.org
Re: [CODE4LIB] Code4Lib 2013 Call for Host Proposals
I just wanted to let people know that I will be updating the Hosting a Code4Lib sites with this year's information and numbers (for hotel blocks etc) as well as other information that would have been helpful. This will NOT happen until closer or after the actual conference, mostly because the information that would be most helpful won't be available until then. I would, however, like to offer my availability to answer any questions for people who are planning on hosting this next year on an ad hoc basis until then. Elizabeth Elizabeth Duell Orbis Cascade Alliance edu...@uoregon.edu (541) 346-1883 Elizabeth Duell Orbis Cascade Alliance edu...@uoregon.edu (541) 346-1883 On 12/1/2011 10:45 AM, Jodi Schneider wrote: The Code4Lib Conference Planning Group is calling for proposals to host the 2013 Code4Lib Conference. Information on the kind of venue we seek and the delineation of responsibilities between the host organization and the Planning Group can be found at the conference hosting web page [1] and on the Code4Lib Wiki [2]. The deadline for proposals is Sunday January 22, 2012. The decision will be made over the course of the following weeks by a popular vote. Voting will begin on or around Wednesday January 25, 2012 and will continue through the first three days of Code4Lib 2012 until 11:59PM Pacific on Wednesday, February 8th. The results of the vote will be announced on Thursday, February 9th, the final day of Code4Lib 2012. You can apply by making your pitch to the Code4Lib Conference Planning list [3]; attention to the criteria listed on the conference hosting page is appreciated. May the best site win! Feel free to take a look at the winning proposal from 2012 https://sites.google.com/site/code4lib2012seattle/ and past hosting proposals from 2011 for ideas: https://wiki.dlib.indiana.edu/display/EVENTS/Code4Lib+2011+Proposal http://www.library.yale.edu/~dlovins/c4l/code4lib2011.html http://sites.google.com/site/code4libvancouver2011 and 1. http://code4lib.org/conference/hosting 2. http://wiki.code4lib.org/index.php/How_To_Plan_A_Code4LibCon 3. code4lib...@googlegroups.com mailto:code4lib...@googlegroups.com -- You received this message because you are subscribed to the Google Groups code4libcon group. To post to this group, send email to code4lib...@googlegroups.com. To unsubscribe from this group, send email to code4libcon+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/code4libcon?hl=en.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
+1 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Ross Singer Sent: Thursday, December 01, 2011 5:47 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions As unwilling commissioner of elections, I'm shocked, SHOCKED, I say, to hear of improprieties with the voting process. That said, I'm not shocked (and we've seen it before). I am absolutely opposed to: 1) Setting weights on voting. 0 is just as valid a vote as 3. 2) Publicly shaming the offenders in Code4Lib. If you run across impropriety in a forum, make a friendly, yet firm, reminder that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib. Sometimes it just takes a simple reminder for people to realize what they're doing is wrong (it certainly works for me). 3) Selection committees. We are, as Dre points out, anarcho-democratic as our core. anarcho-bureaucratic just sounds silly. This current situation is largely our doing. We even publicly said that getting your proposal voted in is the backdoor into the conference. The first allotment of spaces sold out in an hour. This is, literally, the only way that a person that was not able to register and is buried on the wait list is going to get in. And we've basically told them that. One thing I would be open to is to put a disclaimer splash page before any ballot (only to be seen the first time a person votes) briefly explaining how the ballot works and to mention that ballot stuffing is unethical, undemocratic and tears at the fabric that is Code4Lib or some such. I would welcome contributions to the wording. What would people think about that? -Ross. On Thu, Dec 1, 2011 at 8:32 AM, Richard, Joel M richar...@si.edu wrote: I disagree with this suggestion. Personally I vote for only those I find interesting and useful to me, but I don't put an response for every talk listed. I only respond on those I'm interested. Everyone else gets 0 points. I would expect that others do this, too. Katherine's suggestion also puts an burden on those who are legitimately participating while doing nothing to prevent those who are misbehaving. I like Edwards's suggestions, which are easy to implement and don't really impact the process that much. Personally, I believe that the proper response to this is to: 1. Publicly shame those who are participating in this. :) 2. Delete their votes, or at least those you can identify. 3. Disqualify the person who is receiving illegitimate votes. See #1. 4. Eliminate voting altogether and have a committee of 10-15 people from the community select from the proposed talks. Isn't this what other conferences do? In the end, the conference organizers can invite whoever they want to speak. The voting ends up being a courtesy to the rest of us. --Joel Joel Richard Lead Web Developer, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | richar...@si.edu On Dec 1, 2011, at 8:06 AM, Lynch,Katherine wrote: I was actually going to suggest just this, Kåre! Another way to handle it, or perhaps an additional way, would be give a user's votes a certain amount of weight proportionate to the number of sessions they voted on. So if they evaluated all of them and voted, 100% of their vote gets counted. If they evaluated half, 50%, and so on? Not sure if this is worth the effort, but I know it's worked for various camps that I've been to which fall prey to the same problem. Sincerely, Katherine On 12/1/11 6:55 AM, Kåre Fiedler Christiansen k...@statsbiblioteket.dk wrote: From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Michael B. Klein snip In any case, I'm interested to see how effective this current call for support is. Me too! Could someone with access to the voting data perhaps anonymously pull out how many voters have given points to only a single talk or two? If the problem is indeed real, perhaps simply stating on the page that you are expected to evaluate _all_ proposals, and not just vote up a single talk, would help the issue? It might turn away some of the wrong voters. Requiring to give out at least, say, 10 points, could be perhaps be a way to enforce some participation? Best, Kåre
[CODE4LIB] Job Announcement: Marketing Communications Coordinator for technology company (San Diego, CA)
LAC Group is seeking a Marketing Communications Coordinator, on behalf of our client, a technology company that has been on FORTUNE magazine's list of 100 Best Companies to Work For in America for over a decade. We are looking for someone who can coordinate global content updates for the company's websites. This is a full-time position in San Diego, CA. Responsibilities: * Add new content into the Snapdragon Drupal CMS (blog posts, new devices, updated game info, processor details) Update content on company's website. * Coordinate regional updates with corporate marketing, local web agencies, global infrastructure agency * Make small image and code changes where necessary * Perform basic Quality Assurance and testing for website changes * Manage weekly calls with key global region * Other duties as necessary Qualifications: * Bachelor degree * Familiarity with web technologies working on web projects * Experience with the process of website development requirements, wireframes, designs, QA, development, deployment, upgrades * Solid project management skills * Working knowledge of the Drupal CMS a plus * Ability to make minor graphics/HTML/CSS changes a plus * Can communicate easily with both technical and non-technical colleagues * Willingness to learn and interest in problem-solving * Ability to thrive in a fast-paced environment To read more details and to apply please visit this link: http://bit.ly/u7828R To view all of our currently open positions please visit: http://careers.lac-group.com/ LAC Group is an Equal Opportunity/Affirmative Action employer and values diversity in the workforce. Patty De Anda Gates Communications Projects Associate 323.302.9439 - direct 323.852.1083 - main 323.852.1093 - fax LAC Group, 6500 Wilshire Boulevard, Suite 2240, Los Angeles, CA 90048 LAC on LinkedInhttp://www.linkedin.com/groups?mostPopular=gid=1235317 | LAC on Facebookhttp://www.facebook.com/pages/LAC-Group/136401033040717?v=app_4949752878ref=ts#!/pages/LAC-Group/136401033040717?v=wallref=ts | LAC on Twitterhttp://twitter.com/libassociates | LAC Group Newsletter Sign-uphttp://lac-group.com/lac-group/newsletter/ lac-group.comhttp://lac-group.com/ The information contained in this e-mail message is confidential. If you are not the intended recipient, any dissemination or copying is strictly prohibited. If you think that you have received this e-mail message in error, please contact the sender.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
I think that it's not out of bounds to ask people for c4l votes unless you're offering tangible rewards in exchange for said votes. Tangible rewards as used here shall in no circumstance be construed to apply to any offers of beer or its nonalcoholic equivalent. Non-alcoholic equivalent as used here, shall in no way be construed to imply that there is such a thing.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
While I want to stress my position that there is nothing wrong with advertising your proposal (including the source of this now-too-long thread), it *would be* out of line to ask everybody in your organization to vote for your proposal (outside of the exceptional workplace -- such as Gluejar or Equinox -- where everybody might actually have an interest in Code4lib). I think it's important to point out that we have no transgressions; just a cautionary tale. We've known for some time that our current system is vulnerable to (likely unwitting - as Jonathan's email pointed out) abuse and our simple splash screen proposal would probably solve any potential issue. -Ross. On Thursday, December 1, 2011, Eric Hellman e...@hellman.net wrote: I think that it's not out of bounds to ask people for c4l votes unless you're offering tangible rewards in exchange for said votes. Tangible rewards as used here shall in no circumstance be construed to apply to any offers of beer or its nonalcoholic equivalent. Non-alcoholic equivalent as used here, shall in no way be construed to imply that there is such a thing.
Re: [CODE4LIB] Pandering for votes for code4lib sessions
It's also worth noting that the voters (so far) have done a super job. If your talk is not making the cut, don't take it as a reflection or judgment on you or your work. It just means that voters want to save you for next year. And if your talk IS making the cut, it's probably because voters want the chance to make snide remarks about you on the backchannel. (I'll only be able to attend virtually this year. Please don't ask to take away my vote!) Eric Hellman President, Gluejar, Inc. http://www.gluejar.com/ 41 Watchung Plaza #132, Montclair NJ 07042 e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar
Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions
I think the point of the hubbub today is trying to articulate the rule that should be written. Nobody is being excluded: we make things up as they go along and anybody is welcome to throw in their opinion. That said, there's over 5 years of this process already in place. Very little is written, but there is a lot of momentum. Much of it is arbitrary. Some may actually be capricious. Most is probably not even considered, though; it's a really informal group. What I'm trying to say is that there are things that should be documented. We don't necessarily know what they are or how they should read. If you find something that really should be written down, throw it out there (and be willing to solicit opinions, synthesize them and write them down). -Ross. On Thursday, December 1, 2011, Wilfred Drew dr...@tc3.edu wrote: It is unwritten rules that lead people to feel excluded from a group. How can the C4L group make other feel part of the group if the important rules are unwritten? That is what makes the group appear elitist to outsiders or newbies. Bill Drew Sort of a newbie but maybe not -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Bohyun Kim Sent: Thursday, December 01, 2011 4:24 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions So this was what pandering a vote meant all along? And I guess you are supposed to know this to count as a c4l community member? Unwritten rules indeed... ~Bohyun -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind Sent: Thursday, December 01, 2011 3:48 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions I'm still not even sure why people think the blog post violated any unwritten rules or expectations. I agree that people kind of unreasonably raked the author over the coals here. I think _maybe_ under some interpretations it's borderline (some of those interpretations are those of the READERS of the blog and how they respond, which the author has limited control over), and DO think a splash page on voting with a few sentences on expectations for who votes, why, and how, would be a very good thing for us to have _in general_, so this is useful for bringing up that idea (nice idea rsinger). But as a thought experiment, let's say I jrochkind had a proposal, and posted to my blog Hey, if you're thinking about going to the conf, consider voting to help make the conf! If you're voting, please consider my proposal, here's why I think it's important. Would you consider that inappropriate too? If not, please elucidate the differences, and we'll be that much closer to understanding/developing consensual community expectations here. Right now, I think some things some of you all think are obvious are far from obvious to others, even others you assume it would be obvious to. On 12/1/2011 3:33 PM, Munson, Doris wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. Regards, Doris Doris Munson Systems/Reference Librarian Eastern Washington University dmun...@ewu.edu 509-359-6395 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Thursday, December 01, 2011 11:56 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't a tolerance, any rules must be made clear. Be just like us isn't such a rule. I personally feel that the reaction to the alleged offense is over the top. If this has happened before, I don't recall this kind of reaction. If c4l were a Marxist organization this is the point where one could call for an intense round of self-study and auto-criticism.
[CODE4LIB] Taint the vote
I think this calls for an unwritten rule engine. On Dec 1, 2011 10:22 PM, Ross Singer rossfsin...@gmail.com wrote: I think the point of the hubbub today is trying to articulate the rule that should be written. Nobody is being excluded: we make things up as they go along and anybody is welcome to throw in their opinion. That said, there's over 5 years of this process already in place. Very little is written, but there is a lot of momentum. Much of it is arbitrary. Some may actually be capricious. Most is probably not even considered, though; it's a really informal group. What I'm trying to say is that there are things that should be documented. We don't necessarily know what they are or how they should read. If you find something that really should be written down, throw it out there (and be willing to solicit opinions, synthesize them and write them down). -Ross. On Thursday, December 1, 2011, Wilfred Drew dr...@tc3.edu wrote: It is unwritten rules that lead people to feel excluded from a group. How can the C4L group make other feel part of the group if the important rules are unwritten? That is what makes the group appear elitist to outsiders or newbies. Bill Drew Sort of a newbie but maybe not -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Bohyun Kim Sent: Thursday, December 01, 2011 4:24 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions So this was what pandering a vote meant all along? And I guess you are supposed to know this to count as a c4l community member? Unwritten rules indeed... ~Bohyun -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind Sent: Thursday, December 01, 2011 3:48 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions I'm still not even sure why people think the blog post violated any unwritten rules or expectations. I agree that people kind of unreasonably raked the author over the coals here. I think _maybe_ under some interpretations it's borderline (some of those interpretations are those of the READERS of the blog and how they respond, which the author has limited control over), and DO think a splash page on voting with a few sentences on expectations for who votes, why, and how, would be a very good thing for us to have _in general_, so this is useful for bringing up that idea (nice idea rsinger). But as a thought experiment, let's say I jrochkind had a proposal, and posted to my blog Hey, if you're thinking about going to the conf, consider voting to help make the conf! If you're voting, please consider my proposal, here's why I think it's important. Would you consider that inappropriate too? If not, please elucidate the differences, and we'll be that much closer to understanding/developing consensual community expectations here. Right now, I think some things some of you all think are obvious are far from obvious to others, even others you assume it would be obvious to. On 12/1/2011 3:33 PM, Munson, Doris wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. Regards, Doris Doris Munson Systems/Reference Librarian Eastern Washington University dmun...@ewu.edu 509-359-6395 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Thursday, December 01, 2011 11:56 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't a tolerance, any rules must be made clear. Be just like us isn't such a rule. I personally feel that the reaction to the
Re: [CODE4LIB] Taint the vote
IT'S INSANE, THIS VOTE'S TAINT. -Mike P.S. Hat tip to Bob David. On Thu, Dec 1, 2011 at 22:25, Simon Spero s...@unc.edu wrote: I think this calls for an unwritten rule engine. On Dec 1, 2011 10:22 PM, Ross Singer rossfsin...@gmail.com wrote: I think the point of the hubbub today is trying to articulate the rule that should be written. Nobody is being excluded: we make things up as they go along and anybody is welcome to throw in their opinion. That said, there's over 5 years of this process already in place. Very little is written, but there is a lot of momentum. Much of it is arbitrary. Some may actually be capricious. Most is probably not even considered, though; it's a really informal group. What I'm trying to say is that there are things that should be documented. We don't necessarily know what they are or how they should read. If you find something that really should be written down, throw it out there (and be willing to solicit opinions, synthesize them and write them down). -Ross. On Thursday, December 1, 2011, Wilfred Drew dr...@tc3.edu wrote: It is unwritten rules that lead people to feel excluded from a group. How can the C4L group make other feel part of the group if the important rules are unwritten? That is what makes the group appear elitist to outsiders or newbies. Bill Drew Sort of a newbie but maybe not -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Bohyun Kim Sent: Thursday, December 01, 2011 4:24 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions So this was what pandering a vote meant all along? And I guess you are supposed to know this to count as a c4l community member? Unwritten rules indeed... ~Bohyun -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind Sent: Thursday, December 01, 2011 3:48 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Unwritten Rules, formerly Pandering for votes for code4lib sessions I'm still not even sure why people think the blog post violated any unwritten rules or expectations. I agree that people kind of unreasonably raked the author over the coals here. I think _maybe_ under some interpretations it's borderline (some of those interpretations are those of the READERS of the blog and how they respond, which the author has limited control over), and DO think a splash page on voting with a few sentences on expectations for who votes, why, and how, would be a very good thing for us to have _in general_, so this is useful for bringing up that idea (nice idea rsinger). But as a thought experiment, let's say I jrochkind had a proposal, and posted to my blog Hey, if you're thinking about going to the conf, consider voting to help make the conf! If you're voting, please consider my proposal, here's why I think it's important. Would you consider that inappropriate too? If not, please elucidate the differences, and we'll be that much closer to understanding/developing consensual community expectations here. Right now, I think some things some of you all think are obvious are far from obvious to others, even others you assume it would be obvious to. On 12/1/2011 3:33 PM, Munson, Doris wrote: As a relative newcomer to this list, I second the idea that any offenders be contacted off list with an explanation of any unwritten rules they unknowingly violate. I suggest this becomes one of c4l's unwritten rules. Regards, Doris Doris Munson Systems/Reference Librarian Eastern Washington University dmun...@ewu.edu 509-359-6395 -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Thursday, December 01, 2011 11:56 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Pandering for votes for code4lib sessions Responding to the thread and not this specific email... This conversation has an unfortunate subtext of us v. them. It is the case that c4l is a small-ish group that has a particular personality, and folks really care about that. And the c4l conference (which I only attended once) has a great feel about it of folks sharing ideas (and beer). The problem with that kind of chummy-ness is that it makes it hard for newcomers or folks who aren't native c4l-ers to participate, either in the conference or in the various ways that c4l-ers communicate. To then take someone to task for violating an unwritten rule of that culture really does not seem fair, and the unfortunate use of language (pandering), not to mention the length of this thread, is likely to discourage enthusiastic newcomers in the future. If c4l is open to new participants and new ideas, some acceptance of differences in style must be tolerated. Where there isn't
