On 5/14/12 2:29 AM, Bernhard Eversberg wrote:
It raises two questions, although you may not be in a position to
answer the second:
1. Would you advocate a restructuring of RDA to the effect that it
conforms with the relational model, or seamlessly lend itself to
implementations under that concept? Or i.o.w., that RDA come with
a relational table database design ready for implementation? (For
otherwise, as practice has shown, different and incompatible designs
will evolve.)
No, I'm saying that JSC made a claim that RDA was developed on RDBMS
principles, and that scenario 1 is a mock-up of an RDBMS model of RDA,
albeit not in the level of detail that would actually be needed in a
database. I would like to see that principle or goal tested, preferably
using real data. Alternatively, someone could do an analysis of RDA in
RDF, again using data. I am uneasy that we have come this far without
such testing, and we know that putting RDA data in MARC is no test of
these possibilities.
It is possible to do a schematic mock-up of data without having a full
record format. You can draw boxes and say: "this goes here, and links to
this over here..." and database administrators do that all the time. Or
you can put some actual data into a test database. Then you see if you
can retrieve what you want to retrieve and display what you want to
display.
What happened with the MARC format is that when we moved it into actual
databases it turned out that certain things that people expected or
wanted didn't really work well. For example, many librarians expected
that you could replicate a card catalog display with records displaying
in order by the heading that was searched. That is really hard to do
(and not possible to do efficiently) using DBMS functionality, which is
based on retrieved sets not linear ordering, and especially using
keyword searching. I'm asking: are there expectations for catalogs using
RDA that will be problematic? As an example, I know that some people who
have played around with FRBR-structured data have found that there are
efficiency issues is formatting displays. I need to sit down and draw
some diagrams, but I'm wondering about retrieval using the FRBR WEMI
structure: How do you determine where to stop following links when
you've retrieved on, say, a keyword in an expression record? Does it
work for all cases? If not, how do you decide (algorithmically) which
case you have?
Maybe I just worry too much but my past experience is that there are
often huge "gotchas" when you move from thinking about data to actually
doing something with the data.
2. Is there "credible progress" by now in the efforts to create a
successor to MARC? (After all, LC had made that e condition for
implementation, and they did meanwhile decide for it to take
place in 2013. Or are they taking the good intention for the deed?)
And if yes, what kind of approach will it be? Relational tables?
I have no idea.
If your answer to question 1 is YES, wouldn't that amount to favoring
the relational technology over others, potentially or probably more
suitable ones? For there's that NoSQL movement gaining momentum right
now. But even disregarding that, AACR was, I think, always taking pains
to avoid getting involved with the fads and fashions of data
structures, even MARC itself was never mentioned. Now, RDA test data
have been published in nothing but MARC, only marginally embellished,
thereby foregoing the opportunity to unfold much of its potential.
Sticking as it does to a low-level scenario 3.
I don't think that you can really design "structureless" data, that is
data that is designed with no technology in mind. I think you can design
data that is as flexible as possible, but I don't see how you can design
data if you don't have some idea how you want to use it, and using it
means that it has to be realized in some form. Even RDA, which wanted to
be "format neutral" came up with scenario 1, which is a definite
structure. FRBR is a structure, and FRBR is inherent in RDA. So complete
"format neutrality" IMO is not possible, but oftentimes there is more
than one actual implementation format that data can fit comfortably into.
At this point, seeing a concrete example of any one format would be
better than none, at least in terms of easing my mind.
kc
B.Eversberg
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
