(Attention: lurker emerging)
To me what it comes down to is neither simplicity nor complexity, but
extensibility. In a perfect world, our data models should be capable of
representing very sophisticated and robust relationships at a high level
of granularity, while still accommodating ease of metadata production
and contribution (especially by non-experts and those outside the
library community).
I agree that none of our existing data structures/syntaxes are /a priori
/fundamental or infallible. But what is promising to me about RDF is its
intuitive mode of expression and extensibility (exactly the kind I
advocate above).
Casey
Han, Yan wrote:
Bill and Peter,
Very nice posts. XML, RDF, MARC and DC are all different ways to present information in a way (of course, XML, RDF, and DC are easier to read/processed by machine).
However, down the fundamentals, I think that it can go deeper, basically data
structure and algorithms making things works. RDF (with triples) is a directed
graph. Graph is a powerful (the most powerful?) data structure that you can
model everything. However, some of the graph theory/problems are NP-hard
problems. In fundamental we are talking about Math. So a balance needs to be
made. (between how complex the model is and how easy(or possible) to get it
implemented). As computing power grows, complex data modeling and data mining
are on the horizon.
Yan
-----Original Message-----
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Peter
Schlumpf
Sent: Thursday, April 09, 2009 10:09 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] You got it!!!!! Re: [CODE4LIB] Something completely
different
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 <b...@dueber.com>
Sent: Apr 9, 2009 10:37 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Something completely different
On Thu, Apr 9, 2009 at 10:26 AM, Mike Taylor <m...@indexdata.com> 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
--
Casey A. Mullin
Discovery Metadata Librarian
Metadata Development Unit
Stanford University Libraries
650-736-0849
cmul...@stanford.edu
http://www.caseymullin.com
