Wikidata

I think they acknowledge that info-box information is no longer good enough (both in coverage and completeness) and have handed over the moniker of the open-access KG to Wikidata. To their credit, I think its the right call.

src: I worked in a lab lead by DBPedia's founder (and one of the contributors to the original infobox to KB code).

[0] https://blog.liu.se/olafhartig/2019/01/10/position-statement...

^^This enables, amongst other things, fact's validity to be quantified. Instead of saying , you can now say { } ;

[1] http://downloads.dbpedia.org/current/ (from 2018); http://downloads.dbpedia.org/ (see the folder titled 2016-10)

To me the greatest value of Wikidata was making me aware of RDF and SPARQL.

In most cases, if you are relying on data business needs, it would be best to maintain your own RDF dataset and host it either just on HTTP, or on something like https://dydra.com/.

WikiData deseperately needs RDF ingestion, and if this is made available (can be done outside of Wikidata) then it would be easier to periodically sync datasets with Wikidata.

On that note however, you could export all Wikidata triples you need and just host that on your own SPARQL server (e.g. Jena) or use it with RDF tools like rdflib.

I'm using Wikidata to automatically categorize visited websites and used programs for time tracking purposes.

For example, here's a query to get the entity (e.g. company) that has a specific domain (news.ycombinator.com), and get the categories that entity is in that that are a descendent of the "service on internet" category:

    SELECT distinct ?service ?website_url ?outer_category ?outer_categoryLabel WHERE {
        ?service wdt:P856 ?website_url.
        optional {
            ?service wdt:P31 ?inner_category.
            ?inner_category wdt:P279* ?outer_category.
            ?outer_category wdt:P279+ wd:Q1668024.
        }
        VALUES ?website_url {  }
        SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
    }

- social news website - online service - website

Relations have to be written as `wdt:P279` even though they have names [1], and the query engine just silently accepts lots of stuff it shouldn't. For example if above you do `"url"` instead of ``, it will just not return any results because URLs is a separate type and URLs never match strings. And if an entity doesn't exist it will also just not return anything. Then there's this hacky "label service" thing that implicitly creates new output variables (outer_categoryLabel) to make it actually return text.

The UX of the query site [2] is also pretty bad.

I feel like Wikidata would be much more used if it had a easier query language. Or better, real bindings to common languages with full intellisense for properties etc). Something like this:

    const service = wikidata.variable();
    const inner_category = wikidata.variable();
    const outer_category = wikidata.variable();
    const results = await wikidata
        .filter(service.official_website("https://news.ycombinator.com"))
        .filter(service.instance_of(inner_category))
        .filter(inner_category.subclass_of(outer_category).anyDepth())
        .filter(outer_category.subclass_of("service on internet").anyDepth());

    console.log(results.map(row => row.get(outer_category).getLabel({language: "en"})));

[1]: https://phabricator.wikimedia.org/T196450 [2]: https://query.wikidata.org