Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Wikibases other than Wikidata #14

Open
GreenReaper opened this issue Apr 11, 2021 · 0 comments
Open

Add support for Wikibases other than Wikidata #14

GreenReaper opened this issue Apr 11, 2021 · 0 comments

Comments

@GreenReaper
Copy link

GreenReaper commented Apr 11, 2021

EntityShape currently seems to assume it will only ever be run on Wikidata and contains hardcoded URIs in both Python as well as JS, both in obvious places like _get_property_name and _get_entity_json, but also _strip_schema_comments and _compare_statements.

In practice, Wikidata does not contain all data, and in my use-case I wanted to check our Q3 against our EntitySchema:E1 - which as documented in that schema works with the ShEx2 validator once CORS is whitelisted for that domain with CORS Everywhere.

Seeing this script recommended in Wikidata's shape tutorial, I tried to adapt the JS by changing the harcoded URLs within it and using mw.loader.load() on it. However, this failed. Looking closer, I saw it passes entity and property IDs into the API, not URI/IRIs.

It would be nice if it could work with a different base URI that was passed into it, or potentially across disparate URIs for entity and schema, to aid use of Wikibase by third-parties and federation between these and Wikidata. Failing that, moving hardcoded URIs into centrally-defined constants would probably make it easier to reuse the code if hosted elsewhere (e.g. by @wbstack).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant