While I think the first option (the one you and John prefer) might well be the pragmatic one that reflects the way this software has often worked, I don’t really think it precisely models what’s going on. I’m sorry, but a “see also” reference is semantically different than a generic citation. And the strings “see also” and “cf.” are just conventions to express that.

But I’m not attached enough to that position to think it important to argue about. So long as John and others can program the software so the stuff works, that’s the primary goal.

I agree with John that your first model seems nice and clean.

I think in your model that is a citation that contains three references, but at output the software notices that the first one and the second one share the same name, and the name doesn’t need to be output twice.

What is output on screen doesn’t need to exactly match your model–it just needs to be modeled by it! I think you want to keep your model clean, and to some extent actually mapping the concepts involved. Which, for that citation, are to me, a citation with three references. The second just happens to be the same author as the first, which means that APA style (or whatever) says not to write the same name twice.

The model should be seperate from the output according to a given style–it just needs to be able to model it!

Yes, that’s my proposal, with one clarification or amendment: I believe references are an ordered, not unordered list, and that the order is determined by the user. If a style forces sorting by date, the user’s order will get overridden, but if the style is neutral on the subject, the user’s order prevails. So the data model stores the user’s order, not the order as presented.

Are we safe saying that common prefixes ALWAYS indicate in effect a group?

I think: Only if they are contiguous in the user’s order.

I earlier said references should be sorted and grouped. In fact, I think it should be first sorted by user order, then grouped by prefix, then sorted and grouped as the CSL defines.

Assume the user enters (in this order)

         Miller 1990

see also Doe 1999 contra Smith 2000 see also Jones 2002 see also Jones 2001 see also Anderson 2004

If the CSL does not demand grouping or sorting, then references get presented in the user’s order, with the prefixes grouped. This case would also be common with note-based styles.

(Miller 1990; see also Doe 1999; contra Smith 2000; see also Jones 2002, Jones 2001, Anderson 2004)

If the CSL demands references be grouped by name, listed alphabetically, and ordered newest to oldest:

(Miller 1990; see also Doe 1999; contra Smith 2000; see also Anderson 2004, Jones 2002, 2001)

I think that works. Yes?

By this algorithm if the user entered the following

         Miller 1990

see also Doe 1999 contra Smith 2000 see also Jones 2002 Jones 2001 Anderson 2004

he’d get, assuming the same CSL,

(Miller 1990; see also Doe 1999; contra Smith 2000; see also Jones 2002; Anderson 2004; Jones 2001).

Maybe that’s not what he wanted, but it is what he asked for, formatted as the style guide says. I don’t think we can presume that a reference without a prefix inherits the prefix of the previous. If that should be assumed or defaulted, it could be handled in the user interface.

I think uncited or notlisted is a different issue and is a property of a source, not of a citation. We should take that up on a separate thread.

I guess that would work. Are we safe saying that common prefixes ALWAYS indicate in effect a group?

Also, how to sort the groups?

Finally, what about my question about uncited and such? Did we conclude that tags achieve this? And if yes, then does that suggest as well a reference: - may have one more “group” tokens (notcited, notlisted, etc.)?

And if yes, then wouldn’t it be appropriate to define “see” and “seealso” as possible values? If not, how do we explain why?