On Mon, Nov 17, 2008 at 07:16:30AM -0800, Karen Coyle wrote:
> On Mon, Nov 17, 2008 at 4:47 AM, Stephens, Owen
> <[log in to unmask]> wrote:
> > Alistair,
> >
> > In Scenario 1, you say that 'publisher' is not defined in RDA Element
> > Vocabulary. Is this not
> > http://metadataregistry.org/schemaprop/show/id/93.html?
Yes, but I expect all property names to start with a lower case
character -- this is a minor issue in the RDA elements vocab, the
property URI just needs changing from .../Publisher to .../publisher.
>
> Owen, for reasons that are complex, there are two RDA schemas:
> elements and roles. The roles terms came from a list that LoC created,
> and does not include publisher. Publisher (and manufacturer) are
> included in the RDA elements, while other roles like "illustrator" or
> "editor" are in the list of roles. So we have an RDA-ism here that
> needs to be worked out. I assume that Alistair was looking for
> publisher in the list of roles, where it logically would be.
No, I was looking for it in the elements, see above.. sorry for
confusion.
This doesn't invalidate any of your very interesting discussion tho...
>
> The RDA developers are clearly thinking in terms of today's records,
> where you have a field for a personal name, and you can add the "role"
> to that field. But you also have a field for the publication
> information, and that has an element called publisher (not an element
> for a corporate name with the role publisher). This means that there's
> an inconsistency in how agents are treated in RDA. For compatibility
> with RDF, we should treat all of the all of the roles as properties,
> and allow the value to be either a person or a corporate entity. This,
> however, is very different from how librarians think about their data.
> In fact, the use of roles has diminished over recent decades, and
> names are added to records without any roles being included, meaning
> that there really is no "author" field, just a name field. It's not
> that hard to find records (see: http://lccn.loc.gov/80008730) with an
> author and a translator, and both are simply coded as a personal name.
> The roles are only visible in the "statement of responsibility" that
> follows the title, but that's a text field intended for the human
> reader.
>
> This is one of those areas of library cataloging that puzzles me. For
> all of the precision of the rules, in the end we are very imprecise
> about the relationships of creators to the works. I'm not at all sure
> that we'll see library records using the roles as properties, and I
> suspect that we'll need to define a generic "agent" property so that
> we can create records that look like the ones in catalogs today.
Cheers,
Alistair
> >> -----Original Message-----
> >> From: List for discussion on Resource Description and Access (RDA)
> >> [mailto:[log in to unmask]] On Behalf Of Alistair Miles
> >> Sent: 12 November 2008 18:11
> >> To: [log in to unmask]
> >> Subject: New analysis of RDA cataloguer scenarios 2 and 3; scenario 1
> >> revised
> >>
> >> Hi all,
> >>
> >> I've just spend another day working on the RDA cataloguer scenarios,
> >> here's what I've done.
> >>
> >> I reviewed and revised the RDF expression of scenario 1 in light of a
> >> small number of changes to the RDA elements vocabulary since
> >> 2008-10-11 (when I did the last revisition):
> >>
> >> http://dublincore.org/dcmirdataskgroup/Scenarios/1
> >>
> >> I created a first draft RDF expression of scenarios 2 and 3:
> >>
> >> http://dublincore.org/dcmirdataskgroup/Scenarios/2
> >> http://dublincore.org/dcmirdataskgroup/Scenarios/3
> >>
> >> The analysis at the bottom of each of these pages checks that all
> >> classes and properties used in the scenario are defined in either the
> >> RDA Elements, RDA Roles or FRBR Core vocabularies. It also shows any
> >> major issues for these vocabularies, e.g. where a property is required
> >> but not defined somewhere -- the fact that there are very few of these
> >> demonstrates that the vocabularies are sufficient to express the given
> >> scenarios.
> >>
> >> Some further notes are at
> >>
> >>
> >>
> > http://dublincore.org/dcmirdataskgroup/AlistairMiles/AnalysisNotes20081
> >> 112
> >>
> >> I haven't gone through these new scenarios yet to try to
> >> systematically capture issues that they raise, I think it's probably
> >> better to work through the remaining cataloger scenarios (4, 5, 6)
> >> then go through and do a systematic analysis, capturing issues in a
> >> central place.
> >>
> >> That's all for now.
> >>
> >> Cheers,
> >>
> >> Alistair
> >>
> >> --
> >> Alistair Miles
> >> Senior Computing Officer
> >> Image Bioinformatics Research Group
> >> Department of Zoology
> >> The Tinbergen Building
> >> University of Oxford
> >> South Parks Road
> >> Oxford
> >> OX1 3PS
> >> United Kingdom
> >> Web: http://purl.org/net/aliman
> >> Email: [log in to unmask]
> >> Tel: +44 (0)1865 281993
> >
>
>
>
> --
> -- ---
> Karen Coyle / Digital Library Consultant
> [log in to unmask] http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> mo.: 510-435-8234
> ------------------------------------
--
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: [log in to unmask]
Tel: +44 (0)1865 281993
|