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.

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.

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)

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.