daniel edited the task description. (Show Details)

* The repo name in an EntityId object can always be assumed to match the local definition of that name. A repo name in serialized data however cannot be interpreted without knowing which repo it came from.

When receiving prefixed entities from another repo, prefixes are "chained", like interwiki prefixes:
* When reading `d:Q5` from repo `foo`, this is turned into `foo:d:Q5`, meaning "Q5 at the repo that repo foo calls d".
* The local repo may have mappings defined for the prefixes used by other wikis, e.g. "foo:d" would be known to be the same as the local prefix "wd" for Wikidata.
* During deserialization data from another repo, we always add the name of the source repo as a prefix, and then resolve any known mappings: `d:Q5`-from-foo becomes `foo:d:Q5` and then `wd:Q5`.
* During deserialization data from the local database, we don't add any prefix, but we still esolve any known mappings. If `foo:d:Q5` was stored earlier because there was no mapping defined for `foo:d` then, but there is a mapping now, that mapping is resolved when loading the item.

This ensures that an EntityId object always "knows" which repo it belongs to, and it always reflects the currently defiend mappings. This implies however that an ID used in an old revision can //change its effective serialization// later - it will //look// different when the mappings change. The ID would however still //mean// the same, sicne it still references the same entity (provided the mappings were defined correctly).




To: daniel
Cc: Jakob_WMDE, WMDE-leszek, Ricordisamoa, jayvdb, aude, JeroenDeDauw, Jonas, JanZerebecki, adrianheine, thiemowmde, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, Mbch331
Wikidata-bugs mailing list

Reply via email to