On Feb 25, 2005, at 9:04 AM, [EMAIL PROTECTED] wrote:
Any chance we can somehow consolidate the GUI discussion in a single list?
Perhaps, but in the meantime, the easiest solution is to do a reply-all. We should try to maintain attribution in the quotes, though (because sometimes hard to reconstruct).
Comments and clarifications based on the comments so far:
First, let me clarify something: why the distinction between "reference" and "list of references"?
From my perspective, the latter would always be automatically generated, so why would I want to insert a single reference? It seems like it would make the GUI more complicated.
Some documents have two or more 'lists of references': (1) a general bibliography, such as "Recommended Readings," containing information items that are simply inserted in that list and not cited in the document, and (2) a 'works cited' (MLA term) list. By differentiating reference and list of references, OOoBib could handle multiple lists without additional work for the user because citations would automatically go into the 'works cited' list. A user would need to position the cursor in the Bibliography list and insert the references to be included there. Using a 'no cite' option would not work for the (1) type of list as the reference would still go into list (2).
I see what you mean now. There are two separate issues here:
1) reference grouping
Another example to the above is that I often see articles where you have a few different subdivisions in the reference list: for example, "newspaper articles," "legal documents" and then the references per se.
2) "no cite"
Could not they be consolidated? A "recommended reading" would thus be a citation with a local style of "no cite" which is grouped together under the heading of "Recommended Readings."
A reference list subsection for archival documents would just consist of standard citation referents, but grouped by genre/resource type.
??
c) If the doc contained only very selected fields or, in the extreme case, onlyThese are exactly the kinds of issues that MUST be resolved for me to do the GUI design. I do not know all the possible alternatives, and it is not appropriate for me to make the functionality decisions. So what shall OOoBib do for Version 1?
the formatted citations and no "raw" metadata at all, the receiver would not be
able to get any bibliographic data out of the document and wouldn't be able to
apply a new style either (since this might require some other data fields).
What is your opinion about c)? Should this be possible at all? Are there maybe
users that might not want their complete used metadata to be shared with the
document receivers? Are there alternatives?
The easiest solution if we go all XML is to have a complete MODS record that includes all the metadata. Annotations are then stored in separate files that are linked to their MODS referent(s).
A user may choose, when saving their document, something like the following checkbox options (let's be concrete):
Bibliography save options
include bibliographic source metadata __
include annotations:
public __
private __Now, if you don't include the metadata, then you risk the person on the other end not being able to reformat the document. That's a choice we can leave to the user, I think (or not, it's not really a big deal to just always embed).
Notes would have to be explicitly marked as public to be consider as such. Default would be private.
I still think abstracts should be considered part of the core metadata. If you download a reference from pretty much any online journal database, they include the abstracts. Why shouldn't we?
re: equations and such
But the GUI designer is one of those who does need this to seriously use OpenOffice. ;-)
Martha -- given your background in the library world, perhaps you ought to help me lobby the LoC on this :-)
I think the BibDB should contain ALL the information, and that there should be a default setting about what subset is included as the "travelling library" (to borrow an EndNote term) with the document. The travelling library contents should be able to be changed by the author of the document, and the travelling library ought to be able to be exported into a proper BibDB by the reader of the document.
All fine, except the part about "be able to be changed." I think that'd be difficult to manage.
So what shall OOoBib do for Version 1?
As above. When I express resistance to the notion of editing the embedded metadata, it's because I see this as unnecessary, and complicated. If we design the embedding options properly (including the option not to embed), then there shouldn't be any problems.
This is why I originally thought that there would be only one BibDB with subsets ("Collections") that could be searched and managed separately. If I could import my 'book collector' list of the books I own into a BibDB with the genre folders as subsets, then I could have my ~2000 books already categorized in BibDB and ready to use for reference. That does not even count the articles in various fields that would also need to go into my BibDB. To me, having Collections within BibDB, or even Collections within Libraries within BibDB, is necessary so that I can browse relevant topics without having to limit myself to search results or to be overwhelmed by having to browse 2000+ items. The key distinction is among search, browse and obtain -- research I did at OCLC indicates that all three are critical functionality, particularly for advanced users.
Can't the "collections" just be virtual; e.g. a named query?
Bruce
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
