Martha,
I've finally gotten a chance to see these. Very impressive work, but I do have a couple of questions, although others may have asked them already and I haven't see them yet.
I see that you have publication information in the expression record. FRBR does not have publication information as attributes of the expression, but of the manifestation. As you know, I have serious problems with FRBR's concept of manifestation, but I don't know if I believe that the publication info should go into the expression. (Although I realize this is the practical method for catalogers to determine different expressions/editions, as given in LCRI 1.0).
Concerning the point below, coding a name as "AACR2 form" is not entirely correct since 99% of the time, AACR2 forms of name are based on the way a person's or corporate body's name appears on the first item cataloged with cross-references made from any other forms that come into the catalog later. Therefore, it is very possible that different catalogs, both following AACR2, could come up with different forms of the same name. Forms of name are linked to those used in a particular database, so something like "LCNAF" form would be more correct.
Jim Weinheimer
> 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
> person with a set of "seenAs" "displayAs" properties, while
> an academic
> library may wish to designate these as "AACR form" "AACR2
> form" "sort
> form", etc.
>
> kc
>
> >
> > 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-----
> >> From: Next generation catalogs for libraries
> >> [mailto:NGC4LIB_at_listserv.nd.edu]On Behalf Of Riley, Jenn
> >> Sent: Friday, November 30, 2007 9:14 AM
> >> To: NGC4LIB_at_listserv.nd.edu
> >> Subject: Re: [NGC4LIB] Martha Yee's cataloging rules for a more
> >> FRBR-ized catalog, with an RDF model
> >>
> >>
> >>> Martha Yee wrote:
> >>>> I have written elsewhere about the fact that our rules and our
> >>> cataloging
> >>>> data are already considerably FRBR-ized and that what is
> lacking for
> >>> the
> >>>> creation of true FRBR-ized catalogs is adequate software
> support.
> >>>
> >>> Martha, you and I have discussed this at length, so you know that I
> >>> disagree that the problem lies with systems. It is true that
> >>> bibliographic records are very rich and contain a lot of important
> >>> data.
> >>> However, as long as bib data continues to be expressed as text
> >>> strings
> >>> that require human interpretation, systems will NOT be able to
> >>> make use
> >>> of the underlying concepts. This is one of the great errors in the
> >>> RDA
> >>> drafts that we have seen: the bibliographic description continues
> >>> to be
> >>> textual in nature, with relationships left as implicit in that
> >>> text. We
> >>> need rules that can make explicit what today is implicit. And we
> >>> need a
> >>> bibliographic record carrier that can carry those explicit
> >>> expressions.
> >>
> >> Surely, now, the problem is to some degree both with the data and the
> >> systems. There is a great deal more systems could do with our
> >> existing data,
> >> but our current data structures also in some cases make it
> >> significantly
> >> more difficult than it should be (and sometimes impossible) for
> >> systems to
> >> do more advanced things imagined by this group.
> >>
> >> I see much of the current debate about why our catalogs don't function
> >> better as finger-pointing -- "if only *they* (some group other
> than
> >> mine)
> >> would do it better..." I think to move forward we need to accept
> >> that all of
> >> us have something to contribute, and take responsibility for making
> >> that
> >> contribution. I ha
> ve every hope that the work that has been done to
> >> improve
> >> systems will demonstrate some of the possibilities, and in turn
> >> both inspire
> >> more innovative system development and expose areas in which our
> >> data could
> >> be better-structured in order to enable more robust discovery and use
> >> services.
> >>
> >> Jenn
> >>
> >>
> >> ========================
> >> Jenn Riley
> >> Metadata Librarian
> >> Digital Library Program
> >> Indiana University - Bloomington
> >> Wells Library W501
> >> (812) 856-5759
> >> www.dlib.indiana.edu
> >>
> >> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
> >
> >
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> kcoyle@kcoyle.net http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
Received on Mon Dec 03 2007 - 10:55:34 EST