# Digital Transformation of the Elymological Dictionary of Geographical Names
## 3 Model Design
### An Entity-Relationship Model
The meanings of the other columns are the same as in the concrete_toponym table. The source and destination of comparisons appearing in referring entries are collected in comparates table. In the original dictionary, every concrete toponym has a location that, according to the editorial rules, can be an administrative affiliation and/or descriptive information, depending on the object's nature. Due to the fact that an administrative affiliation can be structured, this part of the information was extracted to the separate administrative_affiliation table associated with concrete_toponyms through the administrative_affiliation_assign  
Figure 5: Entity-relationship model of SENSS. ments table (which includes attributes introduced to increase data certainty: former-- informing that the concrete toponym was known to have this administrative affiliation previously; verification--indicating verification status, which can be, for example: \"reconstructed but not verified in the official documents on administrative division\"). By assumption, the primary source of information on administrative affiliation was the original dictionary. There was no requirement to manage administrative division of the whole country. Thus, the administrative_affiliation table has the following columns:  
* administrative_affiliation_id--a primary key;
* affiliation_description--an attribute merging all parts of administrative affiliation into one string (potentially encoded with the use of markup language) for display on the user interface;
* commune, district, municipality, and voivodship--attributes used to represent names of administrative units at different levels of administrative division;
* year--an attribute indicating the year in which the administrative affiliation was valid (usually the year of the volume's publication). Other parts of information related to concrete toponyms are kept in the associated tables: object_characteristics and toponym_classes (both facilitate classification in Polish and English), as well as external_links (introduced to facilitate data linking). In the original dictionary, references to historical sources were interestingly handled. Their bibliographic metadata were introduced with abbreviations in the reference list. Then, the abbreviations, supplemented by the relative position of the quoted content, were placed inside the entries in the sections with historical materials related to the concrete toponyms. This approach was reflected in the historical_resources table, but with one significant extension. The bibliographic metadata of the historical sources and their electronic versions, subject to availability, have been deposited and published in AZON under unique URIs. This led to the design of the historical_resources table with the following columns:  
* historical_resource_id, concrete_toponym_id--primary and foreign keys;
* name--a historical name of a concrete toponym, often in a form presented in a historical source;
* language--the language of the source;
* historical_resource_number--a number representing a position in a chronological list;
* position_in_resource--a relative position of the quoted content (like page, sheet number, etc. );
* resource_ abbreviation--an abbreviation assigned to the historical source;
* uri--a link to the record of the historical source deposited and published in AZON (an extension);
* year--year of appearance. The maintenance of bibliographic data and implementation of digital repositories are a challenge. Delegating these tasks to the external system solved many potential problems.