Re: [RDA-L] Bibframe

[Joseph, Angelina]

Thanks to everyone on clarifying what exactly BibFrame is. I printed out the 
link that Sally sent out. Mac, and all who responded to me on this, thank you.
--angelina joseph 

-Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Mitchell, Michael
Sent: Wednesday, May 29, 2013 7:53 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibframe

-Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg
Sent: Tuesday, May 28, 2013 11:38 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibframe

28.05.2013 23:45, J. McRee Elrod:
> Angelina Joseph asked:
>
>> Every now and then I see the word "Bibframe" in emails. Is it 
>> replacing MAR= C? How is that going to be?
>
> You will have answers from those more in the loop than I, but there is 
> my *very* biased answer.
>
> Bibframe is a work in progress, so no one knows if/when it will 
>replace MARC.
>...

LC's Sally McCallum on May 24 informed the VBIBFRAME community thus:

http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=43920



And this is but one example of the openness of the Bibframe development process 
of which I am very impressed. We catalogers do have a chance to monitor and 
influence the development of our future toolset. There are several first rate 
info sci people working on this but as Mac wrote there seems to be a lack of 
frontline cataloger input at this point (not absent, just a minority).

Michael Mitchell
Technical Services Librarian
Brazosport College
Lake Jackson, TX
Michael.mitchell at brazosport.edu

Re: [RDA-L] Bibframe

[Mitchell, Michael]

-Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg
Sent: Tuesday, May 28, 2013 11:38 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibframe

28.05.2013 23:45, J. McRee Elrod:
> Angelina Joseph asked:
>
>> Every now and then I see the word "Bibframe" in emails. Is it 
>> replacing MAR= C? How is that going to be?
>
> You will have answers from those more in the loop than I, but there is 
> my *very* biased answer.
>
> Bibframe is a work in progress, so no one knows if/when it will  
>replace MARC.
>...

LC's Sally McCallum on May 24 informed the VBIBFRAME community thus:

http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=43920



And this is but one example of the openness of the Bibframe development process 
of which I am very impressed. We catalogers do have a chance to monitor and 
influence the development of our future toolset. There are several first rate 
info sci people working on this but as Mac wrote there seems to be a lack of 
frontline cataloger input at this point (not absent, just a minority).

Michael Mitchell
Technical Services Librarian
Brazosport College
Lake Jackson, TX
Michael.mitchell at brazosport.edu

Re: [RDA-L] Bibframe

[Bernhard Eversberg]

28.05.2013 23:45, J. McRee Elrod:

Angelina Joseph asked:


Every now and then I see the word "Bibframe" in emails. Is it replacing MAR=
C? How is that going to be?


You will have answers from those more in the loop than I, but there is
my *very* biased answer.

Bibframe is a work in progress, so no one knows if/when it will
replace MARC.
...


LC's Sally McCallum on May 24 informed the VBIBFRAME community thus:

http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=43920

Re: [RDA-L] Bibframe

[J. McRee Elrod]

Angelina Joseph asked:

>Every now and then I see the word "Bibframe" in emails. Is it replacing MAR=
>C? How is that going to be?

You will have answers from those more in the loop than I, but there is
my *very* biased answer.

Bibframe is a work in progress, so no one knows if/when it will
replace MARC.

IMNSHO it is a *giant* step backward, in substituting English names
for language neutral MARC field tags (in the form ), all in
the name of being more consistent with Web data.  Seems to ma XML MARC
would fill that need.  There is also the matter of the ambiguity of
language, leading to wrong use of the element names.  (Remember the
now storied cataloguer who enter the donor in Dublin Core's
"contributor"?)

Bibframe has Works and Instances, as opposed to WEM, so will be little
if any better than MARC for RDA.   Expressions are treated as works.

There was talk of including relationship in authorities (read access
points), meaning an an authority for each role, and one assumes
multiple entries for the same person in the same Instance, e.g.,
director/actor, author/illustrator.  I think that one has been
squashed. or at least reduced.  (The access point in the data would
have a URI, pointing to the established form.)

There is talk of allowing only one ISBN per Instance, leading to
separate Instances for the same edition, e.g., different bindings,
simultaneous publication by more than one publisher. serials and sets
with an ISBN for each issue/volume, kits with multiple parts having
their own ISBN.  No headway seems to have been made on that one.

My impression is that those doing the work have not been on the front
line of cataloguing, and are not fully aware of the messy nature of
the bibliographic universe.

There is talk of URIs being shared. e.g., if one library establishes
an authority its URI could be used by other libraries Iwhat if the
first library drops the authority when withdrawing the relevant
work?).  The use of VIAF is also being talked about.  (My name there
had four forms I think before I complained.)

Bibframe proponents assume technical ability and resources many small
libraries will lack.  If implemented, there will be a divide between
have and have not libraries.


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

Re: [RDA-L] Bibframe

[Mitchell, Michael]

It may be awhile before it all comes to pass despite the decree that it should 
be in approximate sync with RDA. A recent question on the discussion list: 
"Will it be possible to use a BIBFRAME authority to link a BIBFRAME Work 
describing a FRBR Work to a BIBFRAME Work description of a FRBR Expression?" 
Maybe, but our students just want to find three sources for the report that's 
due tomorrow.

Michael Mitchell
Technical Services Librarian
Brazosport College
Lake Jackson, TX
Michael.mitchell at brazosport.edu





From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of JSC Chair
Sent: Tuesday, May 28, 2013 2:51 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibframe

BibFrame refers to the Library of Congress program, "Bibliographic Framework 
Initiative" that is indeed exploring a transition from the MARC format.  Please 
check their website for more information:  http://www.loc.gov/bibframe/  They 
also have a listserv you are welcome to join.
- Barbara Tillett, JSC Chair

On Tue, May 28, 2013 at 3:42 PM, Joseph, Angelina 
mailto:angelina.jos...@marquette.edu>> wrote:
Every now and then I see the word "Bibframe" in emails. Is it replacing MARC? 
How is that going to be?

-- angelina
Angelina Joseph
Cataloging Librarian
Ray & Kay Eckstein Law Library
Marquette University
Milwaukee, WI 53201
Ph: 414-288-5553
Fax: 414-288-5914
email: angelina.jos...@marquette.edu<mailto:angelina.jos...@marquette.edu>




--
Dr. Barbara B. Tillett, Ph.D.
Chair, Joint Steering Committee for Development of RDA

Re: [RDA-L] Bibframe

[Joseph, Angelina]

Thank you, Barbara.
--angelina joseph

From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of JSC Chair
Sent: Tuesday, May 28, 2013 2:51 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibframe

BibFrame refers to the Library of Congress program, "Bibliographic Framework 
Initiative" that is indeed exploring a transition from the MARC format.  Please 
check their website for more information:  http://www.loc.gov/bibframe/  They 
also have a listserv you are welcome to join.
- Barbara Tillett, JSC Chair

On Tue, May 28, 2013 at 3:42 PM, Joseph, Angelina 
mailto:angelina.jos...@marquette.edu>> wrote:
Every now and then I see the word "Bibframe" in emails. Is it replacing MARC? 
How is that going to be?

-- angelina
Angelina Joseph
Cataloging Librarian
Ray & Kay Eckstein Law Library
Marquette University
Milwaukee, WI 53201
Ph: 414-288-5553
Fax: 414-288-5914
email: angelina.jos...@marquette.edu<mailto:angelina.jos...@marquette.edu>




--
Dr. Barbara B. Tillett, Ph.D.
Chair, Joint Steering Committee for Development of RDA

Re: [RDA-L] Bibframe

[JSC Chair]

BibFrame refers to the Library of Congress program, "Bibliographic
Framework Initiative" that is indeed exploring a transition from the MARC
format.  Please check their website for more information:
http://www.loc.gov/bibframe/  They also have a listserv you are welcome to
join.

- Barbara Tillett, JSC Chair


On Tue, May 28, 2013 at 3:42 PM, Joseph, Angelina <
angelina.jos...@marquette.edu> wrote:

>  Every now and then I see the word “Bibframe” in emails. Is it replacing
> MARC? How is that going to be?
>
> ** **
>
> *-- angelina*
>
> Angelina Joseph
>
> Cataloging Librarian
> Ray & Kay Eckstein Law Library
>
> Marquette University
> Milwaukee, WI 53201
> Ph: 414-288-5553
> Fax: 414-288-5914
>
> email: angelina.jos...@marquette.edu
>
> ** **
>



-- 
Dr. Barbara B. Tillett, Ph.D.
Chair, Joint Steering Committee for Development of RDA

[RDA-L] Bibframe

[Joseph, Angelina]

Every now and then I see the word "Bibframe" in emails. Is it replacing MARC? 
How is that going to be?

-- angelina
Angelina Joseph
Cataloging Librarian
Ray & Kay Eckstein Law Library
Marquette University
Milwaukee, WI 53201
Ph: 414-288-5553
Fax: 414-288-5914
email: angelina.jos...@marquette.edu

Re: [RDA-L] [BIBFRAME] BIBFRAME relationship indicators & coding

[Gordon Dunsire]

Colleagues

With reference to the status of RDA relationship indicators (and other
vocabularies in the Open Metadata Registry):

The statuses "New-proposed" and "Published" should be interpreted as these
labels indicate: the former is for elements or concepts that are new and
merely proposed, implying that further change to definitions, etc. may
occur; the latter is for elements or concepts that have been published by
the vocabulary maintainers, implying that they are stable and safe to use.
OMR has recently added general definitions to the statuses to help with this
interpretation.

There is an email discussion thread (Life-cycle statuses for RDF
vocabularies) on these statuses and their interpretation on the listserv of
the DCMI Vocabulary Management Community [1] - further comments are still
very much welcome.

The current RDA vocabularies for relationships and roles in the OMR are
based on an early draft of RDA, and all are therefore in "New-proposed"
status. Changes to the underlying appendices on relationship designators in
the RDA Toolkit have, indeed, occurred since that early draft, and the OMR
versions are now out-of-synch. However, the recent meeting of the Joint
Steering Committee for Development of RDA in Chicago discussed a paper on
the RDF representation of the designators [2]. Note that this paper touches
on the interpretation of the designators as relationships (represented as
RDF properties) and as qualifiers to "headings" (represented as RDF/SKOS
concepts). Formal outcomes of the meeting, including this discussion, will
be published shortly; meantime, the blog of the American Library Association
representative to JSC gives a good indication [3].

JSC now expects to make good progress in moving the OMR designator
vocabularies to "Published" status, by carrying out some of the
recommendations in the discussion paper and updating the vocabularies to
synchronise them with the RDA Toolkit. Until this happens, the designator
labels and definitions in the current Toolkit are the master versions, and
it is unsafe to use the OMR versions.

Hope this helps!

Cheers

Gordon

[1]
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind1211&L=DC-VOCABULARY&X=169
2096BDAA8364E2E#3
[2] http://www.rda-jsc.org/docs/6JSC-CILIP-rep-2.pdf
[3]
http://www.personal.psu.edu/jxa16/blogs/resource_description_and_access_ala_
rep_notes/2012/11/report-of-the-meeting-of-the-joint-steering-committee-6-no
vember-2012.html

-Original Message-
From: Bibliographic Framework Transition Initiative Forum
[mailto:bibfr...@listserv.loc.gov] On Behalf Of Mark K. Ehlert
Sent: 30 November 2012 09:16
To: bibfr...@listserv.loc.gov
Subject: Re: [BIBFRAME] BIBFRAME relationship indicators & coding

J. McRee Elrod  wrote:
> Mark said:
>
>>There is no such designator in RDA.  It's "composer (expression)," 
>>which I believe you export to your clients as simply "composer".
>
> It is in the registry:
>
> http://metadataregistry.org/schemaprop/show/id/2209.html
 ...
> It is also in the version of RDA to which I have access at 18.5.1.3:
>
> "For Example:
>film producer
>film director
>actor
>composer of music for sound film"
>
 ...
> Perhaps you looked in the wrong list?

No, I looked in the correct list--the current version of RDA's Appendix I.
The "composer of music for sound film" designation appeared in the November
2008 draft of RDA, but it was wiped out with a number of other terms to form
the current Appendix I list first pushed out with the initial June 2010
publication of RDA.  The examples in Chapter 18 were revised too.

I see that term is still classed as "new-proposed" at the Metadata Registry.
Don't know if that means anything in this context.

> One list in alphabetic order
> would be much easier, perhaps coded for use with one or more of WEMI?

I've already made a single alphabetical list with WEMI labels, to use as a
cheat-sheet.

>>If the intent is to use URIs to describe relationships currently 
>>depicted by our current use of MARC relator codes ...
>
> The URIs lead to terms in English.  The $4 MARC codes can be exported 
> in any language.

The RDA relationship designators and other controlled terms are also
"codes."  They're given as English words in the text, but can be represented
using URIs that can point to multiple language labels for the same concept.
For instance, a number of the RDA terms at the Metadata Registry are
available in both English and German, e.g.,
.   Though
pointing at the same thing via a URI, an English catalog can be set up to
display the English label, and the German catalog set up to display the
German label.  Or perhaps even set up to prefer certain words over others in
a particular language.

To your point about id.loc.gov, maybe LC and/or another group can work to
develop sanctioned translation-synonyms for the MARC relator and other
codes.

> So much of RDA and Bibframe is Anglocentric.

Can't speak to the BIBFRA

Re: [RDA-L] BIBFRAME model document announced

[Bernhard Eversberg]

26.11.2012 17:08, James Weinheimer:


.. an interesting question: Has Dublin Core failed? While it
certainly can't be claimed a success, it has been folded into other
initiatives, e.g. OAI and RDFa. Yet it has not been taken up by many
 organizations.

Although having been the aim of the project: The hope was that all
webmasters equip their HTML files with DC metadata so as to aid the
search engines in finding more relevant stuff. Mind you, that was before
Google came along and quickly demonstrated to be able to find relevant
stuff with no metadata. ("relevant" being a metaphor meaning something
quite different from "relevant" as any uninitiated end-user would
expect, but that went and always goes down unobjected.) And then,
Google even eschewed metadata altogether because of misuse and
abuse by SEOs.
It is not impossible that the advent of Google was a fatal blow for the
meta movement. But another big factor was that DC was too abstract and
left too much room for interpretation. Instead, they should have
provided a comprehensive tool for metadata generation complete
with forms to fill and rules for filling the forms always ready
to be consulted and easy to follow. That some rules might be useful
was realized only much too late.

But of course, all of that may be beside the point when it comes
to BIBFRAME now...

B.Eversberg

Re: [RDA-L] BIBFRAME model document announced

[Brenndorfer, Thomas]

A good tutorial on RDF graphs can be found here: 
http://www.linkeddatatools.com/semantic-web-basics. One can see the same kind 
of entity, attribute and relationship structure as in FRBR, but here is is all 
structured by relationships in the form of statements (or triples), and 
arranged in graphs (which are a series of statements about how things relate to 
each other). What is new with RDF graph databases is their non-hierarchical 
nature.


Thomas Brenndorfer
Guelph Public Library

Re: [RDA-L] BIBFRAME model document announced

[Adger Williams]

Anyway, I really don't like this speculating around in this list
with no input from those who should know more and might easily resolve
errors in our wild guesses. Can this be called a discussion list? It is
rather another Speakers' Corner, inconsequential at the end of the day.
Not the first time though that I encounter this phenomenon.


How soon we get some input from Zephira ("those who should know more...")
will show us how much value they place on RDA.

In the absence of any response, a certain amount of discussion seems
entirely appropriate.


On Mon, Nov 26, 2012 at 7:25 AM, Bernhard Eversberg wrote:

> 26.11.2012 12:17, James Weinheimer:
>
>
>> Let's face it: the FRBR structure is bizarre and difficult even for
>> trained catalogers to grasp.
>>
> ... and to apply consistently end efficiently.
>
>
>
>> The FRBR user tasks are from an earlier time, and in any case, the
>> public hasn't been able to do them since keyword searching was
>> introduced--even in our library catalogs. That has been quite awhile
>> now and I have never seen or heard of anyone complaining. Those
>> original tasks have been long forgotten and have now been superceded
>> in a multitude of ways.
>>
> You are turning more and more radical. Honest analysis - once it
> were done - might well confirm you, however.
>
>
>  Besides, if somebody wants to navigate WEMI,
>> it can be done now with the right catalog software.
>>
>>  Once it were proved necessary. LT and GBS have both found some
> demand for it, and come up with their own solutions, not exactly along
> our lines of thinking and not exactly with much success (in the case of
> GBS at least).
>
>
>
>> The first steps in the new format should be to make it in the
>> simplest ways possible so that web creators can use our records as
>> soon as possible.
>>
> Wasn't that part of the motivation behind Dublin Core? I think it failed
> miserably because it did not create a format but left that to
> implementers. Foreseeably, each and every one of them came up with
> their own schemes and their own idiosyncratic syntaxes.
> The schema.org people are doing a somewhat better job in that they
> do not leave much to implementers. But then, their approach is very
> different from the idea of "records" as self-contained entities, and so
> it is difficult to see how to apply it in a library catalog context.
>
> Anyway, I really don't like this speculating around in this list
> with no input from those who should know more and might easily resolve
> errors in our wild guesses. Can this be called a discussion list? It is
> rather another Speakers' Corner, inconsequential at the end of the day.
> Not the first time though that I encounter this phenomenon.
>
> B.Eversberg
>



-- 
Adger Williams
Colgate University Library
315-228-7310
awilli...@colgate.edu

Re: [RDA-L] BIBFRAME model document announced

[Bernhard Eversberg]

26.11.2012 12:17, James Weinheimer:


Let's face it: the FRBR structure is bizarre and difficult even for
trained catalogers to grasp.

... and to apply consistently end efficiently.



The FRBR user tasks are from an earlier time, and in any case, the
public hasn't been able to do them since keyword searching was
introduced--even in our library catalogs. That has been quite awhile
now and I have never seen or heard of anyone complaining. Those
original tasks have been long forgotten and have now been superceded
in a multitude of ways.

You are turning more and more radical. Honest analysis - once it
were done - might well confirm you, however.


Besides, if somebody wants to navigate WEMI,
it can be done now with the right catalog software.


Once it were proved necessary. LT and GBS have both found some
demand for it, and come up with their own solutions, not exactly along
our lines of thinking and not exactly with much success (in the case of 
GBS at least).




The first steps in the new format should be to make it in the
simplest ways possible so that web creators can use our records as
soon as possible.

Wasn't that part of the motivation behind Dublin Core? I think it failed
miserably because it did not create a format but left that to
implementers. Foreseeably, each and every one of them came up with
their own schemes and their own idiosyncratic syntaxes.
The schema.org people are doing a somewhat better job in that they
do not leave much to implementers. But then, their approach is very
different from the idea of "records" as self-contained entities, and so
it is difficult to see how to apply it in a library catalog context.

Anyway, I really don't like this speculating around in this list
with no input from those who should know more and might easily resolve 
errors in our wild guesses. Can this be called a discussion list? It is

rather another Speakers' Corner, inconsequential at the end of the day.
Not the first time though that I encounter this phenomenon.

B.Eversberg

Re: [RDA-L] BIBFRAME model document announced

[James Weinheimer]

On 11/26/2012 09:53 AM, Bernhard Eversberg wrote:


A lot of speculation. We have to simply ask for the reasoning that
resulted in the draft as it is. Maybe - another speculation - they came
to the conclusion (after studying Jim Weinheimer's musings, for
instance) that WEMI is impracticable or not desirable or not worth the
time and effort.
Is there none of the insiders here to provide some background on all
this?



I would personally like the BIBFRAME suggestions much more if all 
references to FRBR were taken out. As Eric Miller mentioned in his talk 
at LC about the new bibliographic framework, 
http://www.loc.gov/today/cyberlc/feature_wdesc.php?rec=5605 (and the 
ensuing discussion on Autocat), the framework must be simple. If it is 
not simple, nobody will even think about using it. Very wise words.


Let's face it: the FRBR structure is bizarre and difficult even for 
trained catalogers to grasp. In addition, it is based on some unproven 
ideological concepts. Can we really expect non-librarian web creators to 
understand it so that they can implement it in some kind of coherent way?


While the new FRBR relationships may sound good at first, the reality is 
rather different. Introducing those relationships will seriously devalue 
the records in the catalog and degrade search results if we are not to 
undertake *massive* retrospective work. That is a simple fact 
(http://blog.jweinheimer.net/2012/09/cataloging-matters-no-16-catalogs.html). 
This is certainly not the underlying idea of linked data. The idea of 
linked data is to take the data that you *currently have*, share it 
openly in certain ways, and link information where it can be linked. 
Just by doing that, it is assumed that you have increased its value. We 
should find out if it is true. We don't have to devalue the millions of 
records we have now.


The FRBR user tasks are from an earlier time, and in any case, the 
public hasn't been able to do them since keyword searching was 
introduced--even in our library catalogs. That has been quite awhile now 
and I have never seen or heard of anyone complaining. Those original 
tasks have been long forgotten and have now been superceded in a 
multitude of ways. Besides, if somebody wants to navigate WEMI, it can 
be done now with the right catalog software.


For navigation and discovery, let advances in software deal with all of 
that, just as modern software can now extract all the headings and turn 
them into facets for further searching. What more will advances in 
software be able to do as full-text becomes increasingly available and 
library metadata can interact with it more and more? And as image 
searching (http://www.tineye.com) and sound searching 
(http://www.musipedia.org/) improve?


The new bibliographic format should be aimed at the *public*. They will 
be the consumers--not catalogers. We should not be trying to make 
ideological statements that others will not understand or care about, 
such as trying to teach WEMI or to convince them that people *really* 
want the FRBR user tasks. People want resources. Create records that are 
reliable, based on what we have now. If other projects harvest our 
metadata, assume that they will *not* retain our format, but will 
transform it into something else that serves their needs--just as 
libraries do with the formats they get.


The first steps in the new format should be to make it in the simplest 
ways possible so that web creators can use our records as soon as 
possible. The catalog world is starving for feedback! Once feedback 
starts coming in, the future should become clearer.


--
James Weinheimer weinheimer.ji...@gmail.com
First Thus http://catalogingmatters.blogspot.com/
Cooperative Cataloging Rules http://sites.google.com/site/opencatalogingrules/
Cataloging Matters Podcasts 
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] BIBFRAME model document announced

[Bernhard Eversberg]

Am 26.11.2012 09:43, schrieb Heidrun Wiesenmüller:


But I still find it very hard to accept that BIBFRAME in its first
draft (if I understand it correctly) doesn't seem to accommodate for
modeling a work in the abstract FRBR sense - at least not in the
bibliographic part of BIBFRAME. Perhaps it would be possible to model
a FRBR work in the "Authority" section of BIBFRAME, as obviously a
FRBR work can be a subject. I share Robert Maxwell's concern, though,
that BIBFRAME here seems to codify a certain form of technical
implementation, namely that of bibliographic vs. authority data. ...


A lot of speculation. We have to simply ask for the reasoning that
resulted in the draft as it is. Maybe - another speculation - they came
to the conclusion (after studying Jim Weinheimer's musings, for
instance) that WEMI is impracticable or not desirable or not worth the
time and effort.
Is there none of the insiders here to provide some background on all
this?

B.E.

Re: [RDA-L] BIBFRAME model document announced

[Heidrun Wiesenmüller]

Thomas Brenndorfer said:


In several early chapters in RDA there is only a thin blue line separating the movement 
from manifestation attributes to item attributes, and from work attributes to expression 
attributes. For an example of a boundary, see the blue separator "Other Identifying 
Attributes of Expressions" above RDA 6.9 (Content Type).

For RDA Ch. 4 (Providing Acquisitions and Access Information), the attributes 
can be applied to either manifestations or items. This can be seen more clearly 
in the RDA Element Set view (under the Tools tab), which has a hard FRBR 
breakdown of WEMIPFCBCOEP and all subordinate elements organized by attribute 
elements and then relationship elements.


True, works and expressions are treated very close together in RDA. And 
it's certainly also true that the boundaries between the WEMI entities 
are not always clear-cut, and there is sometimes room for discussion and 
different interpretations.


But I still find it very hard to accept that BIBFRAME in its first draft 
(if I understand it correctly) doesn't seem to accommodate for modeling 
a work in the abstract FRBR sense - at least not in the bibliographic 
part of BIBFRAME. Perhaps it would be possible to model a FRBR work in 
the "Authority" section of BIBFRAME, as obviously a FRBR work can be a 
subject. I share Robert Maxwell's concern, though, that BIBFRAME here 
seems to codify a certain form of technical implementation, namely that 
of bibliographic vs. authority data. A really modern data framework 
should, I believe, be more flexible than that.




The report provides a good rationalization for its own approach, which is at a 
sufficiently high abstract level to account for data organization by other 
communities:
"The goal of the Bibliographic Framework Initiative is to develop a model to 
which various content models can be mapped. This recognizes that different 
communities may have different views of their resources and thus different needs for 
resource descriptions. This is especially pronounced as one leaves the book/text 
media and considers images (still and moving), cartographic resources, archival 
collections, and ultimately cultural artifact and museum collections. Many content 
models define hierarchical relationships that need to be restated in RDF graph terms 
and then simplified to the BIBFRAME model.

For example, the origin of the Work/Instance aspects of the BIBFRAME can reflect the 
FRBR relationships in terms of a graph rather than as hierarchical relationships, 
after applying a reductionist technique to simplify things as much as possible. 
Formally reconciling the BIBFRAME modeling effort with an RDA-lite set of cataloging 
rules is a logical next step."

(pg. 15 - http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf)


Well, maybe it's just me, but I'm not really sure what they mean with 
"reflecting the FRBR relationships in terms of a graph (...) after 
applying a reductionist technique". Some more information would have 
been nice. It would also have been good if the BIBFRAME paper gave some 
insight in the motives for digressing from FRBR. Because, although I 
expressed some doubts in my last mail, in fact I am certain that they've 
read the FRBR report...


Also, I really don't like the word "RDA-lite" in this paragraph. 
BIBFRAME must also accommodate for "RDA-full".


Heidrun


--
-
Prof. Heidrun Wiesenmüller M.A.
Hochschule der Medien
Fakultät Information und Kommunikation
Wolframstr. 32, 70191 Stuttgart
Tel. dienstl.: 0711/25706-188
Tel. Home Office: 0711/36565868
Fax. 0711/25706-300
www.hdm-stuttgart.de/bi

Re: [RDA-L] BIBFRAME model document announced

[Adam L. Schiff]

One of the first things I noticed was the example that showed "Tunnel books" as 
a subject.  While this may reflect (incorrect) MARC 21 coding as 650, the resource/work 
being described is clearly not ABOUT tunnel books, it IS a tunnel book.  The correct MARC 
coding of course would be either 655 and/or 380.  Any new framework model needs to 
understand that genre/form is not the same as subject, and both need to be accommodated.

^^
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
Box 352900
Seattle, WA 98195-2900
(206) 543-8409
(206) 685-8782 fax
asch...@u.washington.edu
http://faculty.washington.edu/~aschiff
~~

Re: [RDA-L] BIBFRAME model document announced

[Bernhard Eversberg]

24.11.2012 11:37, Heidrun Wiesenmüller:


 ... BIBFRAME simply _must_ be able to
model RDA data in the necessary granularity and specificity.



That should indeed go without saying. And besides, it ought to be
integrated with RDA documentation as well, so as to enable linking
in both directions. When using the BIBFRAME documentation, as soon
as it will replace MARC, it must be possible to find pertinent rules
for any data element, and the other way. That means, BIBFRAME will
have to become integrated into the Toolkit. As well as with other
rules it will be employed to support. Data entry and editing have
long since been in need of enhancements in these regards. Now,
finally, the chances should be realized. And I mean, what chances does
RDA stand for optimal implementation if there is suboptimal support
at the input and editing stage. Or only unaffordable support!

And that raises another question:

Before engaging in heated debates about all sorts of big
issues as well as detail, we need to know who will eventually
be the owner of BIBFRAME and in what form and under what conditions
it will be made available: liberally like MARC, or under a global
monopoly licensing scheme like RDA.

B.Eversberg

Re: [RDA-L] BIBFRAME model document announced

[Brenndorfer, Thomas]

At one level I don't see the "work" and "instance" discussion in the paper of 
any greater significance than RDA's penchant for preferring a "content" vs 
"carrier" distinction in the organization of the earlier chapters in RDA.

In several early chapters in RDA there is only a thin blue line separating the 
movement from manifestation attributes to item attributes, and from work 
attributes to expression attributes. For an example of a boundary, see the blue 
separator "Other Identifying Attributes of Expressions" above RDA 6.9 (Content 
Type).

For RDA Ch. 4 (Providing Acquisitions and Access Information), the attributes 
can be applied to either manifestations or items. This can be seen more clearly 
in the RDA Element Set view (under the Tools tab), which has a hard FRBR 
breakdown of WEMIPFCBCOEP and all subordinate elements organized by attribute 
elements and then relationship elements.

The report provides a good rationalization for its own approach, which is at a 
sufficiently high abstract level to account for data organization by other 
communities:

>>>>>

"The goal of the Bibliographic Framework Initiative is to develop a model to 
which various content models can be mapped. This recognizes that different 
communities may have different views of their resources and thus different 
needs for resource descriptions. This is especially pronounced as one leaves 
the book/text media and considers images (still and moving), cartographic 
resources, archival collections, and ultimately cultural artifact and museum 
collections. Many content models define hierarchical relationships that need to 
be restated in RDF graph terms and then simplified to the BIBFRAME model.

For example, the origin of the Work/Instance aspects of the BIBFRAME can 
reflect the FRBR relationships in terms of a graph rather than as hierarchical 
relationships, after applying a reductionist technique to simplify things as 
much as possible. Formally reconciling the BIBFRAME modeling effort with an 
RDA-lite set of cataloging rules is a logical next step."

(pg. 15 - http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf)

>>>>>

Thomas Brenndorfer
Guelph Public Library





> -Original Message-
> From: Resource Description and Access / Resource Description and Access
> [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller
> Sent: November 24, 2012 5:37 AM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> Subject: Re: [RDA-L] BIBFRAME model document announced
> 
> This is indeed rather unsettling.
> 
> Funnily enough, they even take the FRBR report (1997 text, in the English
> version) as their example to show what BIBFRAME might look like (p. 16ff).
> But one wonders whether they've taken the trouble of actually reading it.
> The BIBFRAME entity "work", it seems, is a mixture of the FRBR "work" and
> the FRBR "expression".
> 
> This doesn't seem helpful. To me, one of the most important lessons to be
> learned from FRBR is the importance of the work (in the FRBR sense) as a
> starting point for user navigation. In BIBFRAME, there doesn't seem to be
> a common "node", to which the various expressions of the FRBR report (1997
> and 2007 text, translations in various languages) could be linked - they
> would all be separate BIBFRAME works. Perhaps they could at least be
> linked together horizontally ("Works can relate to other Works reflecting,
> for example, part / whole relationships", p. 8).
> 
> The BIBFRAME "instance" sounds like the FRBR "manifestation". FRBR "item"
> doesn't really seem to exist as an entity in its own right; it is
> supposedly covered by BIBFRAME "holdings", which is an example for
> "annotation", and therefore seen as something similar to cover art or a
> review.
> 
> It should also be noted that "Each BIBFRAME Instance is an instance of one
> and only one BIBFRAME Work." (p. 10), whereas in FRBR a manifestation may
> embody more than one expression.
> 
> The distinctions between "authority" and "annotation" also seem rather
> shady to me. Subjects are given as examples for "authority". Would that
> also include e.g. user tagging, or would this rather be "annotation"?
> 
> Granted, this is only a first draft, and it is explicitly stated that the
> model is not complete (p. 8.). I also readily accept that BIBFRAME should
> have a wider horizon than "just libraries". Among other things, this
> certainly means that it should be possible to have different levels of
> complexity (e.g. other parties might want a more "simple" way of
> representing data than we're u

Re: [RDA-L] BIBFRAME model document announced

[Heidrun Wiesenmüller]

This is indeed rather unsettling.

Funnily enough, they even take the FRBR report (1997 text, in the 
English version) as their example to show what BIBFRAME might look like 
(p. 16ff). But one wonders whether they've taken the trouble of actually 
reading it. The BIBFRAME entity "work", it seems, is a mixture of the 
FRBR "work" and the FRBR "expression".


This doesn't seem helpful. To me, one of the most important lessons to 
be learned from FRBR is the importance of the work (in the FRBR sense) 
as a starting point for user navigation. In BIBFRAME, there doesn't seem 
to be a common "node", to which the various expressions of the FRBR 
report (1997 and 2007 text, translations in various languages) could be 
linked - they would all be separate BIBFRAME works. Perhaps they could 
at least be linked together horizontally ("Works can relate to other 
Works reflecting, for example, part / whole relationships", p. 8).


The BIBFRAME "instance" sounds like the FRBR "manifestation". FRBR 
"item" doesn't really seem to exist as an entity in its own right; it is 
supposedly covered by BIBFRAME "holdings", which is an example for 
"annotation", and therefore seen as something similar to cover art or a 
review.


It should also be noted that "Each BIBFRAME Instance is an instance of 
one and only one BIBFRAME Work." (p. 10), whereas in FRBR a 
manifestation may embody more than one expression.


The distinctions between "authority" and "annotation" also seem rather 
shady to me. Subjects are given as examples for "authority". Would that 
also include e.g. user tagging, or would this rather be "annotation"?


Granted, this is only a first draft, and it is explicitly stated that 
the model is not complete (p. 8.). I also readily accept that BIBFRAME 
should have a wider horizon than "just libraries". Among other things, 
this certainly means that it should be possible to have different levels 
of complexity (e.g. other parties might want a more "simple" way of 
representing data than we're used to) withoug becoming incompatible. But 
still, BIBFRAME simply _must_ be able to model RDA data in the necessary 
granularity and specificity.


Heidrun



Am 24.11.2012 00:34, schrieb Robert Maxwell:

I haven't had a chance to look closely at the document yet, but it does disturb me that "a 
team from Zephira" appears to have, having thought about it for a few months, swept away 
nearly two decades of consideration by the best minds in the cataloging profession by apparently 
abandoning the FRBR model, as Mac points out below. I realize not everyone agrees with the FRBR 
model but I should think such a step should not happen simply because of a report from a consulting 
group. Sally McCallum said in her announcement that "like MARC, [the model] must be able to 
accommodate any number of content models", which is certainly true, but one would think that 
at least one of those content models might be RDA, which was the entire impetus for hiring Zephira 
to come up with a new model for us. Since RDA is firmly based on FRBR and DOES include provisions 
for describing and linking to expressions, it does seem inappropriate that the new model should not 
provide for this entity. I have a hard time seeing how this model would be any better a fit for RDA 
than the current MARC model.

Further, report's apparent continuation of a model that continues the division of the database into 
"authority" and "instance" (which I gather is more or less the equivalent of 
bibliographic records, see p. 10 of the report) seems extremely backward to me. In an ER linked 
data database we would have descriptions of the entities linked by relationship links.

Bob

Robert L. Maxwell
Special Collections and Ancient Languages Catalog Librarian
Genre/Form Authorities Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568

"We should set an example for all the world, rather than confine ourselves to the 
course which has been heretofore pursued"--Eliza R. Snow, 1842.

-----Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod
Sent: Friday, November 23, 2012 3:41 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] BIBFRAME model document announced

Posted to Bibframe:



http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf


  Creative Work - a resource reflecting a conceptual essence of the
cataloging item.


  Instance - a resource reflecting an individual, material embodiment
of the Work.


  Authority - a resource reflecting key authority concepts that have
defined relationships reflected in the Work and Instance. Examples of
Authority Reso

Re: [RDA-L] BIBFRAME model document announced

[Robert Maxwell]

I haven't had a chance to look closely at the document yet, but it does disturb 
me that "a team from Zephira" appears to have, having thought about it for a 
few months, swept away nearly two decades of consideration by the best minds in 
the cataloging profession by apparently abandoning the FRBR model, as Mac 
points out below. I realize not everyone agrees with the FRBR model but I 
should think such a step should not happen simply because of a report from a 
consulting group. Sally McCallum said in her announcement that "like MARC, [the 
model] must be able to accommodate any number of content models", which is 
certainly true, but one would think that at least one of those content models 
might be RDA, which was the entire impetus for hiring Zephira to come up with a 
new model for us. Since RDA is firmly based on FRBR and DOES include provisions 
for describing and linking to expressions, it does seem inappropriate that the 
new model should not provide for this entity. I have a hard time seeing how 
this model would be any better a fit for RDA than the current MARC model.

Further, report's apparent continuation of a model that continues the division 
of the database into "authority" and "instance" (which I gather is more or less 
the equivalent of bibliographic records, see p. 10 of the report) seems 
extremely backward to me. In an ER linked data database we would have 
descriptions of the entities linked by relationship links.

Bob

Robert L. Maxwell
Special Collections and Ancient Languages Catalog Librarian
Genre/Form Authorities Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568 

"We should set an example for all the world, rather than confine ourselves to 
the course which has been heretofore pursued"--Eliza R. Snow, 1842.

-Original Message-
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod
Sent: Friday, November 23, 2012 3:41 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] BIBFRAME model document announced

Posted to Bibframe:


>http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf


 Creative Work - a resource reflecting a conceptual essence of the 
cataloging item.


 Instance - a resource reflecting an individual, material embodiment 
of the Work.


 Authority - a resource reflecting key authority concepts that have 
defined relationships reflected in the Work and Instance. Examples of 
Authority Resources include People, Places, Topics, Organizations, etc.


 Annotation - a resource that decorates other BIBFRAME resources with 
additional information. Examples of such annotations include Library 
Holdings information, cover art and reviews.

Are we to gather that RDA's "Work" is still a work, but that "Instance"
replaces Manifestation, Expression is no more, and Item data is a part
of annotation?  Will WIAA or CIAA be our new acronym, replacing WEMI?


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

Re: [RDA-L] BIBFRAME model document announced

[J. McRee Elrod]

Posted to Bibframe:


>http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf

 Creative Work - a resource reflecting a conceptual essence of the 
cataloging item.

 Instance - a resource reflecting an individual, material embodiment 
of the Work.

 Authority - a resource reflecting key authority concepts that have 
defined relationships reflected in the Work and Instance. Examples of 
Authority Resources include People, Places, Topics, Organizations, etc.

 Annotation - a resource that decorates other BIBFRAME resources with 
additional information. Examples of such annotations include Library 
Holdings information, cover art and reviews.

Are we to gather that RDA's "Work" is still a work, but that "Instance"
replaces Manifestation, Expression is no more, and Item data is a part
of annotation?  Will WIAA or CIAA be our new acronym, replacing WEMI?


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

[RDA-L] Bibframe document available

[Karen Coyle]

A document dated Nov. 21, 2012 on the Bibliographic Framework as a Web 
of Data is available from this web page:


http://loc.gov/marc/transition/news/bibframe-112312.html

I learned about this from a re-tweet, which seems to have originated 
with a colleague in the UK. If I missed the announcement on these lists 
and am repeating what you already know, I apologize.


kc

--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [RDA-L] [BIBFRAME] [RDA-L] Are RDA, MARC data, and Bibliographic concepts compatible with Relational database principles or systems? (Was: Re: [RDA-L] RDA, DBMS and RDF)

[Bernhard Eversberg]

19.05.2012 03:28, Simon Spero:


In the examples I gave I actually presented four different models,
representing different ways of using a relational model.


In all of your models, which do make things a lot clearer for those
not familiar wit RDB concepts, you say nothing about subfields. Isn't it
a problem with relational tables that the column values are supposed
to be atomic, i.e. consisting of one strictly typed value? What are we
to do with subfields then if a table column must be free of internal
structure? (SQL, to my knowledge, cannot handle element substructures.)

Subelements cannot be just abandoned, I believe, because we need
repeateble data elements, each with its very own set of subelements -
another issue for the RDB model. And how well does this fit in with the
RDF triple concept?

And there's another thing:
In a relational table, the sequence of columns has no semantic 
significance, so you might shift a column freely around. This is not

quite the case with MARC fields, and certainly not with subfields.

Any new data model would have to consider these issues and weigh these
MARC features well before dismissing them.

B.Eversberg

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[J. McRee Elrod]

>On 15/05/2012 17:53, Jonathan Rochkind wrote:

> Frankly, I no longer have much confidence that the library cataloging
> community is capable of any necessary changes in any kind of timeline
> fast enough to save us.

There is no question that change is needed.  The question is, are RDA
records coded in MARC21 the needed change?


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[James Weinheimer]

On 15/05/2012 17:53, Jonathan Rochkind wrote:

> Frankly, I no longer have much confidence that the library cataloging
> community is capable of any necessary changes in any kind of timeline
> fast enough to save us.
>
> Those that believe no significant changes to library cataloging or
> metadata practices are neccesary will have a chance to see if they are
> right.
>
> I believe that inaction -- in ability to make significant changes in
> "the way our data is currently recorded and maintained" to accomodate
> contemporary needs -- will instead result in the end of the library
> cataloging/metadata tradition, and the end of library involvement in
> metadata control, if not the end of libraries.  I find it deeply
> depressing. But I no longer find much hope that any other outcome is
> possible, and begin to think any time I spend trying to help arrive at
> change is just wasted time.


I think many share your fears. I certainly do, but it is important not
to give up hope. The problem as I see it is that while everyone agrees
that we should move "forward", we don't even know which direction
"forward" is. Some believe it is east, others west, others north, others
up, others down. Nobody knows. Is the basic problem in libraries "the
way our data is currently recorded and maintained"? For those who
believe this, then it would mean that if libraries changed their format
and cataloging practices, things would be better.

But this will be expensive and disruptive. That is a simple fact. And
undertaking something like that during such severe economic times makes
it even more difficult. So, it seems entirely logical that people ask
whether this *really will* help or whether those resources would be
better used to do something else. In fact, this is such a natural
question, not asking it makes people raise their eyebrows and wonder if
there really is an answer. This is why I keep raising the point of the
business case. It is a fundamental, basic task.

And another fact is, if we want to make our records more widely
available in types of formats that others could use, it can be done
right now. Harvard is doing it with their API:
http://blogs.law.harvard.edu/dplatechdev/2012/04/24/going-live-with-harvards-catalog/
They say their records are now available in JSON using schema.org, in DC
or in MARC, although all I have seen is MARC so far. Still, Kudos to
them! It is a wonderful beginning!

So it is a fact that the library community does not have to wait for
RDA, FRBR or even the changes to MARC to repurpose their data. Would it
be perfect? Of course not! When has that ever had anything to do with
anything? Everyone expects things to change constantly, especially
today. A few years of open development using tools such as this would
make the way "forward" much clearer than it is now. Then we could start
to see what the public wants and needs and begin to design for *them*
instead of for *us*. If we find that there is absolutely no interest in
open development of library tools, that would say a lot too.

To maintain that RDA and FRBR are going to make any difference to the
public, or that they are necessary to get into the barely-nascent and
highly controversial "Linked Data", is simply too much to simply accept.
Each represents changes, that's for sure, but theoretical ones that
happen almost entirely behind the scenes, and all whose value has yet to
be proven. All this in spite of the incredible developments going on
right under our noses! Therefore, it seems only natural to question
whether RDA, FRBR and "Linked Data" truly represent the direction
"forward" or are they actually going in some other direction.

On a more positive note, I think there are incredible opportunities for
libraries and librarians today.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Jonathan Rochkind]

On 5/15/2012 11:34 AM, James Weinheimer wrote:

Although MARC needs to change, and has needed it for a very long time, I
don't see how changing the format would improve the subject headings.


I did not mean to say that changing from MARC to somethign else, by 
itself, would do anything at all to subject headings.


I chose my phrase carefully, "the way our data is currently recorded and 
maintained in MARC".  Several things about the way our data is currently 
and recorded and maintained (which we currently do in MARC) ought to be 
changed. Subject headings aren't even one of the main ones, although the 
way they are done could certainly be improved to be more powerful in 
software environments.


It is a large and complicated topic. One we've spent collectively years 
arguing about on this list.


Frankly, I no longer have much confidence that the library cataloging 
community is capable of any necessary changes in any kind of timeline 
fast enough to save us.


Those that believe no significant changes to library cataloging or 
metadata practices are neccesary will have a chance to see if they are 
right.


I believe that inaction -- in ability to make significant changes in 
"the way our data is currently recorded and maintained" to accomodate 
contemporary needs -- will instead result in the end of the library 
cataloging/metadata tradition, and the end of library involvement in 
metadata control, if not the end of libraries.  I find it deeply 
depressing. But I no longer find much hope that any other outcome is 
possible, and begin to think any time I spend trying to help arrive at 
change is just wasted time.


Jonathan

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[James Weinheimer]

On 15/05/2012 16:50, Jonathan Rochkind wrote:

> I certainly agree that the way our data is currently recorded and
> maintained in MARC is not suitable for contemporary desired uses, as
> I've suggested many times before on this list and others and tried to
> explain why; it's got little to do with rdbms though.


Although MARC needs to change, and has needed it for a very long time, I
don't see how changing the format would improve the subject headings.
The semantics are there already, so searching would remain the same. It
is the display of the multiple search result which has disintegrated. I
think there are lots of ways that the displays could be improved for the
public--primarily by making them more flexible and could be experimented
with now--but even then, there will need to be a major push from public
services to get the public to use and understand what the subject
searches are. All of it has been effectively forgotten by the public.

For a whole lot of reasons, library subject searches will always be
substantively different from what what people retrieve from a full-text
search result and while librarians can understand this, it is a lot
harder for the public.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Jonathan Rochkind]

On 5/14/2012 8:52 PM, Karen Coyle wrote:


No, that is not what I meant. Of course you can retrieve records in a
given order, and we do all the time. It's about using the headings in
the MARC records to establish that order. So here's the question I put
to Mac:


Sure you can use the headings in the MARC records to establish record 
retrieval order in an rdbms.  All of our ILS/OPACs that return MARC 
records in headings order and are based on rdbms DO it.


If the literal headings aren't structured right so that the rdbms' 
"natural order" will be right, the standard software solution is to 
automatically construct a 'sort key' from the headings. This is a pretty 
standard solution used all the time in many scenarios, it's not a 
significant burden or problem.


I am a bit mystified by your arguments here about what rdbms can or 
can't do, and am not sure what you are trying to do with them.  They 
don't match what software engineers using rdbms actually do.  Also, you 
keep saying "dbms" ("database management system"), when I think you mean 
to be specifically talking about rdbms (RELATIONAL dbms); dbms is a more 
general term that can apply to just about anything that stores data 
persistently, but your arguments (which I don't agree with) seem to 
specifically be about databases that use SQL and are based on relational 
algebra -- that's rdbms specifically, not 'dbms'.


I certainly agree that the way our data is currently recorded and 
maintained in MARC is not suitable for contemporary desired uses, as 
I've suggested many times before on this list and others and tried to 
explain why; it's got little to do with rdbms though.


Jonathan

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Brenndorfer, Thomas]

From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle

Sent: May 14, 2012 8:53 PM

To: RDA-L@LISTSERV.LAC-BAC.GC.CA

Subject: Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] 
[BIBFRAME] RDA, DBMS and RDF



>All that to say that if we are not going to display our records in 
>alphabetical order by their headings, then I'm >not sure if creating headings 
>during cataloging makes all that much sense. Or at least, not the kinds of 
>headings >that we do create, which are designed to be viewed in alphabetical 
>order. You are supposed to see "Hamlet" before >you see



>Hamlet. French.

>Hamlet. German.

>Hamlet. German. 1919



>Maybe you don't see "Hamlet" first, but the logic of adding on to the right 
>hand side of the heading implies that >the order conveys something to the user 
>that facilitates finding what he is looking for.



>Thus, I question to creation of headings that are designed to be encountered 
>in alphabetical order unless we adopt >an ordered display around those 
>headings. And if we think it is important to adopt such a display, we need to 
>>understand the implications for system design.





There are numerous effects of the alphabetical browse display of headings in 
online systems that force catalogers and systems designers to make all sorts of 
unexpected decisions and difficult choices and workarounds. And even at that, 
the conventions that bring us those headings are often found out of context. 
For example, some of those headings with "extra bits" at the end exist to 
differentiate entities, and otherwise appear arbitrary without much relation to 
the headings around them which omit the extra bits.



End-users have their complaints browsing a catalog index. They complain when 
they expect to find different records attached to each unique heading, but 
instead find that the record happened to have several headings that all began 
with the same words.



Multiple indexes in online catalogs fracture and distort the intended effect of 
browsing headings. For the four ILS's I've worked with and customized I've had 
to make choices about MARC index mapping that would mitigate these issues:



1.  Author Browse may or may not contain name-title headings for works and 
expressions. These headings could be pulled from related or analytical or 
series added entries. Should subject name-title headings be included? What 
about title SEE references to these headings? One system I used actually 
reconstructed the 1XX+240 heading on-the-fly. And what about persons and 
corporate bodies as subjects? Shouldn't the user benefit from seeing all 
related works together?

This is why FRBR is so important. So much of the indexing is built around a 
cacophony of different implicit relationships, with little that is explicit to 
the end-users in terms of building expectations of what should be found with 
what. Being clear about the relationships matter, because that information 
needs to survive as catalogs records and indexes are torn apart and rebuilt in 
any number of different ways - we can't assume the implicit logic that exists 
when all card catalog and heading data are found together in context.


2.  Title Browse often doesn't include authority information such as SEE and 
SEE ALSO references, so much of the information available in authority records 
is effectively lost. Should Title Browse draw in all titles, such as series 
titles or subject titles? I always mapped these together because I felt it 
wrong for an end-user to decide upon a title AND a relationship when searching 
(i.e., the end-user knows the title, but may not know it's a series title - why 
expect the end-user to be forced to choose between Title Browse and Series 
Browse?)


3.  Subject Browse - similar to the issue above about end-users being forced to 
choose indexes, an end-user needs to differentiate William Shakespeare as 
author from William Shakespeare as subject ahead of time to find all the 
records attached to that name. The records are not found together with a single 
search in many cases. In an early system I had with minimal authority control, 
there were actually two system generated authority records for William 
Shakespeare - one as an author and one as a subject. There is a benefit to 
maintenance when one record per entity is updated, but the end-user may not 
encounter all the benefits because of the bewildering choices of indexes and 
the truncated and chopped up displays of bibliographic and authority data in 
online catalogs.



Once web-based catalogs appeared, there were choices that could be made as well 
when a heading is clicked.



In the case of a related name-title work heading, I had three choices in one 
system:



A.  Click the heading and bring up 

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[James Weinheimer]

On 15/05/2012 02:52, Karen Coyle wrote:

> let's say you have a record with 3 subject headings:
>
> Working class -- France
> Working class -- Dwellings -- France
> Housing -- France
>
> In a card catalog, these would result in 3 separate cards and
> therefore should you look all through the subject card catalog you
> would see the book in question 3 times.
>
> In a keyword search limited to subject headings, most systems would
> retrieve this record once and display it once. That has to do with how
> the DBMS resolves from indexes to records. So even though a keyword
> may appear more than once in a record, the record is only retrieved once. 


I don't believe that is correct. That kind of search result should be a
programming decision: whether to dedupe or not. It seems to me that a
record with "France" three times in the record could easily display
three times in a search result if you want it to. With relevance
ranking, or ranking by date, etc. it makes little sense to display the
same record three different times, although I am sure you could. Having
a record display more often makes sense only with some kind of browse
heading display but I have never seen that with a keyword result.

This is a great example of how our current subject heading strings just
don't function today, and they haven't ever since keyword was
introduced. Computerized records work much better with descriptors than
with traditional headings, for instance, your example would be something
like:
Topical Subjects: Working class, Dwellings, Housing
Geographic Subject Area: France.

Here, there is no question since "France" appears only once in the
subjects.

Seen in this light, our subject headings are obsolete but nevertheless,
I believe our subject headings with subdivisions provides important
options found nowhere else, as I tried to show in the posting I
mentioned in my previous message. But really, how the subject headings
function must be reconsidered from their foundations, otherwise they
really are obsolete.

The dictionary catalog really is dead, at least as concerns the public.

-- 
*James Weinheimer* weinheimer.ji...@gmail.com
*First Thus* http://catalogingmatters.blogspot.com/
*Cooperative Cataloging Rules*
http://sites.google.com/site/opencatalogingrules/
*Cataloging Matters Podcasts*
http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Karen Coyle]

