Smalyshev created this task.
Smalyshev claimed this task.
Smalyshev added subscribers: Smalyshev, Manybubbles, GWicke, JanZerebecki,
aude, Lydia_Pintscher, Eloquence.
Smalyshev added projects: Wikidata, wikidata-query-service.
Smalyshev changed Security from none to none.
TASK DESCRIPTION
I was under the impression that each time the claim is updated, the new ID is
generated, so I can just match the IDs to update the claims. However, I have
discovered the following: for item Q24517, the old claim in my dump is:
```
"P279":[{"id":"Q24517$7A855A08-5DD0-41A6-9A36-E3AC3DE24B11","mainsnak":{"snaktype":"value","property":"P279","datatype":"wikibase-item","datavalue":{"value":{"entity-type":"item","numeric-id":2095},"type":"wikibase-entityid"}}
```
However, in current dump at
https://www.wikidata.org/wiki/Special:EntityData/Q24517.json it is:
```
"P279":[{"id":"Q24517$7A855A08-5DD0-41A6-9A36-E3AC3DE24B11","mainsnak":{"snaktype":"value","property":"P279","datatype":"wikibase-item","datavalue":{"value":{"entity-type":"item","numeric-id":2207288},"type":"wikibase-entityid"}}
```
As we can see, same claim ID but it refers to a different node. That makes it
hard to recognize when the claim must be updated. So I'd like to figure out:
# Is it intentional or a bug?
# If it's intentional, can it be changed to generate new IDs on change?
# If not, what would be the best way to recognize when clam changes?
The items can have many claims, so knowing which ones changed and updating
only those would greatly speed up the query service function.
Alternatively, if there's some other format that is better suitable to
loading updates, we may want to use that instead of JSON data.
TASK DETAIL
https://phabricator.wikimedia.org/T85045
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
<username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev
Cc: Aklapper, Smalyshev, Manybubbles, GWicke, JanZerebecki, aude,
Lydia_Pintscher, Eloquence, jkroll, Wikidata-bugs, daniel
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
