Re:WikipediaQL: Query language for efficient data extraction...
by zverok on Monday July 05, 2021 @04:07PM
(#27741398)
Thanks!
I am mentioning Wikidata/SPARQL in README (TL;DR: less data still, harder to discover unless you are deeply into SemWeb tech), but I expect this project, will it live long (fingers crossed) will definitely has some relations with Wikidata, too. My previous attempt on something similar: https://github.com/molybdenum-99/reality — used both Wikipedia and Wikidata (and OpenStreetMap and...) but however cool were few demos I managed too achieve, it was a dead end for several reasons.
Re:WikipediaQL: Query language for efficient data extraction...
by zverok on Tuesday July 06, 2021 @08:00AM
(#27747236)
I am (slightly) contemplating this (see also Reddit discussion: https://www.reddit.com/r/programming/comments/oe9oia/wikiped...). But currently I am mostly focused on deducing atomic selectors that would be useful and choosing their interaction. The particular syntax is kind of afterthought.
Though, I should say that I am still not sure GraphQL's mental model would work here (WikipediaQL for now structured around "which part of the document to choose and how to transform it", with "where to put it" being the final statement just of some branches; with GraphQL, as far as I can understand, each node is "where to put it"-first, and it _may_ lead to clumsy and repetitive queries).
Re:WikipediaQL: Query language for efficient data extraction...
by IfOnlyYouKnew on Tuesday July 06, 2021 @04:42AM
(#27745646)
Yes and no. You can get SQL dumps (although XML is more common), but it doesn't contain any useful structure. The article content is just wikitext, and only metadata such as revisions are structured.
Re:WikipediaQL: Query language for efficient data extraction...
by arthurcolle on Wednesday July 07, 2021 @10:26AM
(#27761488)
You can get all the edges (links between pages) and nodes (pages and text therein), so not sure what you mean about structure. I loaded all of Wikipedia into Neo4J like 6 months ago... Wasn't very hard.
Re:WikipediaQL: Query language for efficient data extraction...
by zverok on Tuesday July 06, 2021 @07:55AM
(#27747180)
The answer is complicated (I am mentioning it in the midst of plans and possibilities in README: "(maybe?) other MediaWiki-based sites (like Wikvoyage, Wiktionary, etc.)").
In more details:
1. With the current library, you can't (connection to en.wikipedia.org is hardcoded :shrug:)
2. Adding "what MediaWiki instance to connect" is relatively easy (they all have the same API), including Wiktionary
3. For Wiktionary, current (v. 0.0.2) selectors will be useful, but future ones (infobox, wikitable and other high-level Wikipedia-specific stuff) will be not
4. So I might think of some way of specifying "set of selectors relevant for this instance" or something like that.
5. So, in some distance future, Wiktionary definitely would be fully supported; how distant—probably depends on how fast the project will be moving forward, and how it will be (hopefully) used by others
6. But I might add a support for "use this instance of MediaWiki" in the near future, it is easy!
If you ever tried to scrape HTML, you know how untidy it usually ends up; this one looks clean.
I am mentioning Wikidata/SPARQL in README (TL;DR: less data still, harder to discover unless you are deeply into SemWeb tech), but I expect this project, will it live long (fingers crossed) will definitely has some relations with Wikidata, too. My previous attempt on something similar: https://github.com/molybdenum-99/reality — used both Wikipedia and Wikidata (and OpenStreetMap and...) but however cool were few demos I managed too achieve, it was a dead end for several reasons.
Though, I should say that I am still not sure GraphQL's mental model would work here (WikipediaQL for now structured around "which part of the document to choose and how to transform it", with "where to put it" being the final statement just of some branches; with GraphQL, as far as I can understand, each node is "where to put it"-first, and it _may_ lead to clumsy and repetitive queries).
That would be really useful.
You can get a lot of data from Wikidata. They have a SPARQL interface at https://query.wikidata.org/#%23Humans%20born%20in%20New%20Yo... and you can also get all the data in a variety of rdf formats.
In more details:
1. With the current library, you can't (connection to en.wikipedia.org is hardcoded :shrug:)
2. Adding "what MediaWiki instance to connect" is relatively easy (they all have the same API), including Wiktionary
3. For Wiktionary, current (v. 0.0.2) selectors will be useful, but future ones (infobox, wikitable and other high-level Wikipedia-specific stuff) will be not
4. So I might think of some way of specifying "set of selectors relevant for this instance" or something like that.
5. So, in some distance future, Wiktionary definitely would be fully supported; how distant—probably depends on how fast the project will be moving forward, and how it will be (hopefully) used by others
6. But I might add a support for "use this instance of MediaWiki" in the near future, it is easy!