John Erling Blad | 5 Sep 2012 10:07
Picon

Changes to the API for Wikidata

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"}
(Continue reading)

John Erling Blad | 5 Sep 2012 10:39
Picon

Changes to the API for Wikidata

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"}
(Continue reading)

Marco Fleckinger | 5 Sep 2012 12:48
Picon

Re: Changes to the API for Wikidata

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"}
>    }
(Continue reading)

Denny Vrandečić | 7 Sep 2012 11:37
Picon
Favicon

Re: Changes to the API for Wikidata

2012/9/5 Marco Fleckinger <marco.fleckinger <at> 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
>> {
(Continue reading)

Marco Fleckinger | 7 Sep 2012 12:21
Picon

Re: Changes to the API for Wikidata

Hi,

On 07.09.2012 11:37, Denny Vrandečić wrote:
> 2012/9/5 Marco Fleckinger<marco.fleckinger <at> 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".

(Continue reading)

Daniel Kinzler | 7 Sep 2012 11:58
Picon
Favicon

Re: Changes to the API for Wikidata

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.

(Continue reading)


Gmane