headers
B.G. Sloan | 1 Dec 16:23
Picon
Favicon

LJ report on Draft Report of the Working Group on the Future of Bibliographic Control

  Norman Oder of Library Journal has a brief report on the Draft Report of the Working Group on the Future of
Bibliographic Control.

  "The opening paragraph of the report, issued today, is stark".

  http://www.libraryjournal.com/article/CA6508740.html

  Bernie Sloan

---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
Permalink | Reply | 0 comments |
headers
Laura Jenemann | 2 Dec 16:43
Picon
Favicon

Re: LJ report on Draft Report of the Working Group on the Future of Bibliographic Control

Thank you for posting this.  I am particularly fascinated by the RDA comments in the Draft.  Since I've
started reading RDA, I've wondered about many of the points brought up about RDA in the Draft Report (p.24,
25), and would love to hear more from the list about this.  I've also been excited about some of the comments
made in The Changing Nature of the Catalog and its Integration with Other Discover Tools - http://www.loc.gov/catdir/calhoun-report-final.pdf

And each time I've read RDA documentation as a reviewer, I realize that my work as a professional, albeit,
unconventionally so, cataloger has not prepared me at all for the highly technical language of RDA - i.e.,
I feel really dumb reading it.  But maybe if I just patiently read FRBR I'd get RDA.  But then again, this may be
precisely the point: RDA may be indicative of the changing professional definition of what a "cataloger"
is, one that may wonderfully make us all the go-to metadata experts not only in libraries, but in other
arenas as well, even if it results in a changing reality where the abilities of people like me aren't best
suited for this brave new world.  And I personally like the user-centered approach that the Draft Report
and Calhoun's Report take in some regards, less so 
 in others, especially when large research organizations like NYPL see these initiatives as a business
opportunities for "merging" their research and branch functions - yet another changing
reality to learn to be at peace with.  But that's a discussion for a different listserv.

Anyhow, sorry to ramble on, and thanks again for posting!
Laura Jenemann
The History Channel, CLiMB2 (Computational Linguistics for Metadata Building 2), Bronxville Library,
Somers Library
lj27 <at> drexel.edu

----- Original Message -----
From: "B.G. Sloan" <bgsloan2 <at> YAHOO.COM>
Date: Saturday, December 1, 2007 10:23 am
Subject: [NGC4LIB] LJ report on Draft Report of the Working Group on the Future of Bibliographic Control

>  Norman Oder of Library Journal has a brief report on the Draft
> Report of the Working Group on the Future of Bibliographic Control.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Rob Styles | 3 Dec 11:26

Re: FW: [NGC4LIB] Martha Yee's cataloging rules for a more FRBR-ized catalog, with an RDF model

Martha,

No I hadn't seen this, it's useful work. Great examples in there. I'd
love to see some example RDF based on the rules - that might clarify
some of Karen's questions.

Dan posted a query to the list before, to let you guys see what our
data looks like, here's the tinyurl version (that works)...

http://tinyurl.com/3xpxdc

Karen, Martha, How does that compare with what you were thinking?

rob

On 30 Nov 2007, at 17:44, Martha Yee wrote:

> Have either of you looked at the RDF model at my web site
> (http://myee.bol.ucla.edu) yet?  Unless I am misunderstanding you,
> I believe
> these rules and this RDF model are trying to do what you are asking
> us to
> do...  The question for me is whether our current deprofessionalized
> staffing is capable of implementing such a complex set of rules and
> such a
> complex model...
>
> Martha
>
> -----Original Message-----
(Continue reading)

Permalink | Reply | 11 comments |
headers
Bernhard Eversberg | 3 Dec 08:55
Picon
Picon
Favicon

Exculpation of MARBI

Karen Coyle wrote:

> Bernhard Eversberg wrote:
>
>> In current MARC, there are no reliable means at all to link
>> bibliographic records with each other! We are badly in need of this
>> for whole-part relationships, like multipart records, and then all
>> the other work - expression - manifestation relationships envisaged
>> by FRBR and RDA. This has been known for a long time, but what has
>> MARBI done about it?
>
> You may be mis-interpreting the role of MARBI. MARBI is an advisory
> group to LC on the MARC21 data standard. At each ALA it looks at
> recommendations that have been received by LC, and that LC has passed on
> to the committee. MARBI does NOT originate any proposals itself. As a
> matter of fact, I don't know if it is possible to present a proposal
> directly to MARBI rather than to and through the Library of Congress.

So my mis-interpretation was a gross over-estimation of MARBI's
capacities. Too bad. The question, however, doesn't go away with that,
it only turns into "What has LC done about it?" And as I said earlier,
and more than once, without LC making a major move, nothing's
going to move. The bibliographic universe revolves around LC. If I
understand it right, they are now getting to feel uneasy about this
role, though. But with this center of gravity loosening its pull, will
our poor little universe not expand and evaporate into all directions?

B.Eversberg
(Continue reading)

Permalink | Reply | 0 comments |
headers
Debbie Pennino | 3 Dec 12:04

Deborah Pennino/Library/NEU is out of the office.

I will be out of the office starting  12/03/2007 and will not return until
01/02/2008.

I will respond to your message when I return.
Permalink | Reply | 0 comments |
headers
Dan Mullineux | 3 Dec 12:05

Re: FW: [NGC4LIB] Martha Yee's cataloging rules for a more FRBR-ized catalog, with an RDF model

Rob.

From my reading of Martha's work, I think the biggest difference is that
we are trying to address the 'entities' in the marc data as being
unique-ish global resources, whereas, and I admit I have not consumed
all Martha's documents, it appears most predicates in Martha's schemas
are literals, in much the same way that Ian Davis' lossless marc to rdf
transliteration was.

The obvious difference, is our work is still undocumented, and nothing
like as rich in domain detail, yet.

Dan.

-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB <at> listserv.nd.edu] On Behalf Of Rob Styles
Sent: 03 December 2007 10:26
To: NGC4LIB <at> listserv.nd.edu
Subject: Re: [NGC4LIB] FW: [NGC4LIB] Martha Yee's cataloging rules for a
more FRBR-ized catalog, with an RDF model

Martha,

No I hadn't seen this, it's useful work. Great examples in there. I'd
love to see some example RDF based on the rules - that might clarify
some of Karen's questions.

Dan posted a query to the list before, to let you guys see what our data
looks like, here's the tinyurl version (that works)...
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rob Styles | 3 Dec 15:24

Re: FW: [NGC4LIB] Martha Yee's cataloging rules for a more FRBR-ized catalog, with an RDF model

I haven't read all of Martha's work yet either, but it is clear she's
thinking beyond string literals:

> 2. We need to be able to identify a work for human beings (rather
> than machines) using a combination of both the author and the title
> (when there is an author), but we also need to treat the author as
> an entity (in RDF terms, a class?) so that we can create a record
> for it that contains all of its variant names, biographical
> information and so forth. I think what I am saying is that we need
> to treat an author as both an entity in its own right and as a
> property of a work, and in many cases the latter is the more
> important function for user service. Is it possible to model this?
> Or is it possible that RDF (and other data modelling) works against
> effective use of bibliographic data because of an absolute
> requirement that something either be a class or a property, but
> never both?

from: http://myee.bol.ucla.edu/rdfmodel.html

Martha, to answer the question if it's still posed... A resource,
such as http://example.com/composer/monteverdi in your examples may
have a class (rdf:Type) and be used as a property by other resources.
The distinction between classes and properties is in the schema URIs
rather than the URIs in the dataset, so your example might look like:

<http://example.com/composer/monteverdi> <rdf:Type> <http://
someschema.com/contributortypes#Composer> .
<http://example.com/composer/monteverdi> <rdf:Label> "Claudio
Monteverdi" .
<http://example.com/work/123456789> <http://purl.org/dc/elements/1.1/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Karen Coyle | 3 Dec 15:31

Re: FW: [NGC4LIB] Martha Yee's cataloging rules for a more FRBR-ized catalog, with an RDF model

Dan Mullineux wrote:
> Rob.
>
>>From my reading of Martha's work, I think the biggest difference is that
> we are trying to address the 'entities' in the marc data as being
> unique-ish global resources, whereas, and I admit I have not consumed
> all Martha's documents, it appears most predicates in Martha's schemas
> are literals, in much the same way that Ian Davis' lossless marc to rdf
> transliteration was.

Exactly the case. So it would be interesting to create a workable
mash-up between Martha's view, which is very semantically rich but
reproduces the traditional cataloging-as-text, and a more "entity"-based
view, which defines global resources. To do this, of course, we need to
have the key elements of our data defined elsewhere on the Web,
preferably in a registry. I'm wondering if we couldn't create registry
stubs somewhere -- that is, create a registry entry just for the group
without adding all of the entries -- and use that in the development of
the schema. That would save time and allow us to model the schema fairly
quickly.

In the work that we are planning relating to RDA and RDF, we have
identified something like 45 or 50 inline vocabularies in RDA, and I
don't know how many classes and properties (since we haven't done that
work yet). This is based on the RDA rules, much as Martha's work is
based on her rules. I think that the actual RDF may be much reduced as
we explore the nature of different fields in the cataloging rules.

I am interested in discussing all of these schemas in greater depth, and
am trying to figure out a way to do so on the futurelib wiki
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karen Coyle | 3 Dec 15:40

Re: FW: [NGC4LIB] Martha Yee's cataloging rules for a more FRBR-ized catalog, with an RDF model

Rob Styles wrote:
> Martha,
>
> No I hadn't seen this, it's useful work. Great examples in there. I'd
> love to see some example RDF based on the rules - that might clarify
> some of Karen's questions.
>
> Dan posted a query to the list before, to let you guys see what our
> data looks like, here's the tinyurl version (that works)...
>
> http://tinyurl.com/3xpxdc
>
> Karen, Martha, How does that compare with what you were thinking?

It's a bit hard to judge from one record, of course. ;-) As Dan said,
this makes use of global entities, and I think we need to work more on
defining those in a truly global way so that we can all be working off
of the same entity set, regardless of what we then do with them in
records. In the library environment, properties like your "displayAs"
and "seenAs" will need to be more specific, so that

<j.0:seenAs>Jackson, Joseph H.(Joseph Hollister)</j.0:seenAs>

would have to make clear that this is the AACR2 form of the name. But
these are details that can be worked out.

I would like for us to think along the lines of the Dublin Core
"dumb-down" rule, which makes it possible for one community to have a
highly detailed view of the data, and another community can have a less
detailed view without losing any data. So you might be happy with a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Lease Morgan | 3 Dec 16:01
Picon

Re: FW: [NGC4LIB] Martha Yee's cataloging rules for a more FRBR-ized catalog, with an RDF model

On Dec 3, 2007, at 9:24 AM, Rob Styles wrote:

> <http://example.com/composer/monteverdi> <rdf:Type> <http://
> someschema.com/contributortypes#Composer> .
> <http://example.com/composer/monteverdi> <rdf:Label> "Claudio
> Monteverdi" .
> <http://example.com/work/123456789> <http://purl.org/dc/elements/1.1/
> creator> <http://example.com/composer/monteverdi> .
>
> so the Class http://someschema.com/contributortypes#Composer is used
> to indicate that Monteverdi is a Composer, and the property http://
> purl.org/dc/elements/1.1/creator used to indicate that he composed
> whatever 123456789 refers to.

I think this discussion is moving in the right direction.

Using the methods outlined above there will: 1) much less ambiguity
regarding the relationships between works, creators, subjects,
publishers, etc., and 2) make it much easier for computers to
supplement the process of creating new relationships between works,
creators, subjects, publishers, etc. This is true since the data/
information about the content of these entities is manifested using
relational database normalization techniques.

Moreover, it might be good to point out, again, that everybody here
is offering something. XML for the techno-weenies. Classification for
the catalogers. So often it is not so much about the "what" of our
work but the "how". The what doesn't change very fast. The how
changes very quickly. The RDF above is an illustration. What we are
doing is description and classification -- an age-old library thing.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane