# Digital Transformation of the Elymological Dictionary of Geographical Names
## 4 Discussion
However, the SENSG dataset includes their URIs. Proper generation and maintenance of these URIs is crucial. In both solutions (AZON and SENSG), all entities have numerical identifiers generated by relational databases. These identifiers appear in the URIs of triples in the graph databases. The relational and graph databases are synchronized. Forms \"attached\" to the relational database allow the CRUD (create, read, update, and delete) operation, but every \"save\" action also triggers updates to the graph database. However, to update a triple, it must be removed and then re-inserted into the graph with its property values changed (property values in the graph database are not editable, unlike attributes in the relational database, and the concepts of \"identifier\" or \"primary key\" are not working). So, for consistency, both the delete and insert operations must be performed with the same triple URI, which is a bit complicated. Matured graph databases offer SPARQL endpoints by default. However the implementation of URI dereferencing (through the content negotiation) had to be done separately. Additionally, due to security reasons, all the endpoints should be protected from DDoS (distributed denial of service) attacks. However, these technical details are out of the scope of this manuscript. Regarding the preparation of data for SENSG, there are many issues related to it: inconsistent use of abbreviations in all 17 volumes, mistakes in historical resource citations (which are the essential source of information for historians and other researchers), changes in the administrative division, and the like. Thus, all the data published on a prototype portal ([[https://sensg.e-science.pl/](https://sensg.e-science.pl/)]([https://sensg.e-science.pl/](https://sensg.e-science.pl/))) need further corrections. As long as the core data are not shaped well to their final form, the persistent and final URIs cannot be offered. Thus, the SENSG prototype, at the moment, does not deliver pure semantic data nor an SPARQL endpoint. The big problem with the integration of different data sources is the correct understanding of what the original resource and its derivatives are. In the case of SENSG, the prepared dataset is intended to be treated as reference data. The published URIs should be used in the Linked Open Data world as \"original\"--the information collected was checked and verified by historians (the cited documents, maps, registers, etc. are sometimes a hundred years old, and their importance is out of the question). Of course, making the references to the other sources of geographical information, such as Geonames, is perfectly right, but the original references are much more significant than those derived. SENSG is intended to deliver such references. In that sense, it plays the role of a primary source of data. However, SENSG refers to old documents. If such documents were scanned and published in some digital libraries or archives, SENSG might deliver links to them via metadata deposited in AZON (in that case, it will play a role of a secondary source of data). Work is currently underway to obtain these documents from publicly available sources. The information model of SENSG includes attributes designed to store geographic location. As the original dictionary does not provide this (there are no geographic coordinates in the printed volumes), the current dataset misses these values. An attempt to discover such georeferenced locations automatically from the official sources (national registries) as well as unofficial ones (Gemet, TGN, Wikipedia) did not succeed, as many of the toponyms could not be found anywhere. It was clear from the beginning that entries discovered in the old archives or that were reconstructed do not exist in these sources. Interestingly, Wikipedia.de ensured the most successful search (local communities are much more interested in promoting their history than big organizations). Another thing that matters is the already-discussed accuracy of the georeferences found.