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 [[log in to unmask]]
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
