Good Idea. In the same way that rdf would allow us to talk about a
single expression in terms of different 'styles' of properties (DC, AACR
etc), it can also allow us to merge other 'schemas', such that one
expression can be constructed from marc or ONIX (e.g. they both have
creator), then although we can be confident that we are referring to the
single 'true' expression we can still also see any data that caused the
relation, either in a single rdf graph or separate (that is just an
implementation issue)
For similar reasons (different view of the same data) we have chosen to
always maintain a link to the unviolated original record. So any entity
(at least manifestations) will have a reference to the resource from
which it was derived in a 'createdFrom' property:
<j.0:createdFrom
rdf:resource="http://api.talis.com/stores/freecat/items/6b23d7a5-b14a-4b
14-9f6c-dda16d5b0033"/>
So:
http://api.talis.com/stores/freecat/items/6b23d7a5-b14a-4b14-9f6c-dda16d
5b0033
Contains a raw iso2709 marc file, and there could be many 'createdFrom'
properties. This imo helps bridge both worlds.
Dan.
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Karen Coyle
Sent: 03 December 2007 14:41
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
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 have 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_at_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:12:26 EST