Inconsistent use of the "pages" field

gerv

When capturing book information, the "Pages" field on the Info tab is sometimes filled in with the number of pages in the book (using the British Library, for example). However, when copying a citation in Chicago without bibliography format, this field is placed at the end of the citation, as the page range in question. These two uses are inconsistent.

FWIW, I think the field should be, if anything, the number of pages in the work. Copying a citation should not put any page reference information in; a work is often cited more than once, so a per-entry field for "page numbers of quotation" in the Zotero database doesn't make much sense.

Gerv

dstillman

Well, for certain item types, such as journal articles, the field is indeed populated with the page reference information. I'm not sure what the citation system should do, but I guess we at least need a separate metadata field for page range.

Ticket created.

bdarcus

This has bothered me too; "pages" cannot be both "number of pages" (which I frankly don't care about) and "page range" (essential for finding and citing articles and chapters and such).

noksagt

In addition to a page range & the total number of pages, a common thing stored in that field is the FIRST page number.

It'd be nice to differentiate from all three cases. You can't only rely on hyphens. Some articles are one page (so the range is identical to the first page). Some page "numbers" have a more complex syntax than just being an integer & so the hyphen might refer to the page number, rather than separating page numbers.

bdarcus

But if an article is one page, the first page is still not incorrect.

I guess you're noting that if you need to get the first page for some reason (like, say, legal case citation), you might have to deal with "1-5" or also with "1–5" (en-dash), or "1, 2, 3."

But is that really that hard a problem to solve?

I find the notion of having a page range and first page field quite odd and confusing.

noksagt

But if an article is one page, the first page is still not incorrect.

That's partly my point. Your statement is true, but how do you know that it is only one page? When given something that is not clearly an extent (such as "1299" (as opposed to "1299-1302"), you can read it as either:<extent unit="page">
<start>1299</start>
<end>1299</end>
</extent>or<extent unit="page">
<start>1299</start>
</extent>Perhaps I'm a bit anal about my metadata, but I want to know which is the case; do I know the full extent or not?

I find the notion of having a page range and first page field quite odd and confusing.

A first page is obviously PART of a range & I'm not suggesting three separate fields in the interface (for first page, range, and total number of pages). If anything, the interface for the page extent could resemble that of either the creator (choice of splitting the filed to clearly define the start and end pages of the extent vs. a freeform entry) and/or the date (hints to say how the field should be interpreted).

bdarcus

But does that really solve your problem? Say I enter in the split field the start, but not the end? It's just the GUI equivalent to your MODS example; I still don't know it's a single page.

I kind of gave up worrying about this one, given the variety of different kinds of page ranges, lists, etc. The RDF ontology just has a single "pages" property for that reason.

noksagt

I think it does actually help to reduce the problem. I use it in refbase & in other software that differentiates a start page and a last page. (I actually used to add one more level of granularity--to indicate that I knew that a citation was more than one page, but that I did not know the last page number (not all that uncommon, since some journals allow first pages only to nonsubscribers), but have stopped that myself).

Say I enter in the split field the start, but not the end? It's just the GUI equivalent to your MODS example; I still don't know it's a single page.

That's correct--the interface won't magically complete missing metadata for you. But it will reduce the number of records which incomplete metadata.

Right now, both one page articles & articles for which only starting pages are known are presented in the syntax you describe (the second MODS example).

But if you have the paper in front of you (or are working with an online database that differentiates a single page from a starting page), there'd be no reason not to enter the ending page field (the first MODS example).

I kind of gave up worrying about this one, given the variety of different kinds of page ranges, lists, etc. The RDF ontology just has a single "pages" property for that reason.

I guess you are no worse than bibtex in this regard. But with MODS & even RIS, one can tell the difference between an article that is definitely only a single page & articles that might or might not have more pages.

I'm not saying that RIS is the paragon to follow here (as you'd at least want to have multiple and/or interrupted extents, which RIS lacks).

I am saying that clearly differentiating start and end parts of an extent are useful semantically.

bdarcus

I'm not saying that RIS is the paragon to follow here (as you'd at least want to have multiple and/or interrupted extents, which RIS lacks).

I am saying that clearly differentiating start and end parts of an extent are useful semantically.

Sure, but you see the tension between the two; right? Any real world data representation has to support non-continuous page ranges. Once you do that, you have to explicitly model the individual page and page ranges within that, which adds a significant amount of heft to the data representation. Am not sure the added value is worth the added cost.

Hmm ... come to think of it, I think in the current version of the ontology we have both a single "pages" (for funky stuff) property and a pageStart and pageEnd. I guess that was our compromise ;-)