There are a number of useful and important Wikidata-focused tools that cannot be made to work easily with other Wikibases. Tool builders need to know important configuration settings of a Wikibase in order for these tools to work properly outside of the Wikidata context. For maximum impact, essential metadata about each Wikibase instance should be generated and exposed in an automated way.
Details
Oct 31 2023
Ok, I think I still don't understand it fully, but I trust you do and I won't stand in the way ^^
Oct 30 2023
If it is in the document served by WikibaseManifest, then as a tool author I have the same problem as currently: if I wanted to make sure that all of my tool's configuration can be derived from the contents of the WikibaseManifest, then whenever I need to introduce a configuration parameter to implement a new feature in my tool, I first need to submit a patch to WikibaseManifest for it to expose this information (be it namespaced or not), get it merged, get a new version of the extension be released and deployed on the wikis I want to interact with.
For OpenRefine(and other tools) the benefit would be that RDF ontologies can be extended very easily so that tools can define their own (namespaced) properties.
So, even if we are assuming that the WikibaseManifest extension serves its information by following some particular ontology, the tool-specific information will not be available there. That means we cannot make it possible to just set up a Wikibase instance in OpenRefine just by providing the URL of the Wikibase instance and letting OpenRefine discover the configuration there. Or how would OpenRefine discover this additional information it requires?
Thanks for reviving this thread I had forgotten about ^^
I'm interested in working on this across OpenRefine, the WikibaseManifest extension and "TIB's" reconciliation service but I wonder if this work wouldn't benefit from being migrated to a proper vocabulary for describing APIs and knowledge graphs. Like Hydra and DCAT or schema.org instead of relying on a JSON file with more or less tool specific fields. It would have a lot of benefits like interoperability and extensibility, so one could for example have an Wikibase manifest describing multiple reconciliation services, or describing any API with an OpenAPI spec, or a W3C URI, etc. We could then just describe the reconciliation and for things like the template for edit summaries one could just use a custom property?
Jul 12 2023
Aug 10 2021
I was told to close this one!
Jul 27 2021
Jul 26 2021
Apr 13 2021
Closed thanks to related efforts by the Release Strategy & Infrastructure initiative. WikibaseManifest will be included in the upcoming Spring 2021 Wikibase Docker release.
Mar 3 2021
Most of the work is done here https://phabricator.wikimedia.org/T275862 but this is still not finished.