You, today's cataloguer/inputter, will profit from mistakes of the past of DS.  For example, we originally had many more required fields than we do now.  However, DS eventually learned that you can't proscribe complex cataloguing rules if you intend to get the viable material out there to the public asap (we learned this lesson by noticing the very large number of fields populated by "attractive garbage" whose sole function was to bypass the computer's demand for a certain piece of information).

Experience also taught us that we need to bow to the machine on some occasions.  An ordered sort on the roman numerals of dates in paleographic convention isn't in the cards:  "s. XV exeunte" will inevitably fall before "s. XV ineunte"; a search for all manuscripts copied between s. IX and s. XI sounds reasonable to a human but is risible to a computer.  You'll appreciate our clever work-around, whereby the computer translates the paleographer's dating to arabic numerals via the Darling Feature:  "s. XV ineunte" automatically expands to a BeginDate of 1400 and an EndDate of 1415.

In the end, however, it's what you, the cataloguer/inputter does that will make DS run smoothly. Here are a few comments on inputting; they constitute a form of Best Practice not for the database's sake, but for the sake of the data itself and the humans who will read it.

1.  Just because a field exists doesn't mean that you're obliged to fill it.  This is not Mt. Everest and you are not Sir Edmund Hillary.  In fact, if you aren't reasonably certain about the authenticity of your source and/or about the level of your own qualifications, it may be just as well to leave a non-required field blank.  (Hint:  "Incipit" is a field where we have noticed many an embarrassment.)

2.  Overall, the descriptions in DS-Access are short, and people's memories are long.  You don't need to duplicate information from one level to the next, or from one field to the next; for example a GenericTitle field infilled with "Bible" is ample, since there is a Language field where one may more appropriately insert "Latin" rendering "Bible. Latin" superfluous.

3.  Children inherit the characteristics of their parents, so that a statement made about a manuscript at the topmost level (Manuscript) is also true of contents at the Image level, and everywhere in between.  The economy of this is that one should push a statement as far up the genealogy as possible, to avoid having to repeat it at every instance lower in the genealogical tree.  "We thank Prof. Pinco Pallino for his notes on this manuscript" is better placed in Acknowledgments at the top, than in that field for each and every Text two generations later (unless, of course, his notes pertained only to certain Texts).

4.  Remember that certain very important fields (none of which is required by the database) are represented on the DS website by Browse Lists, so when inputting in these fields, phrase the entry in an alphabetizeable, indexable manner, while retaining read-order for proper names.  The web-browseable fields are:

• Author
• Title
• Scribe
• Artist

Ergo, enter "Roman de la Rose" but not "The Roman de la Rose"; and enter "Master of the Gold Scrolls, workshop of" but not "Workshop of the Master of the Gold Scrolls"; but do say "Simon Bening" not "Bening, Simon."  The Data Dictionary expatiates on this.

5.  While entering captions for images, bear in mind the two main functions of the caption:  it will be used in-house by the photographer and by the Q.C. people (most likely you) to verify that the correct image is being/was done; it will be used as a field-defined search bed for keywords by DS readers.  Thus a phrase such as "Red paragraph marks" isn't helpful because such paragraph marks probably occur throughout the manuscript and in many manuscripts:  the caption doesn't identify anything salient in that image (so such a caption doesn't help the photographer).  Another example:  to say that a manuscript employs "colors" in a border decoration is wasted effort, since the user is unlikely to search on the term "color" and once he has the image in front of his eyes, he can tell that it has "colors."  "Gold" on the other hand might be a term people would search on because it immediately ratchets the manuscript up a notch in terms of expense (a shorthand term for "high quality"?).

6.  DS is counting on very short records (have we already said that?) and has accordingly placed limits on field size.  Concretely and until very recently, this seems to have had the greatest effect on the field for Provenance:  so squeeze in laconic telegraphic info (not "information"; it's "info"; we're making a point).  Skip explanatory words, e.g. "Sold at Christie's" when "Christie's" alone is clear.  Take advantage of implied chronological order, e.g. "Donated to the Houghton Library by Philip Hofer" is covered by the fact that "Philip Hofer, donor" is the last name in the Provenance field in a Houghton record.  While Provenance has now been expanded to Memo field length (for which see the Data Dictionary), as have a few other fields, don't take this as license for verbosity. That's not the goal.

7.  Punctuation is a headache; humans and computers don't see it in the same way.  Thus, if you can avoid using it, that's good.  Please eschew especially the final period on something that doesn't even begin to look like a sentence, e.g. in the field for languages:  Latin. (like that, with a period); we don't want it; people don't perform searches on "Latin." (like that, with a period), do they?  If you prefer the more polished look of prose finishing up with a period, save it for the end of the Provenance field, or the end of the Decoration field, or Notes, or Acknowledgments (yes, good, in Acknowledgments). 

Semicolons, that's another one.  Please do use a semicolon followed by a space as a delimiter:  Latin; French (when a manuscript has two languages).  DS Central can teach computers to recognize "separate" entries this way.

8.  Capitalization on the other hand is indifferent on the computer's terms but matters to the humans.  Fields that open with lower case letters look unfinished, informal, too casual, even sloppy to humans.  Begin fields with upper case letters, except, that is, for the ubiquitous "ff." (or its equivalent, "pp." if your manuscript is paginated); the combination "Ff." (or "Pp.") looks very odd.

9.  Are you wondering where to position some piece of information in the database?  Go look it up on the online DS!  Chances are that someone else has already encountered this sort of issue, and the ease (or difficulty) you have in retrieving that information online will suggest how successful or pitiful the previous inputting strategy may have been.

10.  No matter what, do not change the database:  add no fields, change no properties.  Remember that this is a consortial project and success depends upon all of us collecting data in the same way.  DS-Central has locked down the front end (i.e. the schema, the application, the file named dsdbms) to make such changes all but impossible, and that's the reason why; Bitter Experience speaks.  If you truly need something different, get in touch with DS-Central and we'll see what can be done to help you (or to talk you out of it).