Karen, you reasoning and examples is of great help. I'll discuss
this with the developers of our interrelated projects.
I understand that there's no such thing as "single truth", and I
appreciate any efforts to clarify best practices in the online
documentation.
Thanks, Matthias
On 11-Apr-07 at 17:39 -0700 Karen Coyle wrote:
> Matthias Steffens wrote:
> >
> >I see your point. However, I thought that the recommended way of
> >encoding total number of pages in MODS was:
> >
> > <extent unit="pages">
> > <total>402</total>
> > </extent>
> >
> OK, now I've gone back and looked at the documentation, and there isn't
> anything called "number" -- just start, end, total, list. Number is in
> the "detail" field, and to me, using "detail" here rather than "extent"
> doesn't make much sense. Detail appears to be for the enumeration of
> serials. Enumeration is different from extent. I could imagine "detail"
> being used for chapter number or names, but then you'd use extent to
> give the pages included in the chapter. I can't explain why that makes
> sense to me, but it does.
>
> Using "extent" would mean that an article on just one page has to be in
> "start"; "end" with the same number confirms it's only one page. "Start"
> with only one number really means the starting page. And I have seen
> citations that use the starting page and the number of pages (used
> mainly for ILL requests), so you could have:
>
> <extent unit="pages">
> <start>37</start>
> <total>5</total>
> </extent>
>
> This means that you could also do:
>
> <extent unit="pages">
> <start>37</start>
> <total>1</total>
> </extent>
>
> Rather than:
>
> <extent unit="pages">
> <start>37</start>
> <end>37</end>
> </extent>
>
> You could also have "start" alone because no other information was
> given, and you don't know how long it is or where it ends.
> >Please correct me if this is wrong. Thanks again,
> >
> > Matthias
> >
> You may have already guessed that there are only varying degrees of
> right in this activity. ;-) It *would* be great to clarify the best
> practices for some of these cases that we can predict. And there will
> always be the unpredictable exceptions.
|