> More specifically, at OSM that's the only Q-numbers people are aware of.
I would like to share my use case ( sorry if sometimes is offtopic )
I am:
- member of Wikimédia Magyarország Egyesület (Wikimedia Hungary)
- OSM meetup organizer
- in my mind: 'Q' == Wikidata ; 'Q' == Quality ( but this is a false associations )
- I have experience working with data warehousing / relational databases
Q/P prefix for me like a
https://en.wikipedia.org/wiki/Hungarian_notation "Hungarian notation aims to remedy this by providing the programmer with explicit knowledge of each variable's data type."but now I am not sure:
- What is the real meaning of Q/P prefix -> Wikidata or Wikibase?
I am involved in some open geodata projects.
#1. adding Wikidata ID concordances to Natural Earth ( this is my work )
#3. OSM
First time: I tried SPARQL + Wikidata Query Service
My experience:
- more and more data -> ( like: Q486972, human settlement ) -> more timeouts ( in my complex geo queries )
(a lot of farms imported in the Netherlands area, so I have to limit the search radius;... )
- data changes every time, so hard to write and validate complex program codes.
After a few months, I have learned that for heavy data users the Wikidata Query Service sometimes not perfect. ( but good for light queries ! )
So now I am loading "Wikidata JSON dump" to Postgres/PostGIS database - and I am writing complex codes in SQL
My codes are very complex codes ( jaro_winkler distance, geo distance, detecting Cebuno imports ; ranking multiple candidates for matching ) ;
And finally I can control the performance of the system ( not timeout ) and I have reproducible results.
for example: my simple SQL example code - you can see lot of P/Q codes inside ,
and you can expect - now I am know lot of Q/P codes by heart !
select
wd_id
,wd_label
,get_wdcqv_globecoordinate(data,'P625','P518','Q1233637') as river_mouth
,get_wdcqv_globecoordinate(data,'P625','P518','Q7376362') as river_source
from wd.wdx
where wd_id='Q626';
And now the "Natural Earth" tables looks like this ( relational database )
+-------------+------------+-----------+
| name | wikidataid | iata_code |
+-------------+------------+-----------+
| Birsa Munda | Q598231 | IXR |
| Barnaul | Q1858312 | BAX |
| Bareilly | Q2788745 | |
this is my current workflow.
But my real nightmare will start - if other databases start using Q/P prefix:
for example, other Airport related databases start using Wikibase - with Q codes
So every airport have at least 4 different Q codes!
And in the future, I have to check errors in this spreadsheet ( and sometimes I don't see the header )
+-------------+------------+-----------+-------------+-----------+-----------+
| name | wikidataid | iata_code | ourairports | flightR24 | AirNav |
+-------------+------------+-----------+-------------+-----------+-----------+
| Birsa Munda | Q598231 | IXR | Q325324 | Q973 | Q1 |
| Barnaul | Q1858312 | BAX | Q42 | Q1 | Q8312 |
| Bareilly | Q2788745 | | Q1 | Q31 | Q45 |
Q1 - everywhere - with different meanings
And what if some users want to add the new airport ID-s back to the wikidata ( linking databases ) Why not
I will see a lot of different Q codes:
Ourairports Q325324
FlightR24 Q973
AirNav Q1
And sometimes very hard to communicate for the new contributors that Q1(AirNav) =/= Q1(Wikidata)
If I see any database/spreadsheet.
- and I see a Q code - My current expectations that this is a Wikidata code. :)
Just check:
https://github.com/search?q=Q28+hungary&type=Code
So my current opinion:
- please don't use Q/P prefixes in any new/other databases!
for me, unlearning a lot of Q/P values is hard,
so as I have more-and-more experience in Wikidata data model - I would like less-and-less using any other Wikibase systems with similar Q/P prefixes.
My other pain point is the "Wikidata JSON dump" , a little more information would be a big help for me: