Okay, so my name is Michal, and I work for Dublin City University, which is one of the many universities in Dublin.
And most importantly, I work for a unit within the university called Fiontar there, Fiontar.
It's like an Irish-speaking mini university within this larger English-speaking university.
And I'm a software developer, which means that I worry about things like database design and data structures,
and that's what I'm going to be talking about today.
I'm going to be talking about data structures for recording data about place names and places.
Okay, and before I do that, let's have a little bit of context.
So I'm working on a project called the Place Names Database of Ireland.
It's, well, it's obviously a database of place names.
It's pretty large. It covers the whole island of Ireland, north and south.
It's got over 100,000 entries. It goes as far down a street level in some areas.
And it's been online since 2008, and it's quite popular.
It's been receiving approximately 150,000 searches every month.
We have a public-facing website, which people can use to search and browse.
I'll just show you a couple of screenshots. This is the homepage.
This is what it looks like if you're using our super-cool mapping interface where we're embedding Google Maps.
This is what it looks like if you switch from the map view to what we're calling the data view.
So this is just a single place name record and so on.
And this is my agenda for today.
So what I want to do is, as I've said, this website has been there for a long time.
And what I want to do today is I want to look back at some of the sort of data structural issues that have been coming up over the last couple of years.
And sort of look at them retrospectively and sort of critique and criticize my own work.
Because I feel that in our database and in a lot of other place names databases, in lots of different places around the world,
that perhaps the data structures that people use to record data are probably not the most suitable for that purpose.
So I'm going to be looking back at our own database, and I'm going to be sort of criticizing a lot of what I have done.
And I'm going to be telling you what I should have done and why I didn't do it.
So this would be a slightly different paper from other papers where people talk about stuff they have done well.
So I'm going to be talking about stuff that I did badly.
So the issues I'm going to have a look at can broadly be sort of grouped under two headings.
One cluster of issues is inherently kind of linguistic and is related to the fact that place names are linguistic expressions.
They belong in a language and they have linguistic properties just like other linguistic expressions do.
So that's items one and two on the agenda there.
And then items three and four are going to be a little bit more theoretical and I'm going to be asking the question,
what exactly is a place?
And is a place just a stretch of land which you can define with coordinates or is it something more than that?
But I'm going to start with the linguistic issues because those are a little easier.
So as I said, you know, place names are linguistic expressions just like any other linguistic expressions.
And place names databases differ in how much prominence or attention they give to the linguistic properties of place names.
And I think it's fair to say that in most cases place names databases give very little attention to the linguistic properties of place names.
Place names are very often treated as just as little pieces of text, little strings of text whose internal structure is not explicated
and whose linguistic properties are not explicated.
And this is pretty much how we have been doing it on our project as well with some exceptions.
But my argument is that it probably is a good idea to pay more attention to the linguistic properties of place names.
I divide them into sort of three broad subcategories.
Their internal structure, so place names have their own internal structure that they're made up of component parts.
They have certain combinatorial properties which determine how they can be integrated into text.
They have things like gender and number and inflection and so on.
And place names are also involved in lexical relations, relations to other place names,
relations to other expressions in the same language, in other languages and so on.
So I'm going to briefly review some of those.
I'm going to start with the middle ones, the combinatorial properties.
So you know place names, because they're linguistic expressions, then depending on the language you're in,
they can have number, gender and properties like that.
And these are often left unrecorded in place names databases,
but we have found it useful to actually explicate them in our database because people need to know these things.
It's just looking up something in a dictionary, you know.
So if you're looking up a place name in a place name database, you may want to know what gender it is and so on.
How it's supposed to be inflected and so on.
We do have some of this data in our database, but probably not enough.
And then there are some properties that place names have that are kind of additional to what linguistic expressions generally have.
A very interesting one is, in some languages, you have this...
Well, here I'm talking about the prepositions that you use with place names to indicate the idea that you're there, you're in this place.
In some languages, there is this duality between in and on.
Irish is one of those examples.
You know, most place names you say you're in them, but some place names you say you're on them, okay?
Irish is a language that does this.
I can think of similar examples in Slavic languages.
And this seems to be sort of partially semantically motivated.
For example, Anhara Rua, the second place name there, it's a peninsula.
So maybe that forces people to conceptualize being there as being on the peninsula.
But then again, there's a lot of other peninsulas where people use the preposition in.
So this is sort of arbitrary, and it's probably a good idea to record facts like these in a database of place names.
Another kind of interesting thing is how do place names combine with categorizing words such as county, town, city, and so on.
And mostly this is fairly regular based on the rules of the language you're in.
But sometimes there are funny exceptions in English as it is used in Ireland.
At least I'm not sure about other countries.
When people refer to counties, the pattern is county XYZ rather than XYZ county, as people would maybe say in other countries.
So basically my claim is that it is a good idea to encode these facts in a database of place names because your users might find it useful.
Okay. That was the sort of the combinatorial properties of place names.
Then if we look inside place names, again, most place names are either nouns or noun phrases.
And if they're noun phrases, then they may be composed of nouns and adjectives or maybe other nouns that modify the head noun.
There may be a definite article or not and so on.
You probably don't want to explicate all this in a place names database.
But there are other aspects to place names which maybe you do want to explicate.
One of them is what I call initialisms, which is various things that happen at the beginning of a place name such as definite articles and in Celtic languages also initial mutations.
And those are basically portions of text which you want to ignore for purposes of alphabetical sorting and various search functions and so on.
I mean, there's nothing unusual about this. I just wanted to mention that this is something that, you know, database designers need to worry about.
Incidentally, the way definite articles are combined with place names and other kinds of proper names as well tends to be a bit irregular.
For example, in the Irish language, a couple of place names display a strange type of behavior where they're used without a definite article in the nominative case.
But with the definite article in the genitive case.
And then a bunch of other place names sort of can kind of be both, you know.
So again, this is an interesting factoid about how a place name is used which users might want to expect to be able to find in a place names database.
And my argument is that we should be, when we're building place names databases, we should be paying more attention to these linguistic aspects of place names.
Another thing about the internal structure of place names is that some of them are composite names.
They're composed of what traditionally have been two separate places and two separate place names.
And then an administrative unit was created sort of taking into traditional units and the resulting place name looks a bit like this, you know, like a double barrel place name.
So you may want to encode this explicitly in your database for purposes of sorting and things like that.
Another example is sometimes place names have little bits at the end which I call disambiguators, words that sort of disambiguate exactly where you are.
You know, when a traditional place has been divided into two administrative units, then the new place name may have little disambiguators at the end like north, south, even AB and so on.
This happens in Ireland often when traditional units are subdivided into new administrative units.
So again, you want to explicate, you may want to sort of demarcate or markup or explicate in your database that these things are disambiguators.
They're not really part of the place name proper and you may want to maybe format them differently when you're displaying them on screen and maybe ignore them for searches and so on.
Okay, so that's about the internal properties of place names and then we've got, you know, place names are involved in lots of various lexical relations to other place names, to other words in the language.
For example, people may be interested in finding out what the word for a person from...
I can give them the slides later, yeah.
Yeah, so demonisms, you know, words for people from, so these are sometimes irregular.
So again, you may want to record these explicitly in a place name's database.
And then there's a phenomenon which I refer to as place name recycling, when one place is named after another place, very often happens with streets and town squares and places like that.
So when you have this happening, when this happens, you may want to know which particular place this place has been named after, you know.
For example, if you have a street called Lismore Park in some city somewhere and you know that this is named after a place called Lismore and there's a couple of places called Lismore in Ireland, so you may want to explicate which one this was named after.
And sometimes there may be ambiguity as well. I was looking at a couple of cases. There's a place called Ballymore Bridge in Countykill there, but there's no place called Ballymore in Countykill there or anywhere nearby, so there will be cases of ambiguity.
But it's an interesting problem to look at.
Okay, the second cluster of issues is related to the fact that place names are, that our database is bilingual.
And this doesn't seem like it should be a problem, because the basic principle is that every place has two names, one in Irish, one in English.
And because of this, you just need to text boxes, you know, for two separate names.
But that would sort of fail to account for a lot of interesting phenomena, such as borrowing, which is when, this is an example, it's an area of Dublin called Dunleider.
This is a place name which originated in Irish and it so happens that the same place name without any kind of change is used in English.
I mean, people pronounce it with a little bit of anglicized pronunciation, but other than that, it's the same name used in both languages.
So what we're doing is we just put in Dunleider as the English name, but that's kind of not satisfactory because it fails to tell you that this is not really an English name, it's just an Irish name which is only used in English.
And then at the other end of the spectrum, you have places in Irish speaking areas which have no known English names.
So what's happening there is if somebody is speaking in English and they want to refer to this place, what I imagine is happening is that they briefly cold switch and then utter the name in Irish and then switch back.
So again, you can either leave the English name blank or you can fill in the Irish name, pretending that this is also the English name, but that neither of those approaches is satisfactory.
You need data structure to indicate all the different conditions.
A lot of the English language place names in Ireland originated from Irish language place names by a process of anglicization, which is basically writing down an approximation of how the name is pronounced.
So again, if a name has this origin, you may want to say that explicitly in the database and then you could maybe get lots of interesting statistical information from that to see how often anglicization has been happening and which parts of the country has it been happening in most and so on.
And on the other hand, what often happens is that if a place name originated in English, then the process people use to get the Irish language name has been translation, like in this case, Butler's Bridge, rendered in Irish as Drogatan Votleric, it's the literal translation.
So when people translate place names, sometimes the translation is based on a misunderstanding or as I prefer to call it, a reinterpretation.
There is this example of an area of Dublin called Temple Bar, which is named after a person called Temple, but people reinterpreted that as the common noun temple and the Irish language name is Baran Temple, which is the bar of the temple.
So it's based on a misunderstanding, but because it's so common, it's been accepted as the official name.
So when things like these happen, it would be interesting to have the relationships explicated in a database so that you could analyze them statistically and do interesting stuff with them.
So that's kind of the end of the linguistic part.
I hope you're still with me because the second bit is going to be a bit more theoretical.
What I want to look at first here in the second bit is at the question of administrative hierarchies.
You know, most countries are subdivided into administrative units and subunits and subsubunits, things like districts and counties and prefectures and so on.
And these are usually deliberately designed to be nested hierarchies so that one unit is always wholly contained within another and each unit always only has one parent.
This is very easy to work with computationally because you can do automated reasoning and things like that.
But what's happening in Ireland, and I suppose a lot of other countries as well, is that we're actually dealing with overlapping hierarchies where units can have more than one parent.
This originated because the system in Ireland, which is basically the country subdivided into counties, then civil parishes, then baronies and then townlands.
And I suspect that originally the system was designed as a neat nesting hierarchy, but because of boundary changes that have not been propagated up and down the hierarchy, we have now ended up with an overlapping hierarchy.
So you can no longer do certain amounts of automated reasoning. So if you know that A is in B and B is in C1 and C2, you no longer know whether A is in C1 or C2 or both or what.
So this is causing us a lot of problems. And I would be interested to hear if maybe other people have experiences from other countries and other databases how people are dealing with this problem.
And, okay, finally, the grand finale, the main issue that I want to attack today is this very theoretical question of what exactly is a place? Only one minute.
Okay. I'm going to illustrate that with an example, and I'm going to go through that very quickly. There's a place in the northwest of Ireland called Donegal.
And if you search for it in our database, you will get maybe five or six hits because there are different administrative units called Donegal.
There's a town, there's a county, there's an electoral division, there's a civil parish, there's a townland. They all slightly overlap with each other.
And conceptually, they are the same place. That's why they have the same name. But as far as our database knows, they only happen to have the same name.
But this is unsatisfactory because it's failing to distinguish cases like this from cases like this. A place is called Unbaliamor, which literally means the large town.
There are lots of them all over the country, and these genuinely do just happen to have the same name. But the six Donegals don't happen to have the same name.
They have the same name because conceptually, they are the same place, even though they're manifested in different administrative geographical areas, sort of in the physical geography and in the administrative hierarchy of the state.
So what I'm suggesting is that we go from a structure like this, where we have a bunch of geographical objects in the database and a bunch of names that refer to them, and we have a lot of duplication because the names are duplicates of one another.
I'm suggesting that we go to something like this, where we introduce a new data category, which I'm referring to an abstract place.
And so the structure that we would have is that we have an abstract place. There is only one of them. There is only one for each cases like Donegal.
It refers to several geographical objects defined by coordinates, and the names refer to these abstract places rather than to patches of land definable by coordinates.
And because we now have fewer names, we have less duplication, we can go wild and annotate our names with lots of linguistic properties and linguistic lexical relations and so on.
I'm suggesting this structure for reasons of computational expediency, but I also like to think that there is a more theoretical basis to it, because places, when you think about it, are not really just patches of land definable by coordinates.
There is an overlay that civilization sort of creates, which hovers above the countryside, and that's why places exist, not in the physical geography, but in the sphere of imagination.
They're concepts, they're not just physical places, and when people assign place names to places, they actually assign place names to these theoretical abstract constructs rather than patches of land.
So this would be my ideal place names database. This is not the way our database is organized, but I'm hoping that one day somebody somewhere will give me the job of building a database like that.
Thanks very much.