 |
 |
I've worked to deprecate marc-hash (what tends to be referred to as "Bill Dueber's JSON format") in favor of Ross's marc-in-json. To the best of my knowledge, there is marc-in-json support for ruby (current ruby-marc), PHP (current File_MARC), marc4j (currently in trunk, soon to be released, I think), and perl (MARC::Record in the next release). I think that covers all the major players except the IndexData yaz- stuff. [Galen, any word on that next release of the perl module?] I, at least, already use marc-in-json in production (It's a great way to store MARC in solr). It would be great if folks would have the confidence to use it, at least as a single-record format. I think for wider adoption we'll need to all have either (a) json pull-parsers to read in a file that contains an array of marc-in-json objects, or (b) a decision to use newline-delimited-json (or some other record-delimiter), so folks can put more than one of these in a file and be able to get them out without running out of memory. -Bill- On Thu, Dec 1, 2011 at 9:11 AM, Ross Singer <[log in to unmask]> wrote: > Ed, I think this would be great. Obviously, there's zero > standardization around MARC/JSON (Andrew Houghton has come the > "closest" by writing up the most RFC-y proposal: > http://www.oclc.org/developer/content/marc-json-draft-2010-03-11). > > I generally fall more in the camp of "working code wins", though, > which, solely on the basis of MARC parser support, would put my > proposal in front. In the end, I don't think it matters which style > is adopted; it's an interchange format, any one of them works (and > they all, including Bill Dueber's) has their pluses and minuses. The > more important thing is that we pick -one- and go with it so we can > use it with some confidence. > > While we're on the subject, if there are any other serializations of > MARC that people are legitimately interested in (TurboMARC, for > example: > https://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records) > and wish ruby-marc supported, let me know. > > Thanks, > -Ross. > > On Thu, Dec 1, 2011 at 5:57 AM, Ed Summers <[log in to unmask]> wrote: > > Martin Czygan recently added JSON support to pymarc [1]. Before this > > gets rolled into a release I was wondering if it might make sense to > > bring the implementation in line with Ross Singer's proposed JSON > > serialization for MARC [2]. After quickly looking around it seems to > > be what got implemented in ruby-marc [3] and PHP's File_MARC [4]. It > > also looked like there was a MARC::Record branch [5] for doing > > something similar, but I'm not sure if that has been released yet. > > > > It seems like a no-brainer to bring it in line, but I thought I'd ask > > since I haven't been following the conversation closely. > > > > //Ed > > > > [1] > https://github.com/edsu/pymarc/commit/245ea6d7bceaec7215abe788d61a0b34a6cd849e > > [2] > http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/ > > [3] > https://github.com/ruby-marc/ruby-marc/blob/master/lib/marc/record.rb#L227 > > [4] > http://pear.php.net/package/File_MARC/docs/latest/File_MARC/File_MARC_Record.html#methodtoJSON > > [5] > http://marcpm.git.sourceforge.net/git/gitweb.cgi?p=marcpm/marcpm;a=shortlog;h=refs/heads/marc-json > -- Bill Dueber Library Systems Programmer University of Michigan Library