Suggestions for an design approach to the OpenOffice Bibliographic Data Entry / Edit GUI Interface Panels.
By David Wilson
Version 1.0 30/8/2004
Objective
The design problem is to provide the bibliographic user with bibliographic entry GUI interface panels
with a simple and familiar design that would look would look (initially) like Endnotes etc. That is they would not be confronted with new concepts or data items on the first simple panel. If the user has very simple requirement - A high school essay with 15 simple citations they would not need to deal with anything different. However, we need to next design 'Advanced Options' panels which would provide the user with the richer set of MODS Options as well. These could be set as the default input when the user became familiar with the concepts of resource type etc.
An example of sort of simple bibliographic data entry panel (Bibkeeper) is -
Instead of the 'Bibtex source' tab we could have an 'Advanced Options' Tab or Tabs. Which would include the special MODS attributes such as originInfo, location, relatedItem, 'type of resource', issuance, genre, extent unit (eg. Page) etc. It would also provide access to the more complex MODS name fields for Given and Family names.
Approach
The suggestion put forward here was inspired by some comments by Chris Putnam on his bibutils project. (see http://www.scripps.edu/~cdputnam/software/bibutils/mods_intro.html )
“The biggest problem for using MODS as an intermediate XML format for converting between different bibliographies may be one of scope. MODS appears to have been defined for people who want to extensively characterize their references, and it lacks a field with a simple 1:1 relationship to typical bibliographic reference types used in bibliography programs. Instead the information appears to be scattered across a number of different fields which have to be looked up to sort out what sort of reference type a particular reference is (which is the most basic sort of information programs like BibTeX and EndNote require).”
This set me thinking that the list of bibtext types to the various MODS fields is similar to that of dealing with the GUI interface as we need a form for each bibliographic 'record type' but, as Chris has pointed out above, there is no single user orientated record type descriptor in MODS.
I suggest we establish a table that defines user orientated record types. This table could include the standard bibliographic types books, articles, reports etc, as well as any the other possible collections eg laws legislation, Law acts, legal decisions, CDs, DVDs, coins, stamps, plants, prize bulls etc.
The MODS fields that define each record type would detailed in this table. (The example below is only an indicative and partial list). This table could be used to parse the MODS input to allocate the correct form for the record type or alternatively when opening a GUI form this table would provide the selection criteria by which the records of the entire set of collections where filtered for access by the form.
|
MODS attributes (partial list) |
|
|||
---|---|---|---|---|---|
Record Type |
Genre |
Resource |
Issuance |
Internet MediaType |
GUI form name |
bibliographic |
Periodical or 'academic journal', or book or thesis |
text |
|
|
bibliographic.frm (probably a table view) |
article |
Periodical or 'academic journal' |
text |
continuing |
|
article.frm |
book |
book |
text |
|
|
book.frm |
report |
|
text |
|
|
report.frm |
inbook |
book |
text |
|
|
inbook.frm |
inproceedings |
conference publication |
text |
|
|
inproceedings.frm |
thesis |
thesis |
text |
|
|
thesis.frm |
map |
map |
cartographic |
|
|
map.frm |
movie |
story |
moving image |
|
|
movie.frm |
web site |
web site |
|
|
text/html & image/jpg |
website.frm |
This table could be user extendible, so that the user could define their own special collections or set up subsets of existing collections. For example the user could divide a collection of movies records into English and foreign collections by specifying the English movie collection by adding the criteria
'language authority= eng'
and the foreign movie collection by adding the criteria
'language authority eng'
The user could modify or add their own forms.
The GUI field requirements could also be defined in a table, the information in the form should be sufficient to generate a form much like the way OOo database Form Wizard does. Alternatively, if we used Xforms, Xpath, Xupdate technologies for the GUI then the 'Field reference data' in the table would provided the necessary data to generate those statements.
For example for the article record type the GUI access form descriptor could contain the following types of fields.
Article |
||||||
---|---|---|---|---|---|---|
Screen Name |
MODS attribute |
Record type |
Mandatory / Optional / repeats |
Form order on screen |
Field length on screen |
Field reference data |
author |
AUTHOR |
PERSON |
M r |
1 |
255 |
|
title |
TITLE |
TITLE |
m |
2 |
255 |
|
journal |
TITLE |
TITLE |
m |
3 |
75 |
|
publisher |
PUBLISHER |
SIMPLE |
o |
4 |
75 |
|
address |
ADDRESS |
SIMPLE |
o |
5 |
255 |
|
year |
PARTYEAR |
SIMPLE |
m |
6 |
6 |
|
month |
PARTMONTH |
SIMPLE |
o |
7 |
10 |
|
day |
PARTDAY |
SIMPLE |
o |
8 |
10 |
|
volume |
VOLUME |
SIMPLE |
m |
9 |
10 |
|
pages |
PAGES |
PAGES |
o |
10 |
10 |
|
number |
NUMBER |
SIMPLE |
o |
11 |
10 |
|
issue |
ISSUE |
SIMPLE |
o |
12 |
10 |
|
issn |
ISSN |
SIMPLE |
o |
13 |
15 |
|
abstract |
ABSTRACT |
SIMPLE |
o |
14 |
200 |
Tables of this type would also would also be used to define the 'table view' for various classes of collections. For example a bibliographic table view would list all the bibliographic records grouped using the record types we have defined. The table would be sortable by author, title date etc. (see next page)
Bibliographic TableView |
|||||
---|---|---|---|---|---|
Screen Name |
MODS attribute |
Form order on screen |
Sort order |
Field width on screen |
Field reference data |
Author |
AUTHOR |
1 |
1 |
15 |
|
Title Of Work |
TITLE |
2 |
3 |
20 |
|
journal |
TITLE |
4 |
20 |
||
publisher |
PUBLISHER |
||||
address |
ADDRESS |
||||
Year |
PARTYEAR |
3 |
3 |
4 |
|
month |
PARTMONTH |
5 |
2 |
||
day |
PARTDAY |
||||
volume |
VOLUME |
9 |
5 |
||
pages |
PAGES |
1 |
5 |
||
number |
NUMBER |
6 |
4 |
||
issue |
ISSUE |
7 |
3 |
||
issn |
ISSN |
||||
abstract |
ABSTRACT |
||||
editor |
EDITOR |
||||
school |
ADDRESS |
||||
thesis |
THESISTYPE |
An example of a table view of bibliographic records.
Issues
Bruce D'Arcas suggested:
“But there needs to be an editing UI where someone could, if they wanted, easily define a simple type that took advantage of those extended options. Say you have an historian who deals with tons of archival docs. For them, archive and collection information is not "advanced"; it's pretty basic.”
Response: User defined or simple to construct data entry / edit panels would be ideal.