4 ms·
The size of Wikidata knowledge base / relevant graph (as well as Linked Open Data Cloud KBs and other large KBs) certainly presents some challenges. However, I
by ablekh 5y ago
The size of Wikidata knowledge base / relevant graph (as well as Linked Open Data Cloud KBs and other large KBs) certainly presents some challenges. However, I think that the largest challenge and, in fact, the main obstacle, for practical programmatic solutions is the use of essentially meaningless alphanumeric identifiers assigned to entities and properties. All corresponding identifiers need to be discovered first manually in order to construct relevant SPARQL queries. Needless to say that these queries are not particularly human-readable (or, rather, human-interpretable) as well.
- tuukkah 5y agoWhy manually, when you have APIs to find Wikidata items and properties based on their labels, descriptions, aliases, data, metadata and use? If you mean autocomplete UI or tooltips, look no further than the query editor and its Ctrl+Space at https://query.wikidata.org/ https://query.wikidata.org/
- ablekh 5y agoI meant APIs, not UI or tooltips. And while Wikidata entities and properties could be accessed using MediaWiki API, arguably, there are, at least, two issues with this: 1) you have to know exact names of all the relevant metadata, which is quite overwhelming* (and the SPARQL query editor's autocomplete feature does not seem to help with this, except for top-level attributes); 2) entity disambiguation - yes, it can be implemented programmatically, however, it has to rely on knowing exact names (values), which brings us back to the point #1. *) Here is an example of the number of attributes for a single entity: https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q42&languages=en https://www.wikidata.org/w/api.php?action=wbgetentities&ids=....