On Nov 20, 2005, at 5:43 PM, David Wilson wrote:
On first glance, you are telling me that we must force users to assign
each citation to a group (if they need this sort of formatting at
least), and therefore the internal coding must be able to store this
(it cannot yet in the OD proposal).
The group belongs to the Cited work not per citation of the work.
So the grouping would be stored with the bibliographic detail file in
the save
files, not in the citation field inserted in the document.
That makes sense. How would the GUI work? Martha, you there? Any
thoughts?
I'm here -- and been quietly reading everything that comes across the
dev and user lists to see when I could be helpful. ;-) So if I have
not spoken up on an issue and someone wants UI feedback, please let me
know like David did this time.
First, it seems to me that this is the same issue we have been
discussing in terms of grouping the bibliographic entries in a document
as different types of reference lists (e.g., General Bibliography, Works
Cited, Recommended Readings). The question is whether we would need to
be able to nest groups within groups--for example, the "Works Cited"
group might include one subgroup as "Primary Sources" and another
subgroup as "Secondary Sources". Unless I am missing something (which
is quite possible), the GUI would allow the user to identify the
reference groups for a document and the entries that go within each
group. Somehow the engine would be able to keep track of that, but the
larger programming question is whether the knowledge of groups are
restricted to a document or becomes part of the bibliographic
item--i.e., which is the fundamental object and what points to what?
The primary UI tradeoff issue is user control versus automation.
Because we do not yet know all of the issues and how people might use
the functionality, I am strongly for an emphasis on user
control--automation that does something other than what the user wants
is a diabolical form of torture, especially when it cannot be overridden
or, worse, when it can be overridden but the overrides are not stored.
If the group knowledge is constrained to the document because the
document is fundamental, then group names such as "Recommended Readings"
or "Works Cited" could be stored as heading text with the other
bibliographic data for the document. The user could type in other group
names (e.g., "Primary Sources" and "Secondary Sources") and insert the
bibliographic entry under that heading--the point of insertion would be
identified by the location of the text cursor. This approach gives the
user the greatest control in that the entire "Bibliographic Section" of
the document could be stored as a whole and changed at will by the user
without being constrained to 'messing with' the bibliographic database.
It would also solve another problem if a user wanted to change or
annotate an entry just for one document.
On the other hand, if the focus is on automation rather than user
control, the knowledge of groups would be associated with the
bibliographic item as fundamental. Every item in the database would
have to know every group that had ever included it, and the groups used
for all other documents, and allow for the entry of new groups. In this
GUI, the user would select a database item and changing its group
heading from the generic default would be among the advanced decisions
to be made for an inclusion. The basic option would be the default.
The system automatically would put the entry in the appropriate sequence
under the group and the position of the text cursor would be
irrelevant. If the group did not already exist in the document (i.e.,
that had been a previous inclusion under that group name), then the
system would automatically add the new group to the document. This is
where the nested issue becomes dominant--what if the new group is
"Secondary Sources" under the higher-level "Works Cited" group -- how
would the system know how to order the subgroup sequence?
Also, this is a perfect example of how developer terminology often
migrates to the UI without consideration of the underlying assumptions
from the users' perspective. Is "group" actually the best word for the
name of a type of reference list? Or would "Reference List" be a better
term as it contains within it the definition of what it is? Consider
the following user statements:
1. "I want to add a new group to the document." [note that this
statement carries no intrinsic information about what is being added]
2. "I want to add a new reference list to the document."
Or perhaps there are even better alternatives for this user concept that
I have not yet identified.
I know as a user that I'd rather
not have to do that, so perhaps we can figure out some other way. Am
not sure how, mind you!
Easy, have a default group. For people who do not need sorting this
can be a
Default (no heading) group. For most of my History papers 80-90% of
the cited
works were Secondary (so that would the default for me) Then, either
when
adding cited works or latter when finishing the paper assign the few
Primary
sources.
FWIW, here's an example of how the latex/bibtex multibib package works:
\usepackage{multibib}
\newcites{bk,art}%
{References from books,%
References from articles}
\bibliographystylebk{alpha}
\bibliographystyleart{plain}
...
\citebk[pp.~23--25]{milne:pooh-corner}
...
\citeart{einstein:1905}
...
\bibliographybk{book-bib}
\bibliographyart{art-bib}
Bruce
Also, one comment about date formatting (see email below). The data
formatting in the document must be different from the format defined by
the document when the document format is determined by location or other
factors (e.g., US versus Europe versus military), but the bibliographic
entry data format is determined by a particular style (e.g., MLA versus
APA). Sorry -- do not have a URL, only this example from my own knowledge.
We all know that bib styles define date formatting. But can we say
that such date formatting is in fact defined by the document format?
Put differently, is it ever the case that a document style mandates
that dates are formatted one way (let's say "January 12, 2002"), but
its bibliographic entries formatted another (say abbreviated; "Jan.
12, 2002")? If yes, please provide urls. This is an important
question if I want to consider integrating CSL logic into OD (and I
do!), as OD already has support for general
date-internalization/configuration. Would be nice to be able to leave
that out of bib styling.
Regards,
Martha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
