 |
 |
Bill, You have hit the nail on the head!!!!! This is EXACTLY what I am trying to do! It's the underlying stuff that I am trying to get at. Looking at RDF may yield some good ideas. But I am not thinking in terms of RDF or XML, triples, or MARC, standards, or any of that stuff that gets thrown around here. Even the Internet is not terribly necessary. I am thinking in terms of data structures, pointers, sparse matrices, relationships between objects and yes, set theory too -- things like that. The former is pretty much cruft that lies upon the latter, and it mostly just gets in the way. Noise, as you put it, Bill! A big problem here is that Libraryland has a bad habit of getting itself lost in the details and going off on all kinds of tangents. As I said before, the biggest prison is between the ears!!!! Throw out all that junk in there and just start over! When I begin programming this thing my only tools will be a programming language (C or Java) a text editor (vi) and my head. But before I really start that, right now I am writing a paper that explains how this stuff works at a very low level. It's mostly an effort to get my thoughts down clearly, but I will share a draft of it with y'all on here soon. Peter Schlumpf -----Original Message----- >From: Bill Dueber <[log in to unmask]> >Sent: Apr 9, 2009 10:37 PM >To: [log in to unmask] >Subject: Re: [CODE4LIB] Something completely different > >On Thu, Apr 9, 2009 at 10:26 AM, Mike Taylor <[log in to unmask]> wrote: > >> I'm not sure what to make of this except to say that Yet Another XML >> Bibliographic Format is NOT the answer! >> > >I recognize that you're being flippant, and yet think there's an important >nugget in here. > >When you say it that way, it makes it sound as if folks are debating the >finer points of OAI-MARC vs MARC-XML -- that it's simply syntactic sugar >(although I'm certainly one to argue for the importance of syntactic sugar) >over the top of what we already have. > >What's actually being discussed, of course, is the underlying data model. >E-R pairs primarily analyzed by set theory, triples forming directed graphs, >whether or not links between data elements can themselves have attributes -- >these are all possible characteristics of the fundamental underpinning of a >data model to describe the data we're concerned with. > >The fact that they all have common XML representations is noise, and >referencing the currently-most-common xml schema for these things is just >convenient shorthand in a community that understands the exemplars. The fact >that many in the library community don't understand that syntax is not the >same as a data model is how we ended up with RDA. (Mike: I don't know your >stuff, but I seriously doubt you're among that group. I'm talkin' in >general, here.) > >Bibliographic data is astoundingly complex, and I believe wholeheartedly >that modeling it sufficiently is a very, very hard task. But no matter the >underlying model, we should still insist on starting with the basics that >computer science folks have been using for decades now: uids (and, these >days, guids) for the important attributes, separation of data and display, >definition of sufficient data types and reuse of those types whenever >possible, separation of identity and value, full normalization of data, zero >ambiguity in the relationship diagram as a fundamental tenet, and a rigorous >mathematical model to describe how it all fits together. > >This is hard stuff. But it's worth doing right. > > > > >-- >Bill Dueber >Library Systems Programmer >University of Michigan Library