headers
Karen Coyle | 11 Mar 2009 18:52

Re: Addition of new type value "reviewOf" for relatedItem

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.
>
(Continue reading)

Permalink | Reply |
headers
Riley, Jenn | 12 Mar 2009 01:07
Picon
Favicon

Re: Addition of new type value "reviewOf" for relatedItem

Hello all,

The MODS/MADS Editorial Committee has just begun the process of analyzing proposals for changes to the
next version of MODS. We're currently planning both a new minor release (3.4) and a major release (4.0).
3.4 will be backwards compatible to 3.3 and therefore only be able to introduce certain types of changes.
4.0 will not be backwards compatible and therefore offer us the opportunity to make some structural and
otherwise significant changes, such as greater use of externally-defined vocabularies and
properties. We'll start posting to the list and the MODS web sites reports of our conversations as they happen.

The conversation in this thread has suggested both short-term (3.4) and long-term (4.0) ways in which the
problem raised might be addressed in MODS. I expect this issue will be on our discussion agenda for our next
call in two weeks, March 25. Thanks for re-raising the book review issue, Arjan, and stay tuned for
information on the Editorial Committee's discussion.

In the meantime, we're actively reviewing change proposals, so if you have them, post them here!

Jenn Riley
Chair, MODS/MADS Editorial Committee


========================
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
(Continue reading)

Permalink | Reply |
headers
ArjanTh | 24 Mar 2009 12:59
Picon

Re: Addition of new type value "reviewOf" for relatedItem

Dear all,

Thank you for your constructive ideas. The main point in my original posting
was how to prevent the development of all kinds of workarounds to create
book_review descriptions in MODS. Therefore, I proposed a possible solution. 

I hope the MODS/MAPS committee will come with good suggestions. We have had
a look on the genre "review", but we've decided not to use it becasue of the
lacking of a good definition. This is exactly what Karen Coyle mentioned.

I agree with Karen that there are related problems to be solved. But on the
other hand, we see in Europe in the more traditional repositories the
standard set of publication types, all of them described in the "MODS
samples", except for the type "book review". 

So, I hope we can find an acceptable way to describe "book reviews" in order
to create uniform and exchangeable records.

Arjan Hogenaar

Riley, Jenn wrote:
> 
> Hello all,
> 
> The MODS/MADS Editorial Committee has just begun the process of analyzing
> proposals for changes to the next version of MODS. We're currently
> planning both a new minor release (3.4) and a major release (4.0). 3.4
> will be backwards compatible to 3.3 and therefore only be able to
> introduce certain types of changes. 4.0 will not be backwards compatible
> and therefore offer us the opportunity to make some structural and
(Continue reading)

Permalink | Reply |
headers
Robin Wendler | 11 Mar 2009 19:09
Picon

Re: Addition of new type value "reviewOf" for relatedItem

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
(Continue reading)

Permalink | Reply |
headers
Diane I. Hillmann | 11 Mar 2009 19:44
Picon
Favicon

Re: Addition of new type value "reviewOf" for relatedItem

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
>
(Continue reading)

Permalink | Reply |

Gmane