Re: [CODE4LIB] Models of MARC in RDF
Fair point. Just instinct on my part that putting it in a triple is a bit ugly :) It probably doesn't make any difference, although I don't think storing in a triple ensures that it sticks to the object (you could store the triple anywhere as well) Owen Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com Telephone: 0121 288 6936 On 6 Dec 2011, at 22:43, Fleming, Declan wrote: 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 Library, University of California, San Diego, La Jolla, CA 92093-0175 http://orpheus.ucsd.edu/fvl/FVLPAGE.HTM/mods:publisher /mods:originInfo mods:physicalDescription rdf:parseType=Resource mods:digitalOriginreformatted digital/mods:digitalOrigin mods:note16mm; 1 film reel (25 min.) :; sd., col. ;/mods:note /mods:physicalDescription mods:subject rdf:parseType=Resource mods:authoritylcsh/mods:authority mods:topicRanching/mods:topic /mods:subject etc. There is definitely some loss in the conversion process -- I don't know enough about the MARC leader and control fields to know if they are captured in the MODS and/or RDF in some way. But there are quite a
Re: [CODE4LIB] Models of MARC in RDF
When I did a project converting records from UKMARC - MARC21 we kept the UKMARC records for a period (about 5 years I think) while we assured ourselves that we hadn't missed anything vital. We did occasionally refer back to the older record to check things, but having not found any major issues with the conversion after that period we felt confident disposing of the record. This is the type of usage I was imagining for a copy of the MARC record in this scenario. Owen Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com Telephone: 0121 288 6936 On 7 Dec 2011, at 01:52, Montoya, Gabriela wrote: One critical thing to consider with MARC records (or any metadata, for that matter) is that it they are not stagnant, so what is the value of storing entire record strings into one triple if we know that metadata is volatile? As an example, UCSD has over 200,000 art images that had their metadata records ingested into our local DAMS over five years ago. Since then, many of these records have been edited/massaged in our OPAC (and ARTstor), but these updated records have not been refreshed in our DAMS. Now we find ourselves needing to desperately have the What is our database of record? conversation. I'd much rather see resources invested in data synching than spending it in saving text dumps that will most likely not be referred to again. Dream Team for Building a MARC RDF Model: Karen Coyle, Alistair Miles, Diane Hillman, Ed Summers, Bradley Westbrook. Gabriela -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen Coyle Sent: Tuesday, December 06, 2011 7:44 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Models of MARC in RDF 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~1234 567FF=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 Library, University of California, San Diego, La Jolla, CA 92093-0175 http://orpheus.ucsd.edu/fvl/FVLPAGE.HTM/mods:publisher /mods:originInfo mods:physicalDescription rdf:parseType=Resource mods:digitalOriginreformatted
Re: [CODE4LIB] Namespace management, was Models of MARC in RDF
On 7 Dec 2011, at 00:38, Alexander Johannesen wrote: Hiya, Karen Coyle li...@kcoyle.net wrote: I wonder how easy it will be to manage a metadata scheme that has cherry-picked from existing ones, so something like: dc:title bibo:chapter foaf:depiction Yes, you're right in pointing out this as a problem. And my answer is; it's complicated. My previous rant on this list was about data models*, and dangnabbit if this isn't related as well. What your example is doing is pointing out a new model based on bits of other models. This works fine, for the most part, when the concepts are simple; simple to understand, simple to extend. Often you'll find that what used to be unclear has grown clear over time (as more and more have used FOAF, you'll find some things are more used and better understood, while other parts of it fade into 'we don't really use that anymore') But when things get complicated, it *can* render your model unusable. Mixed data models can be good, but can also lead directly to meta data hell. For example ; dc:title foaf:title Ouch. Although not a biggie, I see this kind of discrepancy all the time, so the argument against mixed models is of course that the power of definition lies with you rather than some third-party that might change their mind (albeit rare) or have similar terms that differ (more often). I personally would say that the library world should define RDA as you need it to be, and worry less about reuse at this stage unless you know for sure that the external models do bibliographic meta data well. I agree this is a risk, and I suspect there is a further risk around simply the feeling of 'ownership' by the community - perhaps it is easier to feel ownership over an entire ontoloy than an 'application profile' of somekind. It maybe that mapping is the solution to this, but if this is really going to work I suspect it needs to be done from the very start - otherwise it is just another crosswalk, and we'll get varying views on how much one thing maps to another (but perhaps that's OK - I'm not looking for perfection) That said, I believe we need absolutely to be aiming for a world in which we work with mixed ontologies - no matter what we do other, relevant, data sources will use FOAF, Bibo etc.. I'm convinced that this gives us the opportunity to stop treating what are very mixed materials in a single way, while still exploiting common properties. For example Musical materials are really not well catered for in MARC, and we know there are real issues with applying FRBR to them - and I see the implementation of RDF/Linked Data as an opportunity to tackle this issue by adopting alternative ontologies where it makes sense, while still assigning common properties (dc:title) where this makes sense. HOWEVER! When we're done talking about ontologies and vocabularies, we need to talk about identifiers, and there I would swing the other way and let reuse govern, because it is when you reuse an identifier you start thinking about what that identifiers means to *both* parties. Or, put differently ; It's remarkably easier to get this right if the identifier is a number, rather than some word. And for that reason I'd say reuse identifiers (subject proxies) as they are easier to get right and bring a lot of benefits, but not ontologies (model proxies) as they can be very difficult to get right and don't necessarily give you what you want. Agreed :)
Re: [CODE4LIB] Namespace management, was Models of MARC in RDF
Hi Owen - I am doing a paper on FRBR, RDF, and linked data, so this thread is very helpful for me. Can you describe the issue with musical materials in MARC and FRBR's impact on them? TIA, Laura On Wed, Dec 7, 2011 at 3:00 AM, Owen Stephens o...@ostephens.com wrote: That said, I believe we need absolutely to be aiming for a world in which we work with mixed ontologies - no matter what we do other, relevant, data sources will use FOAF, Bibo etc.. I'm convinced that this gives us the opportunity to stop treating what are very mixed materials in a single way, while still exploiting common properties. For example Musical materials are really not well catered for in MARC, and we know there are real issues with applying FRBR to them - and I see the implementation of RDF/Linked Data as an opportunity to tackle this issue by adopting alternative ontologies where it makes sense, while still assigning common properties (dc:title) where this makes sense. __ L.B. Johnson Library Tech Program Student City College of San Francisco http://lbjtech.zzl.org CCSF *Guardsman *Archive Blog http://theguardsmandigitalarchive.com
Re: [CODE4LIB] jQuery Ajax request to update a PHP variable
On Tue, Dec 6, 2011 at 3:40 PM, Doran, Michael D do...@uta.edu wrote: Current trends certainly go in the opposite direction, look at jQuery Mobile. I agree that jQuery Mobile is very popular now. However, that in no way negates the caution. One could consider it as a tragedy of the commons in which a user's iPhone battery is the shared resource. Why should I as a developer (rationally consulting my own self-interest) conserve battery power that doesn't belong to me, just so some other developer's app can use that resource? I'm just playing the devil's advocate here. ;-) You're taking it as given that the use of JavaScript on a mobile device is significantly less energy-efficient than an approach that would exercise only the HTML parsing path. Be careful here, intuition can be misleading. Devices cannot send HTML to their displays. It takes energy to parse it, and energy to render it. Time is roughly proportional to energy. Where do you think most time/energy is spent in? (page-provided) JavaScript execution, HTML parsing, or page layout/rendering? Based on the information I have available to me (I'd appreciate pointers to other studies), JS execution does not dominate - it ranks last behind Page layout and rendering [1], even for sites that are JS heavy, such as webmail sites. Interestingly, a large part of that is evaluating CSS selectors. On a related note, let me point out that there are many ways to change the DOM on the client. Client-side templating frameworks such as knockout.js or jQuery tmpl produce HTML (which then must be parsed), but modern AJAX frameworks such as ZK don't produce any HTML at all, skipping parsing altogether. I meant to add another reason why at this point teaching newbies an AJAX style that relies on HTML-returning entry points is a really bad idea, and that is the move from read-only applications (like Nate's) to applications that actually update state on the server. In this case, multiple parts of the client page (perhaps a label here, a link there) need to be updated. Expressing this in HTML is cumbersome, to say the least. (As an aside, I note that AJAX frameworks such as ZK, which pursued the HTML approach in their first iterations, have moved away from it. Compare the client/server traffic on a ZK 3.x application to the one in a ZK 5. app to see this.) For those interested in how to use one of possible client-side approaches I'm suggesting, I prototyped Nate's application using only client-side templating: http://libx.lib.vt.edu/services/popsubjects/cs/ It uses knockout.js's data binding facilities as well as (due to qTip 1.0's design) the jQuery tmpl engine. Read the (small, self-contained) source to learn about the server-side entry points. (I should point out that in this case, the need for the book cover ISBNs to be retrieved remotely is somewhat contrived; they should probably be sent along with the page in the first place.) A side effect of this JSON-oriented design is that it results in 2 nice JSON-P web services that can be embedded/used in other pages/applications. - Godmar [1] http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pubfiles/login.pdf
Re: [CODE4LIB] Namespace management, was Models of MARC in RDF
Quoting Owen Stephens o...@ostephens.com: I agree this is a risk, and I suspect there is a further risk around simply the feeling of 'ownership' by the community - perhaps it is easier to feel ownership over an entire ontoloy than an 'application profile' of somekind. It maybe that mapping is the solution to this, but if this is really going to work I suspect it needs to be done from the very start - otherwise it is just another crosswalk, and we'll get varying views on how much one thing maps to another (but perhaps that's OK - I'm not looking for perfection) I agree with Owen here. One of the advantages of using a mixed vocabulary is that it forces you to think about your own data in relation to that of others, and thus makes it less likely that you will end up in a silo. Just creating your data in RDF is not enough to making linking happen. Look at where LCSH sits on the LD cloud[1] and you see that there are very few links to it. That's not because it isn't in proper RDF, it's because quite frankly no one outside of libraries has much use for library subject headings in their current state. I think that we (whoever we is in this case) should be working hard to create links from RDA elements (which are already defined in RDF)[2] to other vocabularies, like FOAF, DC, BIBO, etc. If it should turn out that links of that nature cannot be made, for example because the content of the data would be significantly different (Tolkien, J. R. R., John Ronald Reuel, 1892-1973 v. J. R. R. Tolkien) then we need to find a way to MAKE our data play well with that of others. The problem that we have, IMNSHO, is not so much our data FORMAT but our DATA itself. If we don't consider linking outside of the library world, we will just create another silo for ourselves; an RDF silo, but still a silo. (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 [1] http://linkeddata.org [2] http://rdvocab.info That said, I believe we need absolutely to be aiming for a world in which we work with mixed ontologies - no matter what we do other, relevant, data sources will use FOAF, Bibo etc.. I'm convinced that this gives us the opportunity to stop treating what are very mixed materials in a single way, while still exploiting common properties. For example Musical materials are really not well catered for in MARC, and we know there are real issues with applying FRBR to them - and I see the implementation of RDF/Linked Data as an opportunity to tackle this issue by adopting alternative ontologies where it makes sense, while still assigning common properties (dc:title) where this makes sense. HOWEVER! When we're done talking about ontologies and vocabularies, we need to talk about identifiers, and there I would swing the other way and let reuse govern, because it is when you reuse an identifier you start thinking about what that identifiers means to *both* parties. Or, put differently ; It's remarkably easier to get this right if the identifier is a number, rather than some word. And for that reason I'd say reuse identifiers (subject proxies) as they are easier to get right and bring a lot of benefits, but not ontologies (model proxies) as they can be very difficult to get right and don't necessarily give you what you want. Agreed :) -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
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] Vote Now: 2012 Conference T-shirt
Who do I talk to about the fact that I can't access the voting? Visit http://vote.code4lib.org/election/22 to check out the excellent -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu
Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
Hi Tania, If you haven't already, you can register for an account at http://code4lib.org/user/register. Once you have your account set up, you can then sign in to vote. Thanks, Becky -- Becky Yoose Systems Librarian Grinnell College Libraries On Wed, Dec 7, 2011 at 1:52 PM, Tania Fersenheim tan...@brandeis.eduwrote: Who do I talk to about the fact that I can't access the voting? Visit http://vote.code4lib.org/election/22 to check out the excellent -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu
Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
http://code4lib.org/user/password -Ross. On Wed, Dec 7, 2011 at 3:14 PM, Tania Fersenheim tan...@brandeis.edu wrote: I have an account leftover from voting last year but I can't remember how to get in nor can I see a link to alert and admin to my tribulations. On Wed, Dec 7, 2011 at 2:59 PM, Becky Yoose b.yo...@gmail.com wrote: Hi Tania, If you haven't already, you can register for an account at http://code4lib.org/user/register. Once you have your account set up, you can then sign in to vote. Thanks, Becky -- Becky Yoose Systems Librarian Grinnell College Libraries On Wed, Dec 7, 2011 at 1:52 PM, Tania Fersenheim tan...@brandeis.eduwrote: Who do I talk to about the fact that I can't access the voting? Visit http://vote.code4lib.org/election/22 to check out the excellent -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu
Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
I have an account leftover from voting last year but I can't remember how to get in nor can I see a link to alert and admin to my tribulations. On Wed, Dec 7, 2011 at 2:59 PM, Becky Yoose b.yo...@gmail.com wrote: Hi Tania, If you haven't already, you can register for an account at http://code4lib.org/user/register. Once you have your account set up, you can then sign in to vote. Thanks, Becky -- Becky Yoose Systems Librarian Grinnell College Libraries On Wed, Dec 7, 2011 at 1:52 PM, Tania Fersenheim tan...@brandeis.eduwrote: Who do I talk to about the fact that I can't access the voting? Visit http://vote.code4lib.org/election/22 to check out the excellent -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu
Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
Thanks for clarifying that Becky. Users do need to set up an account to vote for the t-shirts and the presentations. There may be some lag time between new account sign up and access to voting so watch your email for account confirmation. Thanks again, Angie On 12/7/11 11:59 AM, Becky Yoose wrote: Hi Tania, If you haven't already, you can register for an account at http://code4lib.org/user/register. Once you have your account set up, you can then sign in to vote. Thanks, Becky -- Becky Yoose Systems Librarian Grinnell College Libraries On Wed, Dec 7, 2011 at 1:52 PM, Tania Fersenheimtan...@brandeis.eduwrote: Who do I talk to about the fact that I can't access the voting? Visit http://vote.code4lib.org/election/22 to check out the excellent -- Tania Fersenheim Manager of Library Systems Brandeis University Library and Technology Services 415 South Street, (MS 017/P.O. Box 549110) Waltham, MA 02454-9110 Phone: 781.736.4698 Fax: 781.736.4577 email: tan...@brandeis.edu
Re: [CODE4LIB] Vote Now: 2012 Conference T-shirt
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] 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
[CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)
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
Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)
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
Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)
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
Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)
On Wed, Dec 7, 2011 at 4:19 PM, Robert Sanderson azarot...@gmail.com wrote: * Separation of concerns... * Lax Security... * Obfuscation... Let's say I'm planning to first build a completely functional app with no javascript at al(*)l, and then use javascript for progressive enhancement. In other words, it's *essential* that I have server-side code that solves these problems already. Does it make sense to replicate the server-side functionality on the client? 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. -n
Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)
Nate, From what I hear, these are increasingly common questions. When the main stack is javascript, it just heightens the questions. With the resurgence of javascript being used server-side with tools like Node.js, client-side javascript MVC frameworks, and single-page applications, lots of different folks are coming to different conclusions about where it makes sense to do certain work. Some of these client-side frameworks may make it more attractive to do things client-side depending on your needs. I've also heard about frameworks which essentially let you run the same javascript code either server-side or client-side. So this is an interesting time for this question, since there is so much experimentation being done around it right now. I don't know if this helps at all. You recently have more options available than you had before for solving these kinds of problems. Jason On Wed, Dec 7, 2011 at 5:43 PM, Nate Vack njv...@wisc.edu wrote: On Wed, Dec 7, 2011 at 4:19 PM, Robert Sanderson azarot...@gmail.com wrote: * Separation of concerns... * Lax Security... * Obfuscation... Let's say I'm planning to first build a completely functional app with no javascript at al(*)l, and then use javascript for progressive enhancement. In other words, it's *essential* that I have server-side code that solves these problems already. Does it make sense to replicate the server-side functionality on the client? 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. -n
[CODE4LIB] Position announcement - Library Digital Infrastructure and Technology Coordinator
University of Denver - Penrose Library Position Available for Library Digital Infrastructure and Technology Coordinator The University of Denver's Penrose Library seeks an energetic, creative, and progressive professional for the position of Library Digital Infrastructure and Technology Coordinator. Responsibilities: Provides overall leadership and direction for the broad range of the library's technology infrastructure, which includes licensed software for library services and operations, development and management of the library's digital content infrastructure (including web-based finding tools, and repository and data curation services.) Coordinates projects related to the creation, management, and use of digital content (including a new digital media student help service), working closely with digital content stakeholders in the library and with staff and faculty across the university. Serves as an internal consultant on standards-based methods and best practices related to access to digital resources, web design, web-based applications, and the development of digital preservation strategies. Oversees the units delivering university-wide AV support for over 200 learning spaces, and internal/external events support. Coordinates strategic planning relating to the wide variety of technological and digital issues in which the library is, and may be, involved; assesssment and implementation of AV technology solutions in learning spaces on campus and online to enhance faculty teaching and student learning. This position reports to the Dean of the Library, directly supervises a digital projects assistant, and supervises and works closely and collaboratively with the Library Technology Manager, who in turn supervises all other library technology staff in the classroom, events, and library technology support units, and in the library web and software development unit. Qualifications required: ALA-accredited MLS degree or equivalent advanced academic qualification in information technology or information services. Proven knowledge of library operations software and systems, experience in developing and implementing web and database applications. Evidence of innovation in implementing emerging information technologies. Expertise with application of information technology in library operations and services. Demonstrated ability to plan, manage and oversee complex projects with diverse technological and equipment needs and to coordinate the library's technology units. Five years of ever increasing management responsibility. Proven ability to manage in a highly-collaborative environment of teamwork and cooperation. Strong interpersonal skills and ability to communicate clearly and knowledgeably, verbally and in writing. The capacity to listen closely to discussions from a variety of partners in order to put those conversations into a larger context for the organization to consider and act upon. Evidence of commitment to professional development and scholarly activities through research, publication, and service to national and regional professional organizations. Preferred: Experience in an academic library. Experience with Innovative Interfaces, Inc. integrated library system. Experience managing a digital content repository system. General information: The University of Denver (DU), the oldest independent university in the Rocky Mountain Region, enrolls approximately 9,500 students in its undergraduate, graduate and professional programs. The Carnegie Foundation classifies the University of Denver as a Doctoral/Research University-Extensive. The University is located in a residential neighborhood of Denver, a vibrant and diverse city offering an array of cultural attractions and recreational activities in the nearby mountains. For more information about Penrose Library and the University of Denver visit: http://www.du.eduhttp://www.du.edu/ Salary, Rank, Benefits: Competitive salary. Faculty status, non-tenure track appointment, with rank depending on experience and qualifications. Faculty hired at the rank of Assistant Professor are required to apply for promotion to Associate Professor in or before the sixth year. All promotions in rank and extensions of contract are based upon performance in three core areas of responsibility: primary job, scholarship/research, and service. Generous benefits package including TIAA-CREF; 22 vacation days a year. Deadline: Review of applications will begin January 9, 2012 and will continue until the position is filled. To Apply: Please visit http://www.dujobs.org for full posting and qualifications, and to submit application materials. The University of Denver is committed to enhancing the diversity of Faculty and Staff and encourages applications from minorities. Katherine Crowe Archives Processing Librarian University of Denver 2150 E. Evans Ave. Denver, CO 80208-5200 e-mail: katherine.cr...@du.edu
Re: [CODE4LIB] marc in json
On 12/1/2011 3:24 PM, Jonathan Rochkind wrote: 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. That's the same question - does it matter? - that I had reading this thread. If you have a ton of records to pack into a file, are the advantages of sending a json mime type over http and viewing it in a browser with jsonovich or whatever worth it when it's a really big file anyway? Seems that having 3-4 parsers that share the exact same idea of how to read/write individual records is the main story, and a great step forward. +1 to y'all for getting this done. -1 to me for never following through with my half-done pymarc implementation at c4lc '09 or whenever it was. -Dan
Re: [CODE4LIB] marc in json
The reason some of us want marc in JSON has absolutely nothing to do with sending json mime type over http and viewing it in a browser with jsonovich or whatever. (In fact, marc-in-json is possibly LESS human readable than marcxml, or at any rate no more so). It's to escape the limits and ease-of-corrupting of ISO Marc21 binary (maximum length, directory/headers that can easily become corrupt, unpredictable char encoding issues), but with a more compact (in bytes) and quicker/easier to parse representation than XML. But yes, it's awesome that we have parsers in several languages that will now read compatible marc-in-json formats. But sometimes you need to send more than one MARC record at once. (at once can be a file, or a network/inter-process stream) . More than one can range from 2 to dchud's a ton. So the next step is a common format for more than one of these things. It would be useful, yes. From: Daniel Chudnov [daniel.chud...@gmail.com] Sent: Wednesday, December 07, 2011 7:27 PM To: Code for Libraries Cc: Jonathan Rochkind Subject: Re: [CODE4LIB] marc in json On 12/1/2011 3:24 PM, Jonathan Rochkind wrote: 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. That's the same question - does it matter? - that I had reading this thread. If you have a ton of records to pack into a file, are the advantages of sending a json mime type over http and viewing it in a browser with jsonovich or whatever worth it when it's a really big file anyway? Seems that having 3-4 parsers that share the exact same idea of how to read/write individual records is the main story, and a great step forward. +1 to y'all for getting this done. -1 to me for never following through with my half-done pymarc implementation at c4lc '09 or whenever it was. -Dan
Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was: jQuery Ajax request to update a PHP variable)
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.
