Closed almereyda closed 4 years ago
this is an issue with custom instances and wikidata-edit
, which isn't addressed from wikidata-cli
yet
there are actually two different problems here:
wikidata-edit
(on which all wikidata-cli
write features are built) relies heavily on the capacity to check properties datatype, which is done by having a list of those properties at hand. This can be customized, but the workflow isn't very satisfying yet: it would be more user-friendly to update this properties list depending on the passed config
objectWe do have such a SPARQL endpoint. What can I do to support mitigating this infrastructural change, as it proposedly affects multiple repositories?
And to illustrate my suprise about properties having a type. Where are these documented and coming from? Why are those not within each Wikibase's namespace (P & Q) ?
I am wondering why these types are hardcoded, because I feel this is working against Linked Data principles here, excluding the schema of the data from its own representation.
On 17 December 2017 at 00:37, Maxime Lathuilière notifications@github.com wrote:
there are actually two different problems here:
- wikidata-edit (on which all wikidata-cli write features are built) relies heavily on the capacity to check properties datatype https://github.com/maxlath/wikidata-edit/search?utf8=%E2%9C%93&q=find_datatype&type=, which is done by having a list of those properties at hand https://github.com/maxlath/wikidata-edit/blob/master/lib/properties/properties.js. This can be customized, but the workflow isn't very satisfying yet https://github.com/maxlath/wikidata-edit/blob/master/docs/how_to.md#custom-wikibase-instance
- but to do this customization, you need a SPARQL endpoint, which all Wikibase don't have
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/maxlath/wikidata-cli/issues/46#issuecomment-352219715, or mute the thread https://github.com/notifications/unsubscribe-auth/ABka_JHYz1zbmzJC8Vh38A86558QZXL-ks5tBFQtgaJpZM4RBZv6 .
I don't know the internals of Wikibase, but a type is associated to each property, as you can see in this query, which links to this page where those types seem to be defined
so if you make this same query but specifying the customized SPARQL endpoint, isn't it working?
wd edit-item q224.json --instance http://some/wikibase/instance/w/api.php --sparql-endpoint http://some/sparql/endpoint
Yes, I managed to mass-add items and translations with the flag after the patch had been provided. Let me find the sources as a proof ...
On Sun, 23 Sep 2018 at 10:08, Maxime Lathuilière notifications@github.com wrote:
so if you make this same query but specifying the customized SPARQL endpoint, isn't it working?
wd edit-item q224.json --instance http://some/wikibase/instance/w/api.php --sparql-endpoint http://some/sparql/endpoint
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/maxlath/wikidata-cli/issues/46#issuecomment-423799457, or mute the thread https://github.com/notifications/unsubscribe-auth/ABka_OeBusAYzPX2J502RsD_1vUZDbJeks5ud0FrgaJpZM4RBZv6 .
since wikibase-edit@v3.0.0
, the map of properties datatype is generated by requesting the Wikibase server instead of relying on a possible SPARQL endpoint, making this all class of errors disappear \o/ wikibase-edit
will be updated to >v3.0.0
in the very soon coming v8.0.0
After following an ominuous link in the documentation and recreating a JSON following the example as of q224.json as
with a valid configuration for a custom Wikibase instance, a stacktrace is thrown: