Please note that this is a breaking change for bots!
It is decided that the module wbsetitem will change from the present "short form" in the json structure to a "long form". Exactly how the long form will be is still a bit open, but it will be closer to the json output format. The changes also makes it possible to use a key-less format as the language and site id will be available inside the long form.
The following short form will be WRONG in the future { "labels":{ "de":"Foo", "en":"Bar" } }
This long form will be RIGHT in the future { "labels":{ "de":{"value":"Foo","language":"de"}, "en":{"value":"Bar","language":"en"} } }
And also this will be RIGHT { "labels":[ {"value":"Foo","language":"de"}, {"value":"Bar","language":"en"} ] }
New modules may use a long form if they support json input, but that for the future.
In some cases it seems necessary to add flags for what to do with individual fields, but perhaps we can avoid it. (Typically for adding/removing aliases, but it could also be necessary for other fields.)
There are also a new "clear" URL argument that will clear the content of an item and make it possible to rebuild it from scratch. Default behavior is NOT to clear the content, but to incrementally build on the existing item.
Also note that use of [no]usekeys in the URL is not supported anymore.
See also * http://www.mediawiki.org/wiki/Extension:Wikibase/API#New_long_format
/jeblad
Hi,
On 05.09.2012 10:39, John Erling Blad wrote:
Please note that this is a breaking change for bots!
It is decided that the module wbsetitem will change from the present "short form" in the json structure to a "long form". Exactly how the long form will be is still a bit open, but it will be closer to the json output format. The changes also makes it possible to use a key-less format as the language and site id will be available inside the long form.
The following short form will be WRONG in the future { "labels":{ "de":"Foo", "en":"Bar" } }
Here we have the Problem, that we cannot add additional information, like a short description or anything similar. So this is absolutely necessary.
This long form will be RIGHT in the future { "labels":{ "de":{"value":"Foo","language":"de"}, "en":{"value":"Bar","language":"en"} } }
do you really want redundant information?
And also this will be RIGHT { "labels":[ {"value":"Foo","language":"de"}, {"value":"Bar","language":"en"} ] }
Not easy browsable by using labels[lang] or labels.lang. Iterating through different labels is needed.
so why not using:
{ labels:[ de:{value:"Foo", source:whatever_de}, en:{value:"Bar", source:whatever_en} ] }
Here you can iterate through all items using their key and the value object:
for (key in labels) { console.log(labels[key]) }
Marco
2012/9/5 Marco Fleckinger marco.fleckinger@gmail.com:
Hi,
On 05.09.2012 10:39, John Erling Blad wrote:
Please note that this is a breaking change for bots!
It is decided that the module wbsetitem will change from the present "short form" in the json structure to a "long form". Exactly how the long form will be is still a bit open, but it will be closer to the json output format. The changes also makes it possible to use a key-less format as the language and site id will be available inside the long form.
The following short form will be WRONG in the future { "labels":{ "de":"Foo", "en":"Bar" } }
Here we have the Problem, that we cannot add additional information, like a short description or anything similar. So this is absolutely necessary.
Right, that is why we are deprecating it.
This long form will be RIGHT in the future { "labels":{ "de":{"value":"Foo","language":"de"}, "en":{"value":"Bar","language":"en"} } }
do you really want redundant information?
The redundancy comes from the browsability that you discuss later. This allows the object in the key-position to be completely self-sustainable and can be passed around. The key is folded forward to increase the browsability. Also the keys do not explicitly say what they are (language codes, e.g., in this case). This makes the data format require more external description.
And also this will be RIGHT { "labels":[ {"value":"Foo","language":"de"}, {"value":"Bar","language":"en"} ] }
Not easy browsable by using labels[lang] or labels.lang. Iterating through different labels is needed.
so why not using:
{ labels:[ de:{value:"Foo", source:whatever_de}, en:{value:"Bar", source:whatever_en} ] }
Because then the objects are not self-contained, as they do not say which language they are.
Here you can iterate through all items using their key and the value object:
for (key in labels) { console.log(labels[key]) }
So you can in the redundant version.
Marco
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi,
On 07.09.2012 11:37, Denny Vrandečić wrote:
2012/9/5 Marco Fleckingermarco.fleckinger@gmail.com:
On 05.09.2012 10:39, John Erling Blad wrote:
This long form will be RIGHT in the future { "labels":{ "de":{"value":"Foo","language":"de"}, "en":{"value":"Bar","language":"en"} } }
do you really want redundant information?
The redundancy comes from the browsability that you discuss later. This allows the object in the key-position to be completely self-sustainable and can be passed around. The key is folded forward to increase the browsability.
As Daniel wrote.
Also the keys do not explicitly say what they are (language codes, e.g., in this case). This makes the data format require more external description.
Not part here, but part of the request where you may could ask for "by language".
And also this will be RIGHT { "labels":[ {"value":"Foo","language":"de"}, {"value":"Bar","language":"en"} ] }
Not easy browsable by using labels[lang] or labels.lang. Iterating through different labels is needed.
so why not using:
{ labels:[ de:{value:"Foo", source:whatever_de}, en:{value:"Bar", source:whatever_en} ] }
Because then the objects are not self-contained, as they do not say which language they are.
Sorry, I did not know that this was your wish/requirement.
Here you can iterate through all items using their key and the value object:
for (key in labels) { console.log(labels[key]) }
So you can in the redundant version.
Exactly.
Marco
On 05.09.2012 12:48, Marco Fleckinger wrote:
This long form will be RIGHT in the future { "labels":{ "de":{"value":"Foo","language":"de"}, "en":{"value":"Bar","language":"en"} } }
do you really want redundant information?
It's not redundant information, it's a lookup index for convenient access. Just like you would add indexes in a database.
And also this will be RIGHT { "labels":[ {"value":"Foo","language":"de"}, {"value":"Bar","language":"en"} ] }
Not easy browsable by using labels[lang] or labels.lang. Iterating through different labels is needed.
That'S why we are using the form with keys in the output. But we accept either form as input (associative as well as list) - for the input, the important thin is that the individual entries are complete and self-contained.
so why not using:
{ labels:[ de:{value:"Foo", source:whatever_de}, en:{value:"Bar", source:whatever_en} ] }
Here you can iterate through all items using their key and the value object:
for (key in labels) { console.log(labels[key]) }
Why wouldn't you be able to do just that with the form we suggest? In fact, in your example, the log would be missing the language code.#
The idea behind the format we are proposing is to use self-contained entries (records) for everything, and support named keys for convenience where possible.
-- daniel