|
Description
|
| |
|
|
URL Table |
Holding tank for submitted URLs |
|
URL_seq |
Primary key |
|
STATUS |
Either draft or pending or confirmed;
draft records need only a URL to be "complete"; pending records need to
have all fields filled in. |
|
URL_POINTER |
The unique address of the resource. Typically it will
take the form of http:// but it could also be an ftp site or a gopher site,
or others as they arise. |
|
URL TITLE |
The title that you would like to appear in a listing for
resources. |
|
URL TYPE |
A growing list of types appears as a menu item. |
|
ANNOTATION |
Text that describes the contents of the resource and helps
the reader anticipate what will be within. |
|
KEYWORDS |
A growing list of keywords to be applied to the resource.
These are more free-form in their intention, following a formal system
(a la LOC) than the idiosyncrasies of the particular discipline. |
|
DISCIPLINE |
A growing list of disciplines for which the resource is
relevant. |
|
SUBJECT/TOPIC |
A growing list of subjects to be applied to the resource.
The librarians in the group will both add subjects to the list, and monitor
the use of subjects by faculty cataloging (in the loose sense of the word)
resources. |
|
ORIGIN_OF_SITE |
The name of the person or organization responsible for
the creation, compilation, and/or maintenance of the resource. |
|
SUBMITTED_BY |
The name of the person submitting the site (will be a
menu that includes your names; later versions will remember who you are
so that you needn't continually fill this in.) |
|
MODIFIED_BY |
Last person to modify record |
|
DATE_SUBMITTED |
Autoenter by system |
|
DATE_MODIFIED |
Autoenter by system |
|
REASON_FOR_SUBMISSION |
More evaluative than an annotation, this field is used
to capture the reason or reasons that the submitter felt that this resource
merits inclusion. a good space for noting if a URL is being submitted as
a good example of a bad site. |
|
APPROVED |
Y (for yes) or N (for No) and provide the reason for approval
or rejection |
|
REASON_FOR_APPROVAL |
Reviewer must provide reason for approving the submitted
URL |
|
REASON_FOR_REJECTION |
Reviewer must provide reason for rejecting the submitted
URL |
|
REVIEWED_BY |
Email address? Or system userid |
|
DATE_REVIEWED |
Autoenter by system |
| |
|
|
Subject Table |
Store subjects defined by CURL committee |
|
SUBJECT_SEQ |
Auto enter by system |
|
SUBJECT_HEADING |
A growing list of subjects to be applied to the resource.
The librarians in the group will both add subjects to the list, and monitor
the use of subjects by faculty cataloging (in the loose sense of the word)
resources. At this point the subjects for all will be intermingled. Later
releases should be able to subset the subjects so that catalogers working
in history, for example, need not see the geology subjects, and vice versa.
if someone on the list would like to take a pass at summarizing what the
final decision was on the distinction between subjects and keywords, that
would be helpful, since I am still somewhat unclear on this, and worry
that without some further distinction being drawn in advance, we will end
up with a big mess to clean up. |
|
CREATED_BY |
The name of the person submitting the subject |
|
DATE_CREATED |
Autoenter by system |
| |
|
|
Discipline Table |
Store disciplines defined by CuRL committee |
|
DISCIPLINE_SEQ |
Auto enter by system |
|
DISCIPLINE_DESC |
A growing list of disciplines for which the resource is
relevant. At this point, we propose to allow the faculty to begin the work
of constructing the list of disciplines as they see fit, and then see what
the list looks like after a few days/weeks of work. |
| |
|
|
URL_Type Table |
Stored url_types defined by CuRL committee |
|
URL_TYPE_SEQ |
Auto enter by system |
|
URL_TYPE_DESC |
A growing list of types appears as a menu item. To add
a url type to the list, first use the url type screen to add the url, then
hit the back button to continue the work of cataloging the resource. |
| |
|
|
User Table |
Register CURL contributors and obtain
minimal user info. This will help in defining user access levels. |
|
LAST_NAME |
User's last name |
|
FIRST_NAME |
User's first name |
|
MIDDLE_NAME |
User's middle name |
|
EMAIL |
User's email full email address |
|
ROLE |
User access to the CURL system |
|
INSTITUTION |
User's affiliation |
|
USERNAME |
User's Logon ID |