On Wed, Sep 24, 2008 at 1:06 PM, Tim Spalding <tim_at_librarything.com> wrote:
> Are there IT people who work in these industries? Certainly. But is
> there a class of newspaper coders? Publisher coders? Of course not. Do
> newspaper types bemoan the lack of reporters with programming skills?
Newspapers are hardly an industry to try to emulate at this point.
Maybe reporters with programming skills could help return them to
profitability.
> Of course not! Is the whole technical landscape at a publisher
> constrained by highly specialized, over-engineered solutions? No. They
> mostly use common IT tools.
>
For what function? I feel there is some comparison of apples to oranges here.
> In the rest of the modern information universe, this stuff just
> *works*. You buy and use industry-standard tools, separate the
> specialized task from the standard software and standards that
> implements it. Meanwhile:
>
> *Only libraries exchange information through Z39.50. Everyone else
> uses HTTP and, if they ever encounter it, wonder what the hell
> libraries are thinking.
Let's back up a minute here. Z39.50 predates the web. It predates
the standard use of HTTP to transport data. With Yazproxy there's
even a free and easy way to turn it into HTTP/XML. There's no reason
vendors can't do this, I figure it's that most libraries just don't
care that much about it.
> *Only libraries have their own private format for books, the many
> flavors of MARC. (ONIX is annoying, but at least it's XML!)
I'm not sure where to approach this one. To me, just being "XML"
isn't a particularly compelling argument. What does being XML afford
the data? I hate dealing with MARC, but I wouldn't say that it's any
worse than dealing with ONIX. Crappy data structures are crappy data
structures and the serialization is really second to that.
Not to mention the fact that there's plenty of ways to turn MARC into XML.
I guess I just don't buy this argument in the slightest.
> *Only libraries pay through the nose for special proprietary database
> systems (ILSes) they often can't even access programmatically.
>
Really, I'm only aware of one major ILS that has this sort of limitation.
How many HR departments really know how to code against their really
expensive PeopleSoft systems?
How many businesses have inventory control systems that they cannot
access programmatically (nor would care to if they could)?
My guess is a lot.
> I'm very much in favor of libraries doing IT internally, as long as
> they understand they're doing *IT*. So long as they think they're
> doing some special "Library IT," they'll keep falling behind—and being
> preyed on by the external vendors willing to facilitate and perpetuate
> the dysfunction.
I think this depends largely on the kind of IT that you're talking
about. Maintaining the staff and lab pcs is *IT*. System
administration is *IT*. But when you start developing software for a
particular industry, some domain knowledge, whether it's library,
banking, publishing or logistics is fairly important, at least for
somebody involved in the project.
-Ross.
Received on Wed Sep 24 2008 - 12:17:48 EDT