Summary: This site is intended to assist the genealogy community, both programmers and end users, with using Evidence Style source reference citations for historical sources by providing two parametrization styles for the templates described in the publications of Elizabeth Shown Mills. (references below). The schemes described here would also describe any source referencing style because its definition is under full control of the end user. The only requirement is that a software program provide a mark up "engine" to handle this simple architecture, which should be trivial to code from the parametrizations presented here.
It is important to note that to fully understand the use of the parametrizations presented here, one must have the book Evidence Explained (see reference below) at hand. The book explains historical evidence, offering extensive discussions of hundreds of record types (in addition to the QuickCheck Models), the quirks within them, the problems they present in using them, the essential data to capture for each, and the research practices that help ensure reliability in the conclusions reached from the evidence. In short, the book describes the art, this website only concerns the implementation of that art.
Table Version:
Template Version:
Professional genealogists know that the proper sourcing of data is the most important thing in genealogical research, more important than the computer program that is used to contain that data. Many of those that adopt Evidence Style as a standard reference style will only write citations in that style. Evidence Style sourcing is an art, not a science, and there often may not be a single "best" implementation of a given style.
Two ways to parametrize Evidence Style source references are presented above. The table version should be easy to adapt into genealogy programs. I would say it is the more "computer ready" of the two ways. The template version uses a Unix script style method to represent them. It was the first way I approached this and served as a "proof of concept". As I got deeper into the programming, I decided I would probably not reach a code version advanced enough for others to use. So I stepped back, and decided to recast the method into the table version which can easily be adopted by existing genealogical programs (if they don't already sufficiently handle Evidence Style).
The parametrization data in the table allows one to write a program algorithm that will uniquely produce Evidence Style format source citations. Either approach produces the same marked up results. (once all typos and mistranscriptions are out of the above tables). To see what the marked up QuickCheck models look like, see Evidence Explained.
This site can be a resource not only for end users, but also for genealogy software vendors wishing to adopt this style. So far, a handful of software vendors have coded in their own interpretations of Evidence Styles.
If a vendor's program can handle defining parameter and field definitions and types as described here, an end user can define these source types in their program, as they wish. They can extend an existing set, make modifications of exisiting ones, etc.
If the end user's program cannot handle these simple parameters and field definitions, or the template version, they are out of luck in using Evidence Style source references in their program. If you wish to use Evidence Style in one of those programs, I urge you to lobby your software vendor for the simple extensions needed to provide the necessary support. That could be as simple as pointing them to this web site. The small generalization required to handle this style can be implemented in any program without breaking anything that the program already does. It would simply allow a new degree of freedom to attract professional genealogists to use their software.
This parametrization should also help program vendors adapt to creating Bibliographies and First Reference, and Short Subsequent references in their reports if they don't already offer these highly desired features.
Note that although these parametrizations are specifically for Evidence Style, it allows the definition of ANY source reference style, from simply free format or comma separated fields only, to any style the end user cares to define. Program vendors simply need to generalize their source handling code to handle the parametrization presented here, and their program will suddenly be able to support any style, under any end user's control. A starter set of Evidence Style sources are found here.
As styles evolve, new ones added, old ones being tweaked, this site can make the latest styles available to all (end users and vendors). As via the Additional Styles links above.
To show how simple styles can be represented by this model, see the Additional Styles links for both types. There you will see how to represent the simplest style of all, free format, and the next simplest, comma separated only. Also shown is how to approach a "cascading" set of sources where one cites another that cites another, etc. It should be clear how to generalize that for one's specific needs. Indeed, these examples should show you how to create any style that you wish with these parametrization styles.
My ideal goal would be that software vendors adapt to a model where these styles can be shared by a standard for export/import of single styles, or in bulk.
I regard implementations such as these only temporary (as is any software). As software like zotero matures and embraces sharable open standards than can include Evidence Style in XML markup languages, software programs will be coded to represent sources (and more) in that manner, and this interim step will be obsolete. But for now, it will allow easy adoption of Evidence Style source referencing.
For example, the value for [RECORD TITLE] as found on page 95 of Evidence Explained can be defined as:
{\u201E}tat De La Force Actuel De La Comp{\super e} De La Mazillier destach{\u233e} Au Illinois
And the rtf will print as seen on page 95 of the book.
These text strings were passed unaltered to the rtf output, They are recognized as pass through text, not privacy fields, when they do not test true for all upper case characters.