Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt

2011-12-08 Thread Kåre Fiedler Christiansen
Hi,

Could the items in the result list be expansible too? Right now I can't see who 
is winning :-)

My ruby-foo is weak (read: non-existent) so no patch supplied. I checked the 
code, but it was jst short of being self explanatory enough for me to 
attempt a half hearted patch (that I wouldn't know how to test anyway)...

Best,
  Kåre

 -Original Message-
 From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On
 Behalf Of Ross Singer
 Sent: Wednesday, December 07, 2011 9:31 PM
 To: CODE4LIB@LISTSERV.ND.EDU
 Subject: Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
 
 This has been updated (thanks to Dave Walker).
 
 If anybody wants to contribute, the sources are available at:
 
 http://code.google.com/p/conferencekeeper/
 
 We are currently running off /branches/diebold
 
 -Ross.
 
 On Wed, Dec 7, 2011 at 3:20 PM, Bohyun Kim k...@fiu.edu wrote:
  I almost wrote the same thing. Please let's make it obvious so
 that we don't have to think.
 
  Kudos to Chad for figuring this out.
  ***How did you even think to click the name?!***
 
  ~Bohyun
 
 
  -Original Message-
  From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On
 Behalf Of Chad Benjamin Nelson
  Sent: Wednesday, December 07, 2011 2:48 PM
  To: CODE4LIB@LISTSERV.ND.EDU
  Subject: Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
 
  I Almost wrote:
 
  Dear Lazyweb,
 
  Where are the tshirts designs?
 
  Instead I'll write -
 
  Needing to click on the name to see the design was not obvious,
 and it would have made voting for sessions much easier I suspect.
 
 
 
  Chad Nelson
  Web Services Programmer
  University Library
  Georgia State University
 
  e: cnelso...@gsu.edu
  t: 404 413 2771
  My Calendar
 
  
  From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of
 Angie Beiriger [beiri...@reed.edu]
  Sent: Wednesday, December 07, 2011 2:34 PM
  To: CODE4LIB@LISTSERV.ND.EDU
  Subject: [CODE4LIB] Vote Now: 2012 Conference T-shirt
 
  *It's time to cast your vote for the Code4lib 2012 Conference t-
 shirt
  design!*
 
  Visit http://vote.code4lib.org/election/22 to check out the
 excellent submissions for this year. You will need to log in to
 rank your choices.
  The voting will be open through Friday, December 16th.
 
  Happy voting!
 
  Angie Beiriger
  Reed College
  beiri...@reed.edu


Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Esme Cowles
I've been following this thread very closely, and find myself torn.  Doing all 
the HTML generation server-side seems like the easiest way to have a single set 
of template code that's shared between JS and non-JS paths, reducing complexity 
of the overall app, and making graceful degradation easier.  On the other hand, 
doing client-side HTML generation (or direct DOM updating) seems like it offers 
better performance, greatly reduced bandwidth, and a better fit if you want to 
create a reusable API.

I think there is a third way: using the same template code for both client-side 
and server side rendering.  The basic HTML version would retrieve pages 
rendered server-side, and the enhanced JS version would retrieve JSON and 
render the UI with the same templates (presumably with modular templates so the 
JS version would only have to update the areas with updated content, and not 
the entire page).  The only template systems I know of that have both client 
and server support are XSLT and Mustache.  Are there others?  Has anybody set 
up a system like this?

-Esme
--
Esme Cowles escow...@ucsd.edu

The wages of sin is death but so is the salary of virtue, and at least the
 evil get to go home early on Fridays. -- Terry Pratchett, Witches Abroad

On 12/7/2011, at 9:38 PM, Jonathan Rochkind wrote:

 Also, I've thought of a good reason myself: performance. If I'm adding
 an item to a list, it's a better user experience to update the display
 immediately rather than waiting for the server to send back a 200 OK,
 and handle the error or timeout case specially.
 
 While in general I tend toward the other the other thing you said, Does it 
 make sense to replicate the
 server-side functionality on the client? -- I think what you propose above 
 is legit. 
 
 MOST people don't write interfaces like that, even in js.  That is, an 
 interface that will update the user interface even before/without receiving 
 _anything_ back from the server. (But, in the best cases, produce and error 
 message and/or 'undo' the user interface action iff the server does later get 
 back with an error/failure message). 
 
 So if you're going to do that, then--- it kind of doesn't matter if the 
 server sends back HTML or JSON or anything else, the user interface is 
 updating before/without getting _anything_ from the server. But to the extent 
 the server's response then serves pretty much only as a 
 notification-of-failure or whatever, yeah, JSON is the way to go. 
 
 So, yeah, if you're going to go all the way there, that's a pretty cool thing 
 (if you can make sure the failure conditions are handled acceptably), sure, 
 go for it.


Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Chad Mills
I used to find myself in the same quandary when writing scripts intended for 
AJAX interaction.  I came around to a solution that works for me, and it is 
more of a programming style than anything.  I basically leave the option open 
to the requester of the AJAX script to declare an output format.  How I start 
is I form my response in an DOM, I use PHP.  I leave a format variable open in 
the request at the time of returning a response I either dump the XML, convert 
it to JSON, or run it though XSL stylesheet for HTML.  Starting out it took me 
longer to develop these AJAX utility scripts, but after a couple of them it's 
second nature to me.  It doesn't seem to any longer to develop, the format 
conversion is cheap, processing wise, and at the end and I leave the ultimate 
choice to whomever calls the AJAX script so I impose the least amount of 
restrictions on its use.

--
Chad Mills
Digital Library Architect
Ph: 732.932.8573 x123
Fax: 732.932.1386
Cell: 732.309.8538

Rutgers University Libraries
Scholarly Communication Center
Room 409D, Alexander Library
169 College Avenue, New Brunswick, NJ 08901

http://rucore.libraries.rutgers.edu/

- Original Message -
From: Esme Cowles escow...@ucsd.edu
To: CODE4LIB@LISTSERV.ND.EDU
Sent: Thursday, December 8, 2011 8:57:28 AM
Subject: Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: 
jQuery Ajax request to update a PHP variable)

I've been following this thread very closely, and find myself torn.  Doing all 
the HTML generation server-side seems like the easiest way to have a single set 
of template code that's shared between JS and non-JS paths, reducing complexity 
of the overall app, and making graceful degradation easier.  On the other hand, 
doing client-side HTML generation (or direct DOM updating) seems like it offers 
better performance, greatly reduced bandwidth, and a better fit if you want to 
create a reusable API.

I think there is a third way: using the same template code for both client-side 
and server side rendering.  The basic HTML version would retrieve pages 
rendered server-side, and the enhanced JS version would retrieve JSON and 
render the UI with the same templates (presumably with modular templates so the 
JS version would only have to update the areas with updated content, and not 
the entire page).  The only template systems I know of that have both client 
and server support are XSLT and Mustache.  Are there others?  Has anybody set 
up a system like this?

-Esme
--
Esme Cowles escow...@ucsd.edu

The wages of sin is death but so is the salary of virtue, and at least the
 evil get to go home early on Fridays. -- Terry Pratchett, Witches Abroad

On 12/7/2011, at 9:38 PM, Jonathan Rochkind wrote:

 Also, I've thought of a good reason myself: performance. If I'm adding
 an item to a list, it's a better user experience to update the display
 immediately rather than waiting for the server to send back a 200 OK,
 and handle the error or timeout case specially.
 
 While in general I tend toward the other the other thing you said, Does it 
 make sense to replicate the
 server-side functionality on the client? -- I think what you propose above 
 is legit. 
 
 MOST people don't write interfaces like that, even in js.  That is, an 
 interface that will update the user interface even before/without receiving 
 _anything_ back from the server. (But, in the best cases, produce and error 
 message and/or 'undo' the user interface action iff the server does later get 
 back with an error/failure message). 
 
 So if you're going to do that, then--- it kind of doesn't matter if the 
 server sends back HTML or JSON or anything else, the user interface is 
 updating before/without getting _anything_ from the server. But to the extent 
 the server's response then serves pretty much only as a 
 notification-of-failure or whatever, yeah, JSON is the way to go. 
 
 So, yeah, if you're going to go all the way there, that's a pretty cool thing 
 (if you can make sure the failure conditions are handled acceptably), sure, 
 go for it.


[CODE4LIB] JCDL 2012 Call for Participation

2011-12-08 Thread Howard, Barrie
Apologies for cross-posting

**

CALL FOR PARTICIPATION

12th ACM/IEEE-CS Joint Conference on Digital Libraries (JCDL 2012)
June 10-14, 2012
Washington, DC, USA

Hosted by The George Washington University and The Library of Congress

http://www.jcdl2012.infohttp://www.jcdl2012.info/

CALL FOR PAPERS

The ACM/IEEE Joint Conference on Digital Libraries is a major international 
forum focusing on digital libraries and associated technical, practical, 
organizational, and social issues. JCDL encompasses the many meanings of the 
term digital libraries, including (but not limited to) new forms of information 
institutions and organizations; operational information systems with all manner 
of digital content; new means of selecting, collecting, organizing, 
distributing, and accessing digital content; theoretical models of information 
media, including document genres and electronic publishing; and theory and 
practice of use of managed content in science and education.

IMPORTANT DATES

   * Full Papers due January 23, 2012
   * Short Papers, Panels, Posters  Demos, Workshops, Tutorials due January 
30, 2012
   * Notification of acceptance for Workshops and Tutorials: March 1, 2012
   * Notification of acceptance for Papers, Panels, Posters  Demos: March 21, 
2012
   * Doctoral Consortium Abstract submissions due March 31, 2012

CONFERENCE FOCUS

The theme for JCDL 2012 is #sharing #linking #using #preserving. Digital 
libraries, under a variety of names and modalities, are often part of the every 
day web experience. The challenge is how digital libraries can enhance user 
experience through providing stability in changing information environment, 
breaking down information silos, integrating into accepted practices of the 
web, and providing a range of access and services to resources across the web, 
both to human and machine users.

The intended community for this conference includes those interested in all 
aspects of digital libraries such as infrastructure; institutions; metadata; 
content; services; digital preservation; system design; scientific data 
management; workflows; implementation; interface design; human-computer 
interaction; performance evaluation; usability evaluation; collection 
development; intellectual property; privacy; electronic publishing; document 
genres; multimedia; social, institutional, and policy issues; user communities; 
and associated theoretical topics. JCDL welcomes submissions in these areas, 
and submissions associated with the JCDL 2012 theme of social media influenced 
themes of linking, sharing, usage, and preservation are particularly welcome. 
The conference sessions, workshops and tutorials will cover all these aspects.

Participation is sought from all parts of the world and from the full range of 
established and emerging disciplines and professions including computer 
science, information science, web science, data science, librarianship, data 
management, archival science and practice, museum studies and practice, 
information technology, medicine, social sciences, education and humanities. 
Representatives from academe, government, industry, and others are invited to 
participate.

JCDL 2012 will be held in Washington, DC on the campus of The George Washington 
University. The program is organized by an international committee of scholars 
and leaders in the digital libraries field and attendance is expected to 
include several hundreds of researchers, practitioners, managers, and students.

JCDL 2012 invites submissions of papers and proposals for posters, 
demonstrations, tutorials, and workshops that will make the conference an 
exciting and creative event to attend. As always, the conference welcomes 
contributions from all the fields that intersect to enable digital libraries. 
Topics include, but are not limited to:

   * Collaborative and participatory information environments
   * Cyberinfrastructure architectures, applications, and deployments
   * Data mining/extraction of structure from networked information
   * Digital library and Web Science curriculum development
   * Distributed information systems
   * Extracting semantics, entities, and patterns from large collections
   * Evaluation of online information environments
   * Impact and evaluation of digital libraries and information in education
   * Information and knowledge systems
   * Information policy and copyright law
   * Information visualization
   * Interfaces to information for novices and experts
   * Linked data and its applications
   * Personal digital information management
   * Retrieval and browsing
   * Scientific data curation, citation and scholarly publication
   * Social media, architecture, and applications
   * Social networks, virtual organizations and networked information
   * Social-technical perspectives of digital information
   * Studies of human factors in networked information
   * Theoretical models of information interaction and 

Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Brad Baxter
On Wed, Dec 7, 2011 at 5:02 PM, Nate Vack njv...@wisc.edu wrote:
 OK. So we have a fair number of very smart people saying, in essence,
 it's better to build your HTML in javascript than send it via ajax
 and insert it.

X in AJAX means XML, so if you send XHTML, you're good.  :-)


Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Bill Dueber
To these I would add:

* Reuse. The call you're making may be providing data that would be useful
in other contexts as well. If you're generating application-specific html,
that can't happen.

But really, separation of concerns is the biggest one. Having to dig
through both template and code to make stylistic changes is icky. Now
excuse me, I have to go work with PHP. And then take a shower to try to get
the smell off me.

On Wed, Dec 7, 2011 at 5:19 PM, Robert Sanderson azarot...@gmail.comwrote:

 Here's some off the top of my head:

 * Separation of concerns -- You can keep your server side data
 transfer and change the front end easily by working with the
 javascript, rather than reworking both.

 * Lax Security -- It's easier to get into trouble when you're simply
 inlining HTML received, compared to building the elements.  Getting
 into the same bad habits as SQL injection. It might not be a big deal
 now, but it will be later on.

 * Obfuscation -- It's easier to debug one layer of code rather than
 two at once. It's thus also easier to maintain the two layers of code,
 and easier to see at which end the system is failing.

 Rob

 On Wed, Dec 7, 2011 at 3:12 PM, Jonathan Rochkind rochk...@jhu.edu
 wrote:
  A fair number? Anyone but Godmar?
 
  On 12/7/2011 5:02 PM, Nate Vack wrote:
 
  OK. So we have a fair number of very smart people saying, in essence,
  it's better to build your HTML in javascript than send it via ajax
  and insert it.
 
  So, I'm wondering: Why? Is it an issue of data transfer size? Is there
  a security issue lurking? Is it tedious to bind events to the new /
  updated code? Something else? I've thought about it a lot and can't
  think of anything hugely compelling...
 
  Thanks!
  -Nate
 
 




-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library


Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

2011-12-08 Thread Mark A. Matienzo
On Thu, Dec 8, 2011 at 5:45 AM, Kåre Fiedler Christiansen
k...@statsbiblioteket.dk wrote:
 We're a bunch of Danes visiting the Code4Lib conference in Seattle. But the 
 prospect of a full week being offline on my trusted Android phone is scary. 
 And the price of international data roaming is simply scary.

 So I was wondering if any US carriers are selling data-enabled SIM cards, at 
 a price that would be reasonable for a week's usage, and which are also 
 available for visiting tourists?

Yes, several of them do, and for GSM your options are ATT and
T-Mobile. Your best option is probably a prepaid SIM card which is
refillable, but I can't speak to their rates offhand.

Mark


Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

2011-12-08 Thread Dhanushka Samarakoon
This is the best non-contract data plan I have seen so far.
5GB for $30 on T-mobile
http://www.walmart.com/ip/Tmobile-30-Wireless-Airtime-Card/15443357

A SIM card should be around $7

On Thu, Dec 8, 2011 at 4:45 AM, Kåre Fiedler Christiansen 
k...@statsbiblioteket.dk wrote:

 Hi all,

 Sorry for being semi-off-topic, but obviously you're the right bunch of
 people to know this...

 We're a bunch of Danes visiting the Code4Lib conference in Seattle. But
 the prospect of a full week being offline on my trusted Android phone is
 scary. And the price of international data roaming is simply scary.

 So I was wondering if any US carriers are selling data-enabled SIM cards,
 at a price that would be reasonable for a week's usage, and which are also
 available for visiting tourists?

 Any input welcome. Thanks.

 Best,
   Kåre



Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Shaun Ellis
I agree with Chad and Jason.  It's all about having many options because 
every situation is different.  Each will call for one format or another 
for efficiency, convenience, and the best user experience (among many 
other considerations).  In a current project, I'm using both JSON and 
HTML AJAX calls.


-Shaun

On 12/8/11 9:09 AM, Chad Mills wrote:

I used to find myself in the same quandary when writing scripts intended for 
AJAX interaction.  I came around to a solution that works for me, and it is 
more of a programming style than anything.  I basically leave the option open 
to the requester of the AJAX script to declare an output format.  How I start 
is I form my response in an DOM, I use PHP.  I leave a format variable open in 
the request at the time of returning a response I either dump the XML, convert 
it to JSON, or run it though XSL stylesheet for HTML.  Starting out it took me 
longer to develop these AJAX utility scripts, but after a couple of them it's 
second nature to me.  It doesn't seem to any longer to develop, the format 
conversion is cheap, processing wise, and at the end and I leave the ultimate 
choice to whomever calls the AJAX script so I impose the least amount of 
restrictions on its use.

--
Chad Mills
Digital Library Architect
Ph: 732.932.8573 x123
Fax: 732.932.1386
Cell: 732.309.8538

Rutgers University Libraries
Scholarly Communication Center
Room 409D, Alexander Library
169 College Avenue, New Brunswick, NJ 08901

http://rucore.libraries.rutgers.edu/

- Original Message -
From: Esme Cowlesescow...@ucsd.edu
To: CODE4LIB@LISTSERV.ND.EDU
Sent: Thursday, December 8, 2011 8:57:28 AM
Subject: Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: 
jQuery Ajax request to update a PHP variable)

I've been following this thread very closely, and find myself torn.  Doing all 
the HTML generation server-side seems like the easiest way to have a single set 
of template code that's shared between JS and non-JS paths, reducing complexity 
of the overall app, and making graceful degradation easier.  On the other hand, 
doing client-side HTML generation (or direct DOM updating) seems like it offers 
better performance, greatly reduced bandwidth, and a better fit if you want to 
create a reusable API.

I think there is a third way: using the same template code for both client-side 
and server side rendering.  The basic HTML version would retrieve pages 
rendered server-side, and the enhanced JS version would retrieve JSON and 
render the UI with the same templates (presumably with modular templates so the 
JS version would only have to update the areas with updated content, and not 
the entire page).  The only template systems I know of that have both client 
and server support are XSLT and Mustache.  Are there others?  Has anybody set 
up a system like this?

-Esme
--
Esme Cowlesescow...@ucsd.edu

The wages of sin is death but so is the salary of virtue, and at least the
  evil get to go home early on Fridays. -- Terry Pratchett, Witches Abroad

On 12/7/2011, at 9:38 PM, Jonathan Rochkind wrote:


Also, I've thought of a good reason myself: performance. If I'm adding
an item to a list, it's a better user experience to update the display
immediately rather than waiting for the server to send back a 200 OK,
and handle the error or timeout case specially.


While in general I tend toward the other the other thing you said, Does it 
make sense to replicate the
server-side functionality on the client? -- I think what you propose above is 
legit.

MOST people don't write interfaces like that, even in js.  That is, an 
interface that will update the user interface even before/without receiving 
_anything_ back from the server. (But, in the best cases, produce and error 
message and/or 'undo' the user interface action iff the server does later get 
back with an error/failure message).

So if you're going to do that, then--- it kind of doesn't matter if the server 
sends back HTML or JSON or anything else, the user interface is updating 
before/without getting _anything_ from the server. But to the extent the 
server's response then serves pretty much only as a notification-of-failure or 
whatever, yeah, JSON is the way to go.

So, yeah, if you're going to go all the way there, that's a pretty cool thing 
(if you can make sure the failure conditions are handled acceptably), sure, go 
for it.


--
Shaun D. Ellis
Digital Library Interface Developer
Firestone Library, Princeton University
voice: 609.258.1698 | sha...@princeton.edu


Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Jonathan Rochkind

On 12/8/2011 9:27 AM, Bill Dueber wrote:

To these I would add:

* Reuse. The call you're making may be providing data that would be useful
in other contexts as well. If you're generating application-specific html,
that can't happen.


Well, if the other contexts are Javascript, and your HTML is nice 
semantically structured with good classes and ID's  it actually ends 
up being just about as easy getting the data out of HTML with JQuery 
selectors as it would be with JSON.


This is kind of the direction of HTML5 microdata/schema.org --- 
realizing that properly structured semantic HTML can be pretty damn 
machine readable, so if you do that you can get human HTML and machine 
readability with only one representation, instead of having to maintain 
multiple representations. (In some of the scenarios we're talking about, 
there are potentially THREE representations to maintain -- server-side 
generated HTML, server-side generated JSON, AND js to turn the JSON into 
HTML).


But yeah, there are always lots of trade-offs. This particular question 
I think ends up depending on a lot on what choices you've made for the 
REST of your software stack. Each choice at each level has different 
trade-offs, but the most important thing is probably to reduce the 
'impedence' of making inconsistent choices in different places. That is 
-- if you're heavy into client-side JS app framework rendering of HTML 
already, then sure you've made your choice, stick to it.


Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

2011-12-08 Thread KREYCHE, MICHAEL
Based on past experience with T-Mobile I would check this out before buying it. 
I'm not sure the data will work on a non-T-Mobile phone. And if it does work on 
your own phone you might only get EDGE speed. 

Mike

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of 
Dhanushka Samarakoon
Sent: Thursday, December 08, 2011 10:07 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

This is the best non-contract data plan I have seen so far.
5GB for $30 on T-mobile
http://www.walmart.com/ip/Tmobile-30-Wireless-Airtime-Card/15443357

A SIM card should be around $7

On Thu, Dec 8, 2011 at 4:45 AM, Kåre Fiedler Christiansen 
k...@statsbiblioteket.dk wrote:

 Hi all,

 Sorry for being semi-off-topic, but obviously you're the right bunch of
 people to know this...

 We're a bunch of Danes visiting the Code4Lib conference in Seattle. But
 the prospect of a full week being offline on my trusted Android phone is
 scary. And the price of international data roaming is simply scary.

 So I was wondering if any US carriers are selling data-enabled SIM cards,
 at a price that would be reasonable for a week's usage, and which are also
 available for visiting tourists?

 Any input welcome. Thanks.

 Best,
   Kåre



Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread BRIAN TINGLE
returning JSONP is the the cool hipster way to go (well, not hipster cool 
anymore, but the hipsters were doing it before it went mainstream), but I'm not 
convinced it is inherently a problem to return HTML for use in AJAX type 
development in a non--ironic-retro way.  

On Dec 7, 2011, at 2:19 PM, Robert Sanderson wrote:

 * Lax Security -- It's easier to get into trouble when you're simply
 inlining HTML received, compared to building the elements.  Getting
 into the same bad habits as SQL injection. It might not be a big deal
 now, but it will be later on.

I've been scratching my head about this one.  Can someone elaborate on this?

Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Robert Sanderson
On Thu, Dec 8, 2011 at 9:14 AM, BRIAN TINGLE
brian.tingle.cdlib@gmail.com wrote:

 On Dec 7, 2011, at 2:19 PM, Robert Sanderson wrote:
 * Lax Security -- It's easier to get into trouble when you're simply
 inlining HTML received, compared to building the elements.  Getting
 into the same bad habits as SQL injection. It might not be a big deal
 now, but it will be later on.

 I've been scratching my head about this one.  Can someone elaborate on this?

If you blindly include whatever you get back directly into the page,
it might include either badly performing, out of date, or potentially
malicious script tags that subsequently destroy the page.  It's the
equivalent of blindly accepting web form input into an SQL query and
then wondering where your tables all disappeared off to.

Rob


Re: [CODE4LIB] Namespace management, was Models of MARC in RDF

2011-12-08 Thread Richard Wallis
On 7 December 2011 16:29, Karen Coyle li...@kcoyle.net wrote:

 (As an aside, there is some concern that the use of FRBR will make linking
 from library bibliographic data to non-library bibliographic data
 difficult, if not impossible. Having had some contact with members of the
 FRBR review group, they seem impervious to that concern.)

 kc


I somehow missed out on this thread and it's predecessor, until a major
fail in the British rail system resulted in an unexpected coffee with Owen
yesterday - I hope he got home OK.However the benefit of being late to
a conversation is that you can see where the points of friction are.  So a
few thoughts on those:

Why bother?
Transforming Marc in to RDF is an interesting and challenging exercise, but
there is little point in doing it without having some potential benefits in
mind beyond the it would be great to have our stuff in a new format


RDF is a means to an end
We shouldn't loose sight of the RDF TLA, Resource Description Framework -
it is a framework for describing [our] resources.   It is the, de facto,
standard for publishing Linked Data.   Publishing descriptions of our
resources as Linked Data does fall in to the potential benefits arena -
reuse, mixing, merging, lowering barriers to use of data across, and from
outside of, the library community.


If it waddles and quacks, it is probably still a duck
Transforming a Marc record to XMLMarc just created the same record in in a
different wrapper.  Apart from the technical benefit (of being able to use
generic tools to work with it), it did not move us much further forward
towards opening up our data to wider use. Transforming Marc, of any flavor,
into an RDF representation of a record still leaves us with a record per
item - a digital card catalogue equivalent.


A record is a silo within a silo
A record within a catalogue duplicates the publisher/author/subject/etc.
information stored in adjacent records describing items by the same
author/publisher/etc.  This community spends much of it's effort on the
best ways to index and represent this duplication to make records
accessible.   Ideally an author, for instance, should be described
[preferably only once] and then related to all the items they produced


Linked Data should be the goal
At the event mentioned by Mike, Linked Data and Libraries[1], the British
Library launched their initial data model for the British National
Bibliography[2].  One of the key concepts of Linked Data is to represent
data as a set of interlinked things. These things are referred to as
objects of interest, they are things about which we can make statements.
In this model you get statements about things (eg. books, authors,
publishers, publishing events, subjects, places, etc.) and the links
between them - not a record per item.


Storing Marc in an RDF triple, or link to it?
The question I would ask is, which consumer of your data would this be
useful for?  Secondly, whatever your answer, it does not make sense to say
that this item, or author, or publisher 'thing' was derived from a
particular Marc record - you could perhaps at data set, or graph, level
(using the provenance vocabulary) define that it was transformed from a
particular source, at a time, using a method, by a person/process.


Who's Ontology
Do we only use library domain ontologies/vocabularies or do we employ dc,
foaf, bibo, etc. ?  Do we use dc:creator which most of the [non-library]
world will understand, or some esoteric [to them] rda properties to
describe corporate and many other nuance of authorship?   If you want to
enable general application developers/data consumers to use your data, you
need to apply the well known [if possibly course-grained or lossy] terms.
If you want to preserve the rich detail extracted from the source Marc, you
need to delve deeper in to bibliographically oriented properties.   Can you
do both? Yes.  Should you do both? Probably.

~Richard.

I think I better stop now and contemplate a blog post to further these
thoughts.


[1]
http://consulting.talis.com/resources/presentations-from-linked-data-and-libraries-2011/
[2]http://consulting.talis.com/2011/07/british-library-data-model-overview/



-- 
Richard Wallis
Technology Evangelist, Talis
http://consulting.talis.com
Tel: +44 (0)7767 886 005

Linkedin: http://www.linkedin.com/in/richardwallis
Skype: richard.wallis1
Twitter: @rjw
IM: rjw3...@hotmail.com


Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Brian Tingle
On Thu, Dec 8, 2011 at 9:11 AM, Godmar Back god...@gmail.com wrote:


 Let me give you an example for why returning HTML is a difficult
 approach, to say the least, when it comes to rich AJAX applications. I
 had in my argument referred to a trend, connected to increasing
 richness and interactivity in AJAX applications being developed today.


don't get me wrong; I love hipsters and JSON.  JSONP callbacks are esp.
handy.  I still would not consume it from a source I did not trust.

 ...



 If we tell newbies (no offense meant by that term) that AJAX means
 send a request and then insert a chunk of HTML in your DOM, we're
 short-changing their view of the type of Rich Internet Application
 (RIA) AJAX today is equated with.

 sure, fair point -- I just don't think there is anything wrong with
generating HTML on the sever and injecting into the DOM if that makes the
most sense for what you are trying to do.  And for things that work that
way now, I don't see a need to rush and change it all to JSONP callbacks
because of some vague security concern.


  - Godmar



Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

2011-12-08 Thread Hogue Melanie
You might try T-Mobile. Explain what you need to do and see what they can 
offer. I use prepaid talk minutes from them and they allow me to pay by the day 
when I need a data conection.
 
Melanie Amy Hogue
Manager of Online Resources  Reports
Chattanooga-Hamilton County Bicentennial Library
423-757-5114



From: Code for Libraries on behalf of Kåre Fiedler Christiansen
Sent: Thu 12/8/2011 5:45 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] Availability of data-enabled temporary SIM cards



Hi all,

Sorry for being semi-off-topic, but obviously you're the right bunch of people 
to know this...

We're a bunch of Danes visiting the Code4Lib conference in Seattle. But the 
prospect of a full week being offline on my trusted Android phone is scary. And 
the price of international data roaming is simply scary.

So I was wondering if any US carriers are selling data-enabled SIM cards, at a 
price that would be reasonable for a week's usage, and which are also available 
for visiting tourists?

Any input welcome. Thanks.

Best,
  Kåre


Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

2011-12-08 Thread Hogue Melanie
My phone is an unlocked Blackberry and it works with the T-Mobile SIM card 
set up for prepaid service. I do normally use EDGE with wi-fi however - even 
though my BB can use GSM. I'm not sure how I am connecting when I buy the daily 
data pass.
 
If he puts a different SIM card in, wouldn't his phone technically be a 
T-Mobile phone?
 
Melanie Amy Hogue
Manager of Online Resources  Reports
Chattanooga-Hamilton County Bicentennial Library
423-757-5114



From: Code for Libraries on behalf of KREYCHE, MICHAEL
Sent: Thu 12/8/2011 11:13 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Availability of data-enabled temporary SIM cards



Based on past experience with T-Mobile I would check this out before buying it. 
I'm not sure the data will work on a non-T-Mobile phone. And if it does work on 
your own phone you might only get EDGE speed.

Mike

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of 
Dhanushka Samarakoon
Sent: Thursday, December 08, 2011 10:07 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

This is the best non-contract data plan I have seen so far.
5GB for $30 on T-mobile
http://www.walmart.com/ip/Tmobile-30-Wireless-Airtime-Card/15443357

A SIM card should be around $7

On Thu, Dec 8, 2011 at 4:45 AM, Kåre Fiedler Christiansen 
k...@statsbiblioteket.dk wrote:

 Hi all,

 Sorry for being semi-off-topic, but obviously you're the right bunch of
 people to know this...

 We're a bunch of Danes visiting the Code4Lib conference in Seattle. But
 the prospect of a full week being offline on my trusted Android phone is
 scary. And the price of international data roaming is simply scary.

 So I was wondering if any US carriers are selling data-enabled SIM cards,
 at a price that would be reasonable for a week's usage, and which are also
 available for visiting tourists?

 Any input welcome. Thanks.

 Best,
   Kåre



Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Jonathan Rochkind

On 12/8/2011 11:19 AM, Robert Sanderson wrote:

If you blindly include whatever you get back directly into the page,
it might include either badly performing, out of date, or potentially
maliciousscript  tags that subsequently destroy the page.  It's the
equivalent of blindly accepting web form input into an SQL query and
then wondering where your tables all disappeared off to.


Hmm, i'm not sure it's the _equivalent_, isn't JS (especially JS you 
wrote) going to only be getting HTML from servers running software you 
wrote/controlled?


Even if a server is just adding HTML to a page (no JS involved), it 
COULD be subject to an HTML injection attack, if the server is basing 
the HTML on user input without properly sanitizing it.


I don't think the fact that you've split the logic between the server 
and the JS  neccearily changes things. It's essentially just a 'remote 
procedure call'. The server is STILL responsible for delivering secure 
HTML -- exactly as it was when there was no JS involved at all, no?


Now, granted, it is a more complicated environment when there's JS 
involved, so there is more chance for a security bug.  But I wouldn't 
say it's the equivalent of blinding accepting web form input etc   
whether JS is involved or not, if the server is generating HTML, it's 
the server's job to _not_ blinding accept web form input and stick it 
into HTML.


If you have your JS asking _untrusted sources_ (instead of your own 
server) for HTML, then that might be a different story.


Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)

2011-12-08 Thread Jonathan Rochkind

On Thu, Dec 8, 2011 at 9:11 AM, Godmar Backgod...@gmail.com  wrote:


If we tell newbies (no offense meant by that term) that AJAX means
send a request and then insert a chunk of HTML in your DOM, we're
short-changing their view of the type of Rich Internet Application
(RIA) AJAX today is equated with.

sure, fair point -- I just don't think there is anything wrong with




I would not want to tell newbies that. But if we tell newbies that 
javascript communication with the server should _always_ mean sending 
JSON, and that sending HTML is unfashionable and they should never do 
it, I also think we're short-changing their view, and giving them cargo 
cult trend-following approaches. I think there are plenty of scenarios 
where either approach is justified and appropriate.  It depends on the 
context, it depends on the rest of your stack, it depends on what's 
going on. There is no substitute for actual thought and analysis and 
decision.


Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

2011-12-08 Thread KREYCHE, MICHAEL
I meant phone purchased from T-Mobile. Some devices they don't sell are 
blocked from using the prepaid data service.

Mike

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Hogue 
Melanie
Sent: Thursday, December 08, 2011 1:33 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

My phone is an unlocked Blackberry and it works with the T-Mobile SIM card 
set up for prepaid service. I do normally use EDGE with wi-fi however - even 
though my BB can use GSM. I'm not sure how I am connecting when I buy the daily 
data pass.
 
If he puts a different SIM card in, wouldn't his phone technically be a 
T-Mobile phone?
 
Melanie Amy Hogue
Manager of Online Resources  Reports
Chattanooga-Hamilton County Bicentennial Library
423-757-5114



From: Code for Libraries on behalf of KREYCHE, MICHAEL
Sent: Thu 12/8/2011 11:13 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Availability of data-enabled temporary SIM cards



Based on past experience with T-Mobile I would check this out before buying it. 
I'm not sure the data will work on a non-T-Mobile phone. And if it does work on 
your own phone you might only get EDGE speed.

Mike

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of 
Dhanushka Samarakoon
Sent: Thursday, December 08, 2011 10:07 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Availability of data-enabled temporary SIM cards

This is the best non-contract data plan I have seen so far.
5GB for $30 on T-mobile
http://www.walmart.com/ip/Tmobile-30-Wireless-Airtime-Card/15443357

A SIM card should be around $7

On Thu, Dec 8, 2011 at 4:45 AM, Kåre Fiedler Christiansen 
k...@statsbiblioteket.dk wrote:

 Hi all,

 Sorry for being semi-off-topic, but obviously you're the right bunch of
 people to know this...

 We're a bunch of Danes visiting the Code4Lib conference in Seattle. But
 the prospect of a full week being offline on my trusted Android phone is
 scary. And the price of international data roaming is simply scary.

 So I was wondering if any US carriers are selling data-enabled SIM cards,
 at a price that would be reasonable for a week's usage, and which are also
 available for visiting tourists?

 Any input welcome. Thanks.

 Best,
   Kåre



Re: [CODE4LIB] Models of MARC in RDF

2011-12-08 Thread Westbrook, Bradley
Hi, folks, 

I am just back into the office from a workshop and wanted to add to this 
thread.  As Declan noted, we at UC San Diego wrangle a lot of source metadata 
into RDF statements for our digital assets.  MARC records form a goodly portion 
of the source metadata that we transform.  We leave bits, sometime big bits, of 
the MARC record behind (we do not use 040, 041, 09x data in our DAMS), and we 
sometimes change some of the MARC data we do retain (300 extent statements are 
typically changed to reflect the digital object and no longer the analog object 
that was digitized).  And we add technical and rights data to the RDF that does 
not appear at all in the source MARC record.  The RDF we transform from MARC 
records does, however, carry one or more traces back to its source MARC record, 
often in the forms of a link to the record in our MARC catalog, the record 
identifier for that MARC record, and the OCLC record identifier.  

Brad W.

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of 
Fleming, Declan
Sent: Tuesday, December 06, 2011 2:43 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF

Hi - point at it where?  We could point back to the library catalog that we 
harvested in the MARC to MODS to RDF process, but what if that goes away?  Why 
not write ourselves a 1K insurance policy that sticks with the object for its 
life?

D

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Owen 
Stephens
Sent: Tuesday, December 06, 2011 8:06 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF

I'd suggest that rather than shove it in a triple it might be better to point 
at alternative representations, including MARC if desirable (keep meaning to 
blog some thoughts about progressively enhanced metadata...)

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: o...@ostephens.com
Telephone: 0121 288 6936

On 6 Dec 2011, at 15:44, Karen Coyle wrote:

 Quoting Fleming, Declan dflem...@ucsd.edu:
 
 Hi - I'll note that the mapping decisions were made by our metadata 
 services (then Cataloging) group, not by the tech folks making it all 
 work, though we were all involved in the discussions.  One idea that 
 came up was to do a, perhaps, lossy translation, but also stuff one 
 triple with a text dump of the whole MARC record just in case we 
 needed to grab some other element out we might need.  We didn't do 
 that, but I still like the idea.  Ok, it was my idea.  ;)
 
 I like that idea! Now that disk space is no longer an issue, it makes good 
 sense to keep around the original state of any data that you transform, 
 just in case you change your mind. I hadn't thought about incorporating the 
 entire MARC record string in the transformation, but as I recall the average 
 size of a MARC record is somewhere around 1K, which really isn't all that 
 much by today's standards.
 
 (As an old-timer, I remember running the entire Univ. of California 
 union catalog on 35 megabytes, something that would now be considered 
 a smallish email attachment.)
 
 kc
 
 
 D
 
 -Original Message-
 From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf 
 Of Esme Cowles
 Sent: Monday, December 05, 2011 11:22 AM
 To: CODE4LIB@LISTSERV.ND.EDU
 Subject: Re: [CODE4LIB] Models of MARC in RDF
 
 I looked into this a little more closely, and it turns out it's a little 
 more complicated than I remembered.  We built support for transforming to 
 MODS using the MODS21slim2MODS.xsl stylesheet, but don't use that.  Instead, 
 we use custom Java code to do the mapping.
 
 I don't have a lot of public examples, but there's at least one public 
 object which you can view the MARC from our OPAC:
 
 http://roger.ucsd.edu/search/.b4827884/.b4827884/1,1,1,B/detlmarc~123
 4567FF=1,0,
 
 The public display in our digital collections site:
 
 http://libraries.ucsd.edu/ark:/20775/bb0648473d
 
 The RDF for the MODS looks like:
 
mods:classification rdf:parseType=Resource
mods:authoritylocal/mods:authority
rdf:valueFVLP 222-1/rdf:value
/mods:classification
mods:identifier rdf:parseType=Resource
mods:typeARK/mods:type

 rdf:valuehttp://libraries.ucsd.edu/ark:/20775/bb0648473d/rdf:value
/mods:identifier
mods:name rdf:parseType=Resource
mods:namePartBrown, Victor W/mods:namePart
mods:typepersonal/mods:type
/mods:name
mods:name rdf:parseType=Resource
mods:namePartAmateur Film Club of San Diego/mods:namePart
mods:typecorporate/mods:type
/mods:name
mods:originInfo rdf:parseType=Resource
mods:dateCreated[196-]/mods:dateCreated
/mods:originInfo
mods:originInfo rdf:parseType=Resource
mods:dateIssued2005/mods:dateIssued
mods:publisherFilm and Video