Qualifiers, like other user-generated properties, will be represented
by a name like "p72137", not by "rank". Therefore a clash cannot
happen.
In the example we only used names in order to make it more readable.
Cheers,
Denny
2012/10/18 Andreas Schultz :
> Hi Daniel,
>
> thanks for the answer. I
Hi Daniel,
thanks for the answer. Is there any plan on when to decide on a
concrete (version 1) JSON representation?
There is also one more thing I would like to ask about the JSON draft.
Is there any reason why qualifiers are represented as key-value pairs
directly in the statement object, inste
racy, altitude or not altiitude, etc and just bundling the properties
> together in an object future proofs you for all that.
>
> -Original Message- From: Andreas Schultz
> Sent: Wednesday, October 17, 2012 7:20 AM
> To: wikidata-l@lists.wikimedia.org
> Subject: [Wikid
--Original Message-
From: Andreas Schultz
Sent: Wednesday, October 17, 2012 7:20 AM
To: wikidata-l@lists.wikimedia.org
Subject: [Wikidata-l] JSON representation
Hi all,
I have a question or rather proposal regarding the JSON representation [1].
The "Geo" example on the JSON page[1
On 17.10.2012 13:20, Andreas Schultz wrote:
> Wouldn't a representation like the following be more
> appropriate?
>
> "value": {
> "latitude" : 32.233,
> "longitude" : -2.233,
> }
>
> That is, if "snaktype": "value", then there has to be a "value" key
> with a data type specific value o
Hi all,
I have a question or rather proposal regarding the JSON representation [1].
The "Geo" example on the JSON page[1] implies that there won't be a
fixed representation for data types. Instead of the "value" key that
all the other examples use, the Geo example uses "longitude" and
"latitude".
