Print

Print


Robin:

It wasn't our choice--JSC wanted to do it that way, despite our 
recommendations that they not do so. Some CC:DA members agreed with us, 
and commented to that effect during constituency review. But, we'd 
agreed to do it their way for our part of the project, so we did. The 
WEMI relationships are specifically labeled as to their FRBR entity, but 
the Roles only refer to which one they're associated with (mostly) in 
their definitions. The Elements do not yet generally have these 
relationships specified, because the FRBR entities have not yet been 
registered by IFLA (though they've said "soon" for some time), and we've 
resisted making something up on our own.

This doesn't mean, BTW, that every community interested in extending RDA 
to reflect their own needs has to do it that way, and we're hoping most 
don't.

Diane

Robin Wendler wrote:
> A question for Karen and Diane, from my ignorance, about those RDA 
> terms: from a modeling perspective, why was it desirable to have 
> separate relationships for each type of resource the relationship can 
> apply to (e.g. "Work" in evaluationOfWork)? It seems preferable to let 
> the resources declare their own properties rather than packing those 
> properties into a relationship.
>
> Curiously yours,
> --Robin
>
>
>
> At 10:52 AM 3/11/2009 -0700, Karen Coyle wrote:
>> The terms in Appendix J of RDA have been entered into the Metadata 
>> Registry:
>> http://metadataregistry.org/schemaprop/list/schema_id/13.html
>>
>> Because they each have a unique identifier, you could use them 
>> unambiguously (if not 'legally') in a MODS record. The difficulty 
>> will be that they have implied in them the FRBR levels (work, 
>> expression, etc.), but you could probably decide to stick to 
>> manifestation as a safe choice. I guess that would have to imply that 
>> you are recording a manifestation-to-manifestation relationship. 
>> Where I think things might break down will be in the lack of 
>> identifiers for the bibliographic items, so it will be hard to get a 
>> good fix on the reciprocity in a system unless you use system 
>> numbers. If you try this out, let us know how it works.
>>
>> kc
>>
>> Rhonda Marker wrote:
>>> This is not the only case in which the relatedItem type vocabulary 
>>> is frustratingly limited. The MARC origins of MODS are weighing us 
>>> down. (Never mind-- that's just a splinter in my finger so to speak, 
>>> not the main point here.)
>>>
>>> I'd like to see more explicit reciprocity in the type vocabulary 
>>> when it is warranted, e.g. "reviewOf" and "ReviewIn". I'd also like 
>>> to see a more elastic registry of <relatedItem> type values so that 
>>> we don't have to move heaven and earth to apply the element to fit 
>>> our needs. To begin with I'd like to see MODS populate the type 
>>> vocabulary for this element with the relationship designators found 
>>> in the RDA draft, Appendix J.
>>>
>>> Rhonda Marker
>>> Repository Collection Manager
>>> Scholarly Communication Center / Alexander Library
>>> Rutgers University Libraries
>>>
>>> ArjanTh wrote:
>>>> Dear MODS users,
>>>>
>>>> The Dutch scientific institutions – united in Surfshare (the 
>>>> successor of
>>>> DAREnet) – have decided to use MODS in the description of objects 
>>>> in their
>>>> repositories. The main reason to do so is the higher granularity 
>>>> MODS offers
>>>> to its users.
>>>>
>>>> For most type of documents, MODS is providing us with nice examples 
>>>> in the
>>>> “Sample MODS Version 3 XML Documents”, available at:
>>>> http://www.loc.gov/standards/mods/mods-guidance.html. 
>>>> Unfortunately, no
>>>> example has been given on how to handle with ‘book reviews’.
>>>> Of course, others have pointed out this problem as well (see the 
>>>> discussions
>>>> on the MODS forum). But pointing out the problem will not 
>>>> automatically lead
>>>> to a final solution. In November 2007, Jenn Riley has started the
>>>> discussion on this subjects and Joe Altimus has made good 
>>>> suggestions to
>>>> overcome the problems (as agreed to by Rebecca Guenther).
>>>>
>>>> Meanwhile, workarounds are being developed at several places to 
>>>> create book
>>>> review descriptions in MODS. This is understandable, but we don’t 
>>>> think this
>>>> is a welcome development.
>>>> In Europe (the DRIVER project) and more specifically in the 
>>>> Netherlands, we
>>>> need to find a way to handle ‘book reviews’ as soon as 
>>>> possible. The Royal
>>>> Netherlands Academy of Arts and Sciences (the maintainer of the 
>>>> service
>>>> 'NARCIS', www.narcis.info) proposes to introduce the new type value
>>>> "reviewOf" for 'relatedItem'. [ relatedItem type="reviewOf"> ].
>>>>
>>>> This solution is quite similar to the one explained by Joe Altimus in
>>>> November 2007. In Europe it is supported by Benoît Pauwels of the 
>>>> Free
>>>> University of Brussels.
>>>>
>>>> With this new type value "reviewOf" it will be clear to everyone 
>>>> how to
>>>> create book review descriptions in MODS and it will stop the 
>>>> development of workarounds. Besides, we think this proposal is 
>>>> rather easy to implement.
>>>>
>>>> Furthermore, it would we helpful when the 'book review' - after the 
>>>> approval
>>>> of this proposal - will be introduced in the “Sample MODS Version 
>>>> 3 XML
>>>> Documents”.
>>>>
>>>> Arjan Hogenaar
>>>>
>>>> -- 
>>>> Arjan Hogenaar
>>>> Research Information
>>>> Royal Netherlands Academy of Arts and Sciences
>>>> Kloveniersburgwal 29, Amsterdam
>>>> P.O. Box 19121, 1000 GC Amsterdam
>>>> T.: +31 (0)20-4628641
>>>> W: www.knaw.nl
>>>>
>>>>
>>>
>>
>> -- 
>> -----------------------------------
>> Karen Coyle / Digital Library Consultant
>> [log in to unmask] http://www.kcoyle.net
>> ph.: 510-540-7596 skype: kcoylenet
>> fx.: 510-848-3913
>> mo.: 510-435-8234
>> ------------------------------------
>