This page explains how to configure the functionality and appearance of your Oracc project.
Files | Lists | Proxies | Updating | 00lib/config.xml | Editable components | Related pages
Oracc project configuration is handled by several files:
The project configuration is handled by an XML project definition file called 00lib/config.xml. This is the file you are most likely to need to edit. We give more detailed instructions below.
The colours of your project website are given in the file 00lib/p3colours.txt, as described on a separate page.
If your corpus borrows ("proxies") ATF files from another project, their P, Q or X-numbers are listed in 00lib/proxy.lst, described further below.
In principle, several corpus configuration issues are dealt with by
the XML Text Corpus (XTC) definition file 00lib/corpus.xtc. In practice, the default
never needs editing, so we will say nothing more about it here.
Several lists of ID-numbers provide control over what is included in the project and what is displayed.
The two important lists are 00lib/approved.lst and
00lib/outlined.lst. The first gives all the texts which
are considered part of the project. The second gives the texts which
are displayed by the pager. Whether or not the pager actually uses
00lib/outlined.lst is controlled by the pager
option pager-outlined-lst in 00lib/config.xml, as described build [http://oracc.museum.upenn.edu/configdoc/build.html] page.
The other two lists
(00lib/new.lst and 00lib/rejected.lst) are
presently irrelevant as they are intended to support dynamic tracking
of new additions to the CDLI catalogue in a manner that is not yet
implemented.
Secondary lists influence the build process if any kind of dynamic editing is being done by the system. They are:
approved.lstapproved.lstSimilar lists influence the creation of outlined.lst:
not-outlined.lst and add-outlined.lst
contain numbers to be excluded or included in the generated
outlined.lst respectively.
Finally, if you want to borrow ("proxy") ATF files from another corpus, you should make a file 00lib/proxy.lst, that lists the P, Q or X-number of each proxied text, one to each line. Precede each text-id with the relevant project abbreviation and a colon; if you want to borrow the other project's catalogue data, follow the text-id with an @-sign and the project name. If you don't include an @-statement, the CDLI catalogue data will be used.
For instance:
dccmt:P345916@dccmt dccmt:P347486@dccmt cams/gkab:P348765@dccmt cams/gkab:P348767@dccmt
In this example the first two texts are proxied from DCCMT [http://oracc.museum.upenn.edu/dccmt/] and the second from the CAMS subcorpus GKAB [http://oracc.museum.upenn.edu/cams/gkab/]. However, all four take catalogue data from DCCMT.
You can use proxy lists to make corpora or subcorpora entirely of proxied texts (e.g., DCCMT/Paper11 [dccmt/paper11], a collection of texts for an undergraduate course). If you do this, set the (sub)project's catalogue-build-policy option [http://oracc.museum.upenn.edu/configdoc/build.html] to "virtual" to generate a glossary.
When you have edited the file 00lib/config.xml as described below, use the oracc command to
update the web version of the configuration file:
oracc config
The configuration file 00lib/config.xml ("the config
file") is the one which projects will modify most. It is an XML file
with a simple syntax and simple tags, the most important of which are
described here.
Config files are generated automatically when a project is first created. Let's start by looking at a typical config file (this one has been simplified a little for clarity):
<project n="dcclt"> <name>Digital Corpus of Cuneiform Lexical Texts</name> <abbrev>DCCLT</abbrev> <logo type="text">dcclt</logo> <url/> <type>corpus</type> <public>yes</public> <blurb>Editions and translations of lexical texts (word lists and sign lists) from all periods of cuneiform writing <br/> Project directed by Niek Veldhuis at UC Berkeley and supported by the <a href="http://www.neh.gov">National Endowment for the Humanities</a>.</blurb> <image>P000120.png</image> <image-alt>Drawing of a list of vessels from Archaic Uruk, circa 3500 BCE</image-alt> <option name="build-approved-policy" value="mixed"/> <option name="build-outlined-policy" value="Q"/> <option name="catalog-build-policy" value="auto"/> <option name="cbd-mode" value="mixed"/> <option name="%sux" value=". epsd2 dcclt/nineveh"/> <option name="%akk" value="."/> <option name="pager-back-button" value="DCCLT Portal"/> <option name="pager-back-url" value="http://oracc.museum.upenn.edu/dcclt"/> <option name="outline-default-select" value="true"/> <option name="outline-default-sort-fields" value="period,genre,provenience"/> <option name="outline-default-sort-labels" value="Time,Genre,Place"/> <option name="outline-special-select" value="true"/> <option name="outline-special-list-name" value="outlined.lst"/> <option name="outline-special-sort-fields" value="period,subgenre"/> <option name="outline-special-heading-template" value="1 2"/> <option name="outline-special-catalog-fields" value="designation,subgenre,keywords"/> <option name="outline-special-catalog-widths" value="30,25,41"/> </project>
The words following the angle bracket, <, we call
`tags'. The words before an equals sign followed by a quoted string
we call `attributes'. These are the building blocks of XML. XML
files are always balanced: tags may contain tags, but the closing tags
must always match at the same level of containment.
Certain elements of the config file should not be edited: the opening and closing tags must be `project', and the `xmlns' code in the first line should never be changed. The project name and abbreviations at the start of the file are generally set up when the project is created, and also should not be changed (because they are used by the Oracc software to work with the project's files--changing an abbreviation will result in files not being found).
Several components of the config file may be edited by projects, however.
Some are required for all projects. They are described on the page of core [http://oracc.museum.upenn.edu/configdoc/core.html] config elements.
Then there are a large number of configuration options. In order to ensure some kind of systematization in the options we categorize them into groups. Each one begins with its own prefix and has its own page of documentation:
In the configuration file 00lib/config.xml an option is
declared using the following XML syntax:
<option name="NAME" value="VALUE"/>
For example, to set the build-approved-policy option
described below to the value atf you would write:
<option name="build-approved-policy" value="atf"/>
The options must be given within an <options>
block. If your 00lib/config.xml doesn't have such a block
yet, you will need to say:
<options> <option name="build-approved-policy" value="atf"/> </options>
We are currently developing a web interface for project configuration, which will mean that you no longer have to edit config files by hand. However, the options available will remain the same.
More documentation on project configuration can be found here:
Eleanor Robson & Steve Tinney
Eleanor Robson & Steve Tinney, 'Project Configuration', Oracc: The Open Richly Annotated Cuneiform Corpus, Oracc, 2019 [http://oracc.museum.upenn.edu/doc/help/managingprojects/configuration/]
Released under a Creative Commons Attribution Share-Alike license 3.0, 2014.
[http://www.facebook.com/opencuneiform]
[http://oracc.blogspot.com]
[http://www.twitter.com/oracctivity]
Oracc uses cookies only to collect Google Analytics data. Read more here; see the stats here [http://www.seethestats.com/site/oracc.museum.upenn.edu]; opt out here.