Note to the majority of readers on RDA-L: you should feel no guilt in 
skipping the rest of this thread. It has veered off into a technical 
discussion that you may simply have no time (or use) for - kc


On 5/14/12 12:50 PM, Simon Spero wrote:


On Mon, May 14, 2012 at 10:45 AM, Karen Coyle mailto:li...@kcoyle.net>> wrote:
 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 *[a]* /replicate a card catalog
display/ with *[b]* /records/ /displaying in order by the/
/heading that was searched/. That is really hard to do (*[c]* /and
not possible to do efficiently/) using*[d]* /DBMS/ functionality,
which is based on *[e]* /retrieved sets/ not /linear ordering/,
and*[f] */especially using keyword searching/.  [emphasis and
labels  added]


BLUF: Not all DBMS  are Relational;  it is possible to efficiently 
retrieve records in order from many different types of DBMS, including 
Relational databases.


[c] and [d] make the claim that it is impossible to retrieve records 
efficiently in some desired order using DBMS functionality.  This is 
justified by [e] which claims that the source of this necessary 
inefficiency is that DBMS functionality is based on "retrieved sets" 
not "linear ordering".


No, that is not what I meant. Of course you can retrieve records in a 
given order, and we do all the time. It's about using the headings in 
the MARC records to establish that order. So here's the question I put 
to Mac:


***

let's say you have a record with 3 subject headings:

Working class -- France
Working class -- Dwellings -- France
Housing -- France

In a card catalog, these would result in 3 separate cards and therefore 
should you look all through the subject card catalog you would see the 
book in question 3 times.


In a keyword search limited to subject headings, most systems would 
retrieve this record once and display it once. That has to do with how 
the DBMS resolves from indexes to records. So even though a keyword may 
appear more than once in a record, the record is only retrieved once.


In your catalog, which displays the subject headings on a line with the 
author and title

1) will each of these subject headings appear in the display?
2) does that mean that the bibliographic record (represented by the 
author and title) will display 3 times in the list of retrievals?


***

I could add to that: if the record had four subject headings:

Working class -- France
Working class -- Dwellings -- France
Housing -- France
Housing -- Europe

Then under what circumstances in your system design would the user see 
all four subject entries (heading plus bib data) in a single display?


That's part of the question. The card catalog had a separate physical 
entry for each "entry point" or heading associated with the 
bibliographic description. Do we have a reasonably efficient way to 
imitate this behavior using keyword (or keyword in heading, or 
left-anchored string searching) in an online library catalog? (followed 
by: is there any reason to do that?)


But I think another part is the difference between retrieval, in the 
database sense of the term ("give me all of the records with the word 
*france* in a subject heading") vs. the kind of alphabetical linear 
access that the card catalog provided, which allows you to begin at:


France -- United States -- Commerce

and soon arrive at

Frances E. Willard Union (Yakima, Wash.)

I don't think you can get from one to the other in most online catalogs 
because the set of records that you can see is determined by the search 
that retrieves only those records with *france* in it.


I've designed a browse in DBMSs using a left-anchored search that 
retrieves one heading (the first one hit) in a heading index followed by 
a long series of "get next" commands. Naturally, "next" has to also be 
next in alphabetical order, so the index you are traversing has to be in 
alphabetical order. I should say: alphabetical order that is retained 
even as records are added, modified or deleted. I think this may be more 
feasible in some DBMSs than others.


However, what is obviously missing here is a display of the bib record 
that goes with the heading (all of that "ISBD" stuff). It's possible 
that DBMS's can do this fine today, but in my olden days when I 
suggested to the DBA that we'd need to "get next," display that heading, 
then retrieve and display the bibliographic record that went with it, 20 
times in order to create a page of display, I practically had to revive 
the DBA with a bucket of cold water.


Mac's system also cannot take the display from France--US--etc to 
Frances E. Willard because the headings it has to work with have been 
retrieved on a keyword search, thus only headings with the term *france* 
in them are displayed. It also does displ

Re: [RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Myers, John F.]

I think the question is referring back to filing rules of the card catalog.  
I'm not certain how closely they met the conditions of the "strong reading" 
because I'm not entirely certain of the original query myself.

>From the 1956 LC filing rules, p. 140 has the following statements regarding 
>the interaction of subject entries with other entries:

I. The proper order of entries when the names of a person, place and thing are 
identical is: A. Person; B. Place; C. Subject [other than a specific subject 
that is arranged after its own author and added entries]; D. Title.

Example:
Stone, Samuel  [author]
Stone, Thomas [author]
Stone, Pa.   [name of place]
STONE  [name of an object]
Stone[a title beginning with the word]

II. Any author entry may have its own subject entry.  When this is the case, 
the subject entry follows directly after its own author and added entries.  
[Clarifying text elided]

Example (some entries elided):
Stone, Thomas [author]
Stone, Thomas [added entry]
STONE, THOMAS  [subject]
Stone, Pa.   [place as author]
Stone, Pa.   [place as added entry]
Stone, Pa. Dept. of Ed.  [subordinate body as author]
Stone, Pa. Dept. of Ed.  [subordinate body as added entry]
STONE, PA. DEPT. OF ED.  [subordinate body as subject]
STONE, PA. [place as subject]
STONE, PA. - BIOG.[place with subdivision as subject]


III. [A sequence dealing strictly with subjects and their various subdivisions, 
qualifications, and inverted formulations - clustering by group but not 
yielding a strict alphabetic sequence: ART - HISTORY precedes ART - 17th 
CENTURY precedes ART - ALBANIA.]

John F. Myers, Catalog Librarian
Schaffer Library, Union College
807 Union St.
Schenectady NY 12308

518-388-6623
mye...@union.edu

Karen Coyle wrote:

I don't get this at all. Maybe an example would help?

Quoting Simon Spero:
[snip]
In a  strong reading could imply that when searching a physical card catalog by 
a heading of a specific kind (e.g. subject) , there would be no card found that 
would would not be in alphabetical order for that subject.  But if the catalog 
was interfiled, an entry on a different field might interrupt the ordering for 
the specific field that were searched for, a contradiction.

Re: [RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Simon Spero]

On Mon, May 14, 2012 at 2:18 PM, Karen Coyle  wrote:

>  On 5/14/12 9:33 AM, Simon Spero wrote:
>
> [I will split my response in to several parts].
>
>  On Mon, May 14, 2012 at 10:45 AM, Karen Coyle  wrote:
>
>
>>  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 [a] *replicate a card catalog display* with [b]  *records* *displaying
>> in order by the* *heading that was searched*. That is really hard to do
>> ([c] *and not possible to do efficiently*) using [d] *DBMS*functionality, 
>> which is based on [e]
>> *retrieved sets* not *linear ordering*, and [f] *especially using
>> keyword searching*.  [emphasis and labels  added]
>
>
>  These are somewhat strong claims, which may require some weakening
> before they are entirely valid.
>
>  If  [a] and [b] are both true, it must necessarily be true that in card
> catalogs records were displayed in order by the heading that was searched.
>
> there was no 'record' in the card catalog, nor a search in the sense that
> I mean. The "search" in "b" is a database search. In the card catalog you
> had cards, and you had alphabetical order. There really wasn't anything
> resembling a database search, which is an action against an index that
> results in a retrieved set of something stored in a database (which could
> be bib records or it could be headings, if you store and index those
> separately). The "start anywhere and go backwards and forwards through the
> alphabet on strings at the top of cards that are left-anchored, and see the
> heading and the other information on the card" is not something you get in
> most library catalogs. Mac's catalog is an interesting mix -- it's a
> search, not a heading browse, and each heading appears on a line with its
> record, even if more than one heading is retrieved with the search.
>
>  In a  strong reading could imply that when searching a physical card
> catalog by a heading of a specific kind (e.g. subject) , there would be no
> card found that would would not be in alphabetical order for that subject.
>  But if the catalog was interfiled, an entry on a different field might
> interrupt the ordering for the specific field that were searched for, a
> contradiction.
>
>
> I don't get this at all. Maybe an example would help?
>

The card is the record.  A card catalog is searched by finding the
drawer[s]  marked as holding entries beginning with the correct initial
letters; finding the first match within a drawer (using any algorithm for
search in a sorted random access file).  For subject access, the correct
search string may require the use of an ancillary large red books.

Suppose that the card catalog is searched by subject  where multiple
inverted headings are relevant, and that there is an author whose last name
files after the first subject, but before the inverted subjects, and that
the catalog has records by author and by subject filed together in the same
dictionary catalog.  Values for the records for the author may appear in
the subject area of the card that are not in alphabetical order by subject.

Simon

[RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Simon Spero]

>
> On Mon, May 14, 2012 at 10:45 AM, Karen Coyle  wrote:
>
>  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 *[a]* *replicate a card catalog display* with *[b]*  *records* 
> *displaying
> in order by the* *heading that was searched*. That is really hard to do (*
> [c]* *and not possible to do efficiently*) using* [d]* *DBMS*functionality, 
> which is based on
> *[e]* *retrieved sets* not *linear ordering*, and* [f] **especially using
> keyword searching*.  [emphasis and labels  added]
>

[These are somewhat strong claims, which may require some weakening before
they are entirely valid.  I will not unpack the term  "record" here.]

BLUF: Not all DBMS  are Relational;  it is possible to efficiently retrieve
records in order from many different types of DBMS, including Relational
databases.

[c] and [d] make the claim that it is impossible to retrieve records
efficiently in some desired order using DBMS functionality.  This is
justified by [e] which claims that the source of this necessary
inefficiency is that DBMS functionality is based on "retrieved sets" not
"linear ordering".

It is difficult to work out what the intended reading of [e] is. The use of
the term "sets" in "retrieved sets", if interpreted in a mathematical
sense, which would indeed make the concept of ordering nonsensical, as the
elements within sets are unordered.  However, since the claim is made in
support of claims about possible efficiency, and since this is an attribute
of possible systems, this reading cannot be the intended one.

All of the major types of DBMS implementations have some form of ordering,
 internally, and in the query language.   It is trivially true that in SQL
based databases, the order in which the results of queries are retrieved is
unspecified if you do not specify the order in which you want results to be
returned, but even if we restrict ourself to these kinds of databases, this
is not sufficient to support the strong claim.  However, even though what
the order in which the results might be unspecified, results are returned
in *some* order, one after another.  [e] thus cannot provide support for
[c] and [d].

The internal arrangement of database records on disk is generally in some
kind of  linear order- to a first approximation, the records are stored one
after the other in some  order. This internal  order may be as simple as
 the order in which the records were added to the database, or it may be an
order based on the content of one of the fields of the record.  If not
otherwise specified, the order in which records are returned is based on
this internal order*.

For example, the Relational DBMSs  Oracle and PostgresSQL both allow for
records to be clustered (ordered on disk) so as to make retrieval in that
order extremely efficient.
Object Oriented DBMSs are usually quite efficient at following links to
related records, and many will optimize based on patterns of
 retrieval order.
Some OODBMS-like systems in the NoSQL family are entirely memory resident,
making disk access irrelevant.
Hierarchical databases like IDMS can be very fast at following the chains
around which they are organized.

Since we can efficiently  retrieve records, in some specified order, using
some DBMS, we have a counter-example to [c].

The claim can be weakened to a claim of possible inefficiency, but that is
 not unexpected in an ILS context :-)

Claim [f] may or may not be considered to hold; one can replicate the
database record once for each keyword that occurs, which is roughly
 equivalent to KWIC, which of course, trades space efficiency for time.  If
records are not replicated, keyword access to an indexed field may require
a separate disk access for every record that matches the keyword (when the
match is not at the start of the string).

Often read requests will be ordered so that disk head movement is
minimised; where this happens this is faster than purely random access.

 If the entire database is memory resident, or if all relevant records are
in cache, the overhead of disk access is irrelevant. In this case [f] does
not hold.


I hope this isn't too confusing,

Simon

* In some situations involving multiple tables, some systems  may return
records in a different order if no specific order is requested.  This is
due to decisions that the DBMS makes on the fastest way of answering the
query.  Since not asking for results to be returned in a specific order
tells the system that you don't care about ordering, the system may choose
to use different algorithms when running your query.  This extra freedom to
optimize is  why the order of results is unspecified by default.

Re: [RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Karen Coyle]

On 5/14/12 9:33 AM, Simon Spero wrote:

[I will split my response in to several parts].

On Mon, May 14, 2012 at 10:45 AM, Karen Coyle > wrote:


 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 [a] /replicate a card catalog
display/ with [b] /records/ /displaying in order by the/ /heading
that was searched/. That is really hard to do ([c] /and not
possible to do efficiently/) using [d] /DBMS/ functionality, which
is based on [e] /retrieved sets/ not /linear ordering/, and [f]
/especially using keyword searching/.  [emphasis and labels  added]


These are somewhat strong claims, which may require some weakening 
before they are entirely valid.


If  [a] and [b] are both true, it must necessarily be true that in 
card catalogs records were displayed in order by the heading that was 
searched.
there was no 'record' in the card catalog, nor a search in the sense 
that I mean. The "search" in "b" is a database search. In the card 
catalog you had cards, and you had alphabetical order. There really 
wasn't anything resembling a database search, which is an action against 
an index that results in a retrieved set of something stored in a 
database (which could be bib records or it could be headings, if you 
store and index those separately). The "start anywhere and go backwards 
and forwards through the alphabet on strings at the top of cards that 
are left-anchored, and see the heading and the other information on the 
card" is not something you get in most library catalogs. Mac's catalog 
is an interesting mix -- it's a search, not a heading browse, and each 
heading appears on a line with its record, even if more than one heading 
is retrieved with the search.
In a  strong reading could imply that when searching a physical card 
catalog by a heading of a specific kind (e.g. subject) , there would 
be no card found that would would not be in alphabetical order for 
that subject.  But if the catalog was interfiled, an entry on a 
different field might interrupt the ordering for the specific field 
that were searched for, a contradiction.


I don't get this at all. Maybe an example would help?

kc

Thus, a  weaker reading, that allows for interruptions of other 
records that are not in order of the searched for field must be intended.





--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[J. McRee Elrod]

Karen asked:

>Mac, I'd love to see your file design. I did find an example of a record 
>that appears more than once in a single list, and I am wondering if you 
>had to replicate the record in the database to accomplish that, or if 
>you have another way to retrieve a record more than once on a single 
>keyword retrieval.

I'm copying your question to the designer  who should be able
to answer your question.


> http://www.canadianelectroniclibrary.ca/cel-arc.html


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

[RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Simon Spero]

[I will split my response in to several parts].

On Mon, May 14, 2012 at 10:45 AM, Karen Coyle  wrote:


>  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 [a] *replicate a card catalog display* with [b]  *records* *displaying
> in order by the* *heading that was searched*. That is really hard to do
> ([c] *and not possible to do efficiently*) using [d] *DBMS*functionality, 
> which is based on [e]
> *retrieved sets* not *linear ordering*, and [f] *especially using keyword
> searching*.  [emphasis and labels  added]


These are somewhat strong claims, which may require some weakening before
they are entirely valid.

If  [a] and [b] are both true, it must necessarily be true that in card
catalogs records were displayed in order by the heading that was searched.
 In a  strong reading could imply that when searching a physical card
catalog by a heading of a specific kind (e.g. subject) , there would be no
card found that would would not be in alphabetical order for that subject.
 But if the catalog was interfiled, an entry on a different field might
interrupt the ordering for the specific field that were searched for, a
contradiction.  Thus, a  weaker reading, that allows for interruptions of
other records that are not in order of the searched for field must be
intended.

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Karen Coyle]

Mac, I'd love to see your file design. I did find an example of a record 
that appears more than once in a single list, and I am wondering if you 
had to replicate the record in the database to accomplish that, or if 
you have another way to retrieve a record more than once on a single 
keyword retrieval.


kc

On 5/14/12 8:53 AM, J. McRee Elrod wrote:

Karen said:


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...


If I understnad what you mean, we had no difficulty doing this.  One
example:

http://www.canadianelectroniclibrary.ca/cel-arc.html


__   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
   {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
   ___} |__ \__





--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[J. McRee Elrod]

Karen said:

>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...
 
If I understnad what you mean, we had no difficulty doing this.  One
example:

http://www.canadianelectroniclibrary.ca/cel-arc.html


   __   __   J. McRee (Mac) Elrod (m...@slc.bc.ca)
  {__  |   / Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
  ___} |__ \__

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Karen Coyle]

On 5/14/12 6:13 AM, Brenndorfer, Thomas wrote:
Scenario 3 is card catalogs, which relies upon filing rules. Scenario 
1 relies upon entities just linking to entities, not necessarily 
relying on mechanisms such as volatile and difficult-to-manage 
authorized access points.
Scenario 3 calls itself "‘Flat file’ database structure (no links)", and 
I suspect that there are catalogs that do not have database-managed 
links between headings and authority files. They are, as you say, kind 
of database versions of the card catalog, but they are still databases.


kc

--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Jonathan Rochkind]

On 5/14/2012 10:45 AM, Karen Coyle wrote:


No, I'm saying that JSC made a claim that RDA was developed on RDBMS
principles


Where do you find this claim?

I've seen documentation that FRBR (and by extension RDA) was developed 
based on entity-relational modelling.


That's not the same thing as 'rdbms principles'.  Entity-relational 
modelling is compatible with, and indeed even the foundation of, RDF too.


Jonathan

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Karen Coyle]

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

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Brenndorfer, Thomas]

> -Original Message-
> From: Resource Description and Access / Resource Description and Access
> [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg
> Sent: May 14, 2012 5:29 AM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> Subject: Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
> 
> 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.
> 


Scenario 2 is MARC, which relies upon authorized access points for machine 
linking and is what most people will be using for RDA in the short term, and 
will be testing on. Scenario 3 is card catalogs, which relies upon filing 
rules. Scenario 1 relies upon entities just linking to entities, not 
necessarily relying on mechanisms such as volatile and difficult-to-manage 
authorized access points.

Thomas Brenndorfer
Guelph Public Library

Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF

[Bernhard Eversberg]

13.05.2012 19:49, Karen Coyle:


After struggling for a long time with my frustration with the
difficulties of dealing with MARC, FRBR and RDA concepts in the
context of data management, I have done a blog post that explains
some of my thinking on the topic:

  http://kcoyle.blogspot.com/2012/05/rda-dbms-rdf.html

The short summary is that RDA is not really suitable for storage and
use in a relational database system, and therefore is even further
from being suitable for RDF. I use headings ("access points" in RDA,
I believe) as my example, but there are numerous other aspects of RDA
that belie its intention to support "scenario one."



You've done a very concise and elucidating description of the calamity,
and there certainly needs to be discussion about it.

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.)

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?

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.

B.Eversberg