-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add language property to PITs #8
Comments
The solution above has some major drawbacks, I realize already.... It involves creating a new PIT for each object, for which an ID has to be created or an URI has to be present. In the case of GeoNames, we do not have URIs or IDs for each language variant. Maybe introducing a {
"uri": "http://sws.geonames.org/2747373",
"name": "The Hague",
"type": "hg:Place",
"geometry": {
"type": "Point",
"coordinates": [
4.29861,
52.07667
]
},
"languages": {
"en": "The Hague",
"ga": "An Háig",
"it": "L'Aia",
"fy": "De Haach"
},
"data": {
"featureClass": "P",
"featureCode": "PPLG",
"countryCode": "NL"
}
} |
Or maybe this conflicts with our core conceptual model: each place name or spelling variant is a PIT.... But we also do not want to introduce new IDs for a datasets which uses its own URIs for all other PITs... |
I'll take a stab at this with the first approach for now: new source 'multilingual_names' with a record for each language synonym. Least elegant but at least we'll have something, later we can try the other approach. |
See https://github.com/whosonfirst/whosonfirst-dates for inspiration! |
For example:
This way, we can meaningful add language synonyms to PITs.
@wires What do you think?
The text was updated successfully, but these errors were encountered: