Print

Print


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.