[OSM-talk] OSM relation ID property in Wikidata
cstadler at informatik.uni-leipzig.de
Sat May 4 14:17:54 UTC 2013
>> Wikidata entities are (with a few caveats) static and
language-independent (eg https://www.wikidata.org/wiki/Q3183), and could
potentially be useful here
I totally agree, so tagging OSM entities with Wikidata IDs (where
applicable) might improve the stability even beyond that of using
Wikipedia arctile names.
>> but they're not human-readable and you'd have to rely on an API to
convert them into page titles, which seems like it might not be desirable.
We are talking about people wanting stable references to OSM. If this is
the most stable way to do, then ppl have to - and will - live with it.
Because they are doing it already.
Right now,  is a popular source for stable identifiers - for each
Wikipedia article, there a a corresponding *machine readable* DBpedia
And in  you see an overview of datasets referring to these IDs. Note
that by ID I actually mean IRIs in general.
So if Wikidata succeeds, we will be using their IDs all over the place.
There is work in progress to make Wikidata Linked Data / Semantic Web
compatible - in the next few months we will know more.
As for the Demo I meantioned in another mail:
I am the maintainer of the LinkedGeoData (LGD) project where we
publish the whole OSM database as RDF data.
This means I have a full, live synced replicate of the planet here - and
let me say "great job!" to the osmosis devs :)
So I created a Wikipedia article name Linked Data API:
Note that there are just a bit more than 100K entities having a
wikipedia tag, and the data quality seems really low.
This does a lookup for the OSM id based on their wikipedia and
When you follow the shown sameAs link, you will go to:
which is the RDF version of the corresponding OSM entity.
Note, at this URL, you will see that it points to
http://dbpedia.org/resource/Catford - so you can navigate the *data*
just like hyperlinks in HTML documents.
Also note, that this is not just a "I hack a REST API thing":
You can also query it - e.g. whiche user added the Wikipedia link and
what else did he edit:
Add 'Explain' before the 'SELECT' to see the SQL.
Yes, its a bit slow because Postgres takes a bad query plan for the
conditional Wikipedia tags index >_<. Everything will get better with
the new materialized views support ;)
 Example: http://dbpedia.org/resource/Catford
Note:If you start scraping the HTML for data, you're doing it wrong ;)
curl -LH "Accept: application/rdf+xml"
curl -LH "Accept: application/json"
Or visit: http://dbpedia.org/data/Catford.ntriples
Same data, different formats.
On 05/04/2013 11:47 AM, Andrew Gray wrote:
> On 4 May 2013 00:49, Claus Stadler <cstadler at informatik.uni-leipzig.de> wrote:
>> Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
>> Wikipedia referring to database identifiers? (The answer is a clear 'yes'
>> from my side.)
>> In fact there are the (wikipedia, *) tags - but not sure how good the
>> quality is - what can be seen on a first glance is, that people mix URLs and
>> article names, and also encoding.
> Wikipedia URLs are themselves potentially unstable, though - it's
> usually more or less okay for geographic places, since we tend to have
> fixed naming systems, but to pick a high-profile example, the URL
> https://en.wikipedia.org/wiki/Perth has at various times over the past
> ten years pointed to Perth in Perthshire, Perth in Western Australia,
> and a placeholder disambiguator page.
> (They are also, of course, language-dependent, but that's another
> kettle of fish)
> Wikidata entities are (with a few caveats) static and
> language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and
> could potentially be useful here - but they're not human-readable and
> you'd have to rely on an API to convert them into page titles, which
> seems like it might not be desirable.
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage & WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk