Named Entities
A named entity is the normalised form of a proper name: the editorial decision
that the tokens a-ḫi-i, a-ḫi-ú and a-ḫe-e all spell one and the same name,
Aḫiu. It is a statement about writing and language, not about people — two
different men called Aḫiu share a single named entity.
This is the step that must come before any prosopographic work. Persons are matched to occurrences through the name forms already attached to them, so an un-normalised name has nothing to match against.
1. Browsing the register
The register lives at /onomastica/namedentities/ and is organised by class — personal
names (masculine and feminine together), divine, geographic, month names — each with its own
tab. Within a tab, an alphabet bar restricts the list to a single initial, and a filter form
narrows it further.
Each entry shows the normalised form, its class, and the number of attestations: the occurrences that have been assigned to it, counted within the texts your account may see.
Attested and unattested forms
By default the list shows only forms that have at least one attestation — which is what an onomasticon is for. A form you have just created therefore does not appear until an occurrence is attached to it.
Editorial accounts have a Show all (incl. unattested) toggle that adds the orphan entries, listed with a count of zero. It is how you find a form you created a moment ago, and how you spot entries left stranded by a later reassignment.
2. Attaching occurrences
Occurrences are attached to a name form in the Global lemmatizer, which presents the corpus one class at a time and assigns in bulk: you search a written form, the matching occurrences come back grouped across the whole corpus, you select those that spell the same name and assign the entry to all of them at once.
The procedure, the tabs and the include already lemmatized occurrences option are described there. Two points belong here, because they concern the register rather than the tool:
- the class of the token decides which tab a spelling appears in, and therefore which register can receive it. A personal name that was not marked as such in the transliteration will never reach the onomastic tabs — the fix is in Edit tablet, not here;
- the lemmatizer assigns, it does not create. If the form you need does not exist yet, create it as described in §3 and then return to the lemmatizer.
Named entities
3. Creating and editing a name form
Name forms live at /onomastica/namedentities/, browsable by class tab and by
initial letter. Creating or editing one requires editing rights on named entities.
Create/Edit form
The record holds:
| Field | Notes |
|---|---|
| Form | The normalised form, with diacritics (Aḫiu) |
| Form (ASCII) | Auto-filled from the form; used for accent-insensitive search |
| Class | PN, PNF, DN, GN, MN — determines which tokens may carry it |
| Gender, Language | Akkadian, Hurrian, West Semitic, Sumerian, Hittite, mixed, unknown |
| Name type | theophoric, hypocoristic, profession, descriptive, kinship, unknown |
| Theophoric element, Meaning, Notes | Free fields |
The class cannot be chosen freely against the evidence: a form classified GN
will never be offered for a token marked PN. The two pools are kept apart on
purpose, so that a personal name and a homophonous place name never contaminate each
other.
4. Duplicate detection — a warning, never a block
As you type the form, DAPCA looks for existing entities that resemble it and lists them live, each with the written forms actually attested for it. If you submit anyway, a second check re-displays the form with a warning panel and a Create/Save anyway button.
Neither guard blocks you, and that is deliberate. Variants are legitimate: the same name really can be entered twice under slightly different normalisations, and sometimes it should be, when the difference is meaningful. The guard exists so you notice, not so you obey.
Matching respects the class pools: personal names (PN/PNF) are compared against each other, while DN, GN and MN are each compared only within their own class. A personal name and an identically written geographic name will therefore never be flagged as duplicates of one another.
When two forms are genuinely related, do not merge them — link them, using the relations on the entity page:
| Relation | Use for |
|---|---|
variant |
Two spellings of the same name |
hypocoristic |
A short or pet form |
same_as |
Asserted identity of form |
uncertain_eq |
Equivalence you suspect but cannot prove |
These links matter downstream: the candidate occurrences proposed on a person's page are drawn from the linked name forms as well as the direct ones, so a well-linked variant widens the net automatically.
Duplicates
5. Finding an entity that "disappeared"
The browse list shows attested entities only — those with at least one occurrence attached. A form you have just created, or one whose occurrences were later detached, has no attestations and is therefore absent from the list.
Tick Show all (incl. unattested) to include them; they appear with an occurrence count of 0. The toggle is available to Advanced users and Administrators.
Unkinked entities
6. Deleting
Deleting a named entity detaches its occurrences: the tokens themselves are kept and simply become un-normalised again, returning to the appropriate Lemmatizer tab for reassignment. Relations to other name forms are removed along with the entity. Nothing in the text is lost.