No. A global encyclopaedia might be global, but does not have to be imperialist, if the control over the content and the ability to contribute to the encyclopaedia is not limited to imperial structures.

Unless you equate "global" with "imperialist", in which case your statement is true by definition. But then everything that is done on a global scale is necessarily imperialist, and then one of the two terms does not seem useful anymore.

Equity can be global.

That would require the equation to be wrong.

Sine the wiki hasn't been opened for editing yet, there is indeed only one function that has visible implementations (which was added for testing purposed): https://www.wikifunctions.org/view/en/Z10000 - all others are built-in and then invisible.

The two implementations are in Python and JavaScript (and rather trivial): https://www.wikifunctions.org/view/en/Z10004 https://www.wikifunctions.org/view/en/Z10005

This particular work is mostly funded through a set of large restricted donations, not through the general funds.

exactly that! I have a design mockup that is quite similar to that.

Thanks, that's really helpful to read! The page is still in a very early stage. You are right, the current object section is just confusing, we will remove it.

Maybe a better start to understand what Wikifunctions does - but it is a very simple example too - is this function: https://www.wikifunctions.org/wiki/Z10000

The other functions that you found randomly are currently not well supported.

We are working on it, to make it less confusing. Such feedback is very helpful.

As planned, with our first scheduled weekly deployment, the JSON object is not being displayed anymore.

I have a half hour YouTube video on that topic, maybe you'll find it interesting, but likely too long: https://www.youtube.com/watch?v=WqYBx2gB6vA

It was interesting. I don’t think cheap matters much in a world:where compute is still getting rapidly cheaper. Being certain is good, but the throwmtons of data i to massive models keeps beating everything else. I do think the models need to get some self doubt built in some how but I don’t think the data catalog will be more than post NOC fact checking. Fun times tho.

Edited: It was interesting. I don’t think cheap matters much in a world where compute is still getting rapidly cheaper. Being certain is good, but the throw tons of data into massive models keeps beating everything else. I do think the models need to get some self doubt built in some how but I don’t think the data catalog will be more than post hoc fact checking. Fun times tho. (My mom was an editor, she'd be horrified.)

I hope this helps with getting started: https://w.wiki/3x3n

And here's a visualization on a map, using geocoordinates: https://w.wiki/3x3g

Thanks, the queries are very powerful, but it still seems like this data is not as usable as the data in the HTML table. Any airports that don't have wikipedia links for the airport or city don't get picked up, and there are disagreeing duplicates in the wikidata that the HTML does not have.

For example (AKG) Anguganak Airport and city Anguganak don't have an article so they don't appear in the wikidata. ALZ doesn't appear in the data because Lazy Bay does not have an article page. There are some duplicate entries, with different cities or airport names like AAL, AAU, ABC. ABQ has 4 different entries. The data also is out-of-date in some instances. "Opa-locka Airport" was renamed to "Miami-Opa Locka Executive Airport" in 2014 for example. In the HTML table all these issues are solved.

Thanks for the answer!

I got the query wrong (reason: https://twitter.com/vrandezo/status/1430206988177219593 )

Here's the corrected query: https://w.wiki/3x8u

This includes a few more thousand results.

AKG does show up (but has indeed no connection to Anguganak), ALZ shows up (again, without a connection to a city). Article pages are not a requirement for the data to be in Wikidata.

I see your point. The duplicate entries can often be explained (e.g. ABQ is indeed the IANA code both for Albuqerque Sunport and the Kirtland AF Base, which are adjacent to each other), but that's already a lot of detail.

If a single table provides the form of clean data one is looking for, that's great and should be used (and slightly different than the original question that triggered this, where we had to go through many different pages and fuse data from thousands of pages together). Different tasks benefit from different inputs!

I'd suggest that in this case one should consider using MusicBrainz, in order to get more comprehensive and better results than either with Wikidata or Wikipedia.

I wouldn't say the data is better, just different. Instead of "how do I extract the info I want?" your problem becomes too much data to sift through. See my comment here: https://news.ycombinator.com/item?id=24992600

That obscures my point.

My point is that even if "Wikipedia" may not be the best tool, "Wikidata" is the wrong tool because the data is wrong.

Sounds a lot like DBpedia to me

Hmmmm, indeed. Considering that I've heard of DBpedia before my attempts with Wikidata, I now wonder why I didn't use it. Gonna check what they know about subjects that interest me.

That would be a bug and should not be the case. I just tried it and couldn't replicate it. There is no difference between 7-7-2000 and 07-07-2000 in xsd, and neither in the SPARQL query endpoint.

Here are the people in Wikidata born on 07-07-2000: https://w.wiki/3wrj

And here the people born on 7-7-2000: https://w.wiki/3wrk

The results are identical.

(This doesn't mean we have no duplicates at all in Wikidata - the post actually mentions five discovered duplicates within Queen Elizabeth II's ancestors. But these are entities, not within the datatypes)

IMHO WD SPARQL should reject invalid literals: https://phabricator.wikimedia.org/T253718