Re: [CODE4LIB] Curious about Cell Phone Barcode Scanning Apps
Thanks for the tips. I too am actually hoping to build a single platform first. I'm thinking that Android has the most robust set of tools available, but i-Phone or even Palm might be the way to go. My plan is to try to generate a set of "similar" titles by Author and Subject, hopefully organized into three tabs (local OPAC/Library Thing/Worldcat). I'm doing this as an independent study in Library School. I'd love to compare notes if you have time. -Matt On Tue, May 12, 2009 at 11:16 AM, Adam Brin wrote: > I've also been doing some research into this. There are a number of > toolkits out there. zxing gets most of the way there and it has an iPhone > package as well (an app called "barcodes"). Most of them are still in the > early stages. > > I've also seen: > - http://zebra.sourceforge.net/ > - http://www.bruji.com/cocoa/barcode.html > - http://code.google.com/p/jjil/ > > JJill seems to be in the backend of a bunch of them, but i've had a lot of > trouble getting it setup. I've been taking a conceptually different > approach from Jonathan, focusing my thought on one platform that can > showcase the app as opposed to solving the problem for all phones. > > - adam > > > On May 8, 2009, at 7:47 AM, Jonathan Rochkind wrote: > > I started to do a just bit of web research in this. Open source barcode >> photo recognition software looks like it's _just_ starting to become >> realistically available. This was the product that looked most promissing in >> my web research (not sure if it's what the Android app is using): >> >> http://code.google.com/p/zxing/ >> >> My Umlaut software would be an _ideal_ end-point of barcode recognition, >> is why I started to look into it. Umlaut is designed specifically to meet >> the goal of taking a known item citation (such as an ISBN, sure), and >> returning a range of library availability and services for that item. >> http://wiki.code4lib.org/index.php/Umlaut >> >> The next step, which I haven't figured out yet, is how to get your >> software to participate in MMS/SMS architecture -- in particular to receive >> MMS/SMS messages in a way that's affordable to you and convenient to your >> users. (It looks like some but not all cell phones can send MMS messages to >> email, but not necessarily as conveniently as sending MMS to a cell number; >> but I'm not sure if there's a cheap way to have software receive MMS >> messages at a cell number. The Android app of course performs all it's >> processing on the Android itself, which you can do on a device-by-device >> basis for devices powerful enough for that; but I too am attracted to the >> idea of an MMS solution that would work on any MMS capable device, with no >> need to customize per device). >> >> I also haven't actually looked at the zxing code yet. >> >> But I'd love to have Umlaut able to receive an MMS message, and give the >> user back a concise list of library services/links. So many interesting >> projects, not enough time. >> >> Jonathan >> >> Matt Amory wrote: >> >>> I'm interested in some advice on building an app to pickup barcode data >>> through a cell phone camera and return OPAC/Library Thing/WorldCat etc. >>> results to a mobile interface. >>> I know that Android has a UPC barcode reader linked to a shopping app, >>> and >>> I'm wondering if this can be used or repurposed, or if there's a better >>> place to begin. >>> >>> Thanks! >>> >>> > ___ > Adam Brin > ph: (510) 987.0636fx: (510) 287.6123 > adam.b...@ucop.edu > -- Matt Amory (917) 771-4157 matt.am...@gmail.com
[CODE4LIB] Call for proposals: EdUI Conference w/ Jared Spool, Michael Wesch, Molly Holzschlag and others
Colleagues, Please excuse cross postings. = CALL FOR PARTICIPATION, EDUI 2009 CONFERENCE = * Have you completed an innovative Web project at your institution that you want to tell others about? * Are you enthusiastic about introducing new technologies and techniques to other Web professionals? * Do you want to share your ideas about user experience design and development for higher education or other large institutions? * Are you ready to add something cool to your CV or resume? Then we invite you to help make the EdUI 2009 conference a success! Submit your presentation proposal by July 1 2009. -- About the Conference -- The University of Virginia (U.Va.), in partnership with User Interface Engineering (UIE), invites presentation proposals for EdUI 2009: Remaining , to be held September 21–22, 2009 in Charlottesville, Virginia on the U.Va. campus. Economic times might be lean, but professional growth has never been more important. EdUI 2009: Remaining will provide an opportunity for Web professionals in higher education and local and regional businesses to share ideas about the opportunities and challenges surrounding web user interaction, interface design, and development. The conference will be particularly useful for: * Web Designers * Web Developers * Webmasters * User experience and interaction design professionals We are delighted that our speaking lineup so far includes Jared Spool, founder of User Interface Engineering, as keynote speaker, with Michael Wesch, Dana Chisnell, Derek Featherstone, Molly Holzschlag & Dan Rubin as headliners. Jared, Dana, Derek, Molly, and Dan are some of today’s top authors and speakers in web design and development. Michael Wesch, featured in the most recent issue of National Geographic magazine, is widely known for his popular Youtube videos on the social and cultural impact of new media. Find out more about these fantastic speakers at: http://www.uie.com/about/ http://www.google.com/profiles/mike.wesch http://www.usabilityworks.net/ http://boxofchocolates.ca/about http://molly.com/about.php http://superfluousbanter.org/about/ Keep up with the conference: Email - http://eduiconf.org/joinlist Twitter - http://twitter.com/edui2009 Facebook - search for "Edui 2009" and join our group -- Be a Part of It -- Please join us for this exciting conference. We seek dynamic speakers willing to share their knowledge and expertise about user experience design and development through case studies, workshops, tutorials, and poster sessions. Preference is given to presentations that offer practical methods and ready-to-use techniques and tools. Possible topics may include: * Innovation and change in higher ed or large institution web sites * Web strategies * User experience design / interaction design * Graphics workflows * User testing * CSS tips & techniques * Web standards * Web accessibility * Reusability in web development * Web applications frameworks * Interaction & web applications testing * Use of social media Conference sessions will be 40 minutes long with a 5-minute question and answer period. Longer topics can be proposed to spread across two consecutive sessions in a "Part 1, Part 2" format. -- Submission Guidelines & Important Dates -- If you would like to be considered as a speaker, please submit your ideas online at http://eduiconf.org/proposals/ by July 1, 2009. The Conference Committee will review all submissions. Notification regarding acceptance will be made by July 22nd. If your proposal is selected, the primary speaker will receive a gratis registration to the full conference, including lunches and a reception. Conference organizers are not responsible for speakers' travel and accommodation costs. We look forward to receiving your ideas and suggestions by July 1, 2009. -- Best wishes, EdUI Conference Organizers
Re: [CODE4LIB] Curious about Cell Phone Barcode Scanning Apps
I've also been doing some research into this. There are a number of toolkits out there. zxing gets most of the way there and it has an iPhone package as well (an app called "barcodes"). Most of them are still in the early stages. I've also seen: - http://zebra.sourceforge.net/ - http://www.bruji.com/cocoa/barcode.html - http://code.google.com/p/jjil/ JJill seems to be in the backend of a bunch of them, but i've had a lot of trouble getting it setup. I've been taking a conceptually different approach from Jonathan, focusing my thought on one platform that can showcase the app as opposed to solving the problem for all phones. - adam On May 8, 2009, at 7:47 AM, Jonathan Rochkind wrote: I started to do a just bit of web research in this. Open source barcode photo recognition software looks like it's _just_ starting to become realistically available. This was the product that looked most promissing in my web research (not sure if it's what the Android app is using): http://code.google.com/p/zxing/ My Umlaut software would be an _ideal_ end-point of barcode recognition, is why I started to look into it. Umlaut is designed specifically to meet the goal of taking a known item citation (such as an ISBN, sure), and returning a range of library availability and services for that item. http://wiki.code4lib.org/index.php/Umlaut The next step, which I haven't figured out yet, is how to get your software to participate in MMS/SMS architecture -- in particular to receive MMS/SMS messages in a way that's affordable to you and convenient to your users. (It looks like some but not all cell phones can send MMS messages to email, but not necessarily as conveniently as sending MMS to a cell number; but I'm not sure if there's a cheap way to have software receive MMS messages at a cell number. The Android app of course performs all it's processing on the Android itself, which you can do on a device-by-device basis for devices powerful enough for that; but I too am attracted to the idea of an MMS solution that would work on any MMS capable device, with no need to customize per device). I also haven't actually looked at the zxing code yet. But I'd love to have Umlaut able to receive an MMS message, and give the user back a concise list of library services/links. So many interesting projects, not enough time. Jonathan Matt Amory wrote: I'm interested in some advice on building an app to pickup barcode data through a cell phone camera and return OPAC/Library Thing/WorldCat etc. results to a mobile interface. I know that Android has a UPC barcode reader linked to a shopping app, and I'm wondering if this can be used or repurposed, or if there's a better place to begin. Thanks! ___ Adam Brin ph: (510) 987.0636fx: (510) 287.6123 adam.b...@ucop.edu
Re: [CODE4LIB] Curious about Cell Phone Barcode Scanning Apps
On Fri, 8 May 2009, Joe Atzberger wrote: Google provided the barcode-recognition line-interpolation software as open source for Android developers to build on. That explains why I have about 4 barcode-scanning apps on the G1. Note that most common cellphone camera's haven't advanced enough to get reliable resolution for barcodes, in particular the up-close macro-like distances you would use a scanner at. My old nokia, despite the 3 MP camera, couldn't get focus up close. At ASIS&T two years ago, one of the folks from Microsoft Research was handing out little lenses to put over your cellphone camera to change the focal length so it'd work for scanning barcodes. (I'm only interested in this sort of thing as I deal with the Friends of the Library book sale, and I'd love to know if something actually has significant value and would be worth trying to sell through alternate means ... and I'm too cheap to shell out for one of the services where they modify your cell phone and you have to pay an ongoing service fee) -Joe
Re: [CODE4LIB] One Data Format Identifier (and Registry) to Rule Them All
Ross Singer wrote: My point is that there's a step before that, possibly, where the "theory" behind unAPI, Jangle, whatever, is tested to even see if it's going in the right direction before writing it up formally as an RFC. I don't think the lack of adoption of unAPI has anything to do with the prose of it's specification document. The RFC format is useful for later adopters, but people that, say, jumped on the Atom syndication format as a good idea didn't need an RFC first, they developed a spec, /then/ wrote the standard once they had an idea of how it needed to work. I think this is a really important point, for us to get used to. Good formal standards are built _from_ best practices tested through experience. Too often we try to do it vice versa, and wind up spending an awful lot of time on the details of standards that turn out to actually not solve the problem we wanted to solve as optimally as it could have been solved. Jonathan
Re: [CODE4LIB] One Data Format Identifier (and Registry) to Rule Them All
On Tue, May 12, 2009 at 6:21 AM, Jakob Voss wrote: > Ross Singer wrote: > >>> >>> http://unapi.info/";> >>> http://xmlns.com/foaf/0.1/"/> >>> >> >> I generally agree with this, but what about formats that aren't XML or >> RDF based? How do I also say that you can grab my text/x-vcard? Or >> my application/marc record? There is still lots of data I want that >> doesn't necessarily have these characteristics. > > In my blog posting I included a way to specify mime types (such as as > text/x-vcard or application/marcURI) as URI. According to RFC 2220 the > application/marc type refers to the "harmonized USMARC/CANMARC > specification" whatever this is - so the mime type can be used as format > identifier. For vCard there is an RDF namespace and a (not very nice) XML > namespace: > > http://www.w3.org/2001/vcard-rdf/3.0# > vcard-temp (see http://xmpp.org/registrar/namespaces.html) > This is vCard as RDF, not vCard the format (which is text based). It would be the equivalent of saying, "here's an hCard, it's the same thing, right?" although the reason I may be requesting a vCard in its native format is because I have a vCard parser or an application that consumes them (Exchange, for example). > > That depends whether you want to be taken serious outside the library > community and target at the web as a whole or not. > My point is that there's a step before that, possibly, where the "theory" behind unAPI, Jangle, whatever, is tested to even see if it's going in the right direction before writing it up formally as an RFC. I don't think the lack of adoption of unAPI has anything to do with the prose of it's specification document. The RFC format is useful for later adopters, but people that, say, jumped on the Atom syndication format as a good idea didn't need an RFC first, they developed a spec, /then/ wrote the standard once they had an idea of how it needed to work. -Ross.
Re: [CODE4LIB] One Data Format Identifier (and Registry) to Rule Them All
Ross Singer wrote: http://unapi.info/";> http://xmlns.com/foaf/0.1/"/> I generally agree with this, but what about formats that aren't XML or RDF based? How do I also say that you can grab my text/x-vcard? Or my application/marc record? There is still lots of data I want that doesn't necessarily have these characteristics. In my blog posting I included a way to specify mime types (such as as text/x-vcard or application/marcURI) as URI. According to RFC 2220 the application/marc type refers to the "harmonized USMARC/CANMARC specification" whatever this is - so the mime type can be used as format identifier. For vCard there is an RDF namespace and a (not very nice) XML namespace: http://www.w3.org/2001/vcard-rdf/3.0# vcard-temp (see http://xmpp.org/registrar/namespaces.html) If you want to identify a defined format, there is almost always an identifier you can reuse - if not, ask the creator of the format. The problem is not in identifiers or the complexity of formats but in people that create and use formats that are not well defined. What about XML formats that have no namespace? JSON objects that conform to a defined structure? Protocol Buffers? If something does not conform to a defined structure then it is no format at all but data garbage (yes, we have a lot of this in library systems but that's no excuse). To refer to XML or JSON in general there are mime types. If you want to identify something more specific there must be a definition of it or you are lost anyway. And, while I didn't really want to wade into these waters, what about formats that are really only used to carry other formats, where it's the *other* format that really matters (METS, Atom, OpenURL XML, etc.)? A container format with restricted carried format is a subset of the container format. If you cannot handle the whole but only a subset then you should only ask for the subset. There are three possibilities: 1. implicitely define the container format and choose the carried format. This is what SRU does - you ask for the record format but you always get the SRU response format as container with embedded record format. 2. implicitely define the carried format and choose the container format 3. define a new format as combination of container and carried format unAPI should be revised and specified bore strictly to become an RFC anyway. Yes, this requires a laborious and lengthy submission and review process but there is no such thing as a free lunch. Yeah, I have no problem with this (same with Jangle). The argument could be made, however, is there a cowpath yet to be paved? That depends whether you want to be taken serious outside the library community and target at the web as a whole or not. Cheers, Jakob -- Jakob Voß , skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de
