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". 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 object.
Something that imho would also be useful, is a way to specify the data type - this could be optional. For the Geo example something like the following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data type from the keys and/or the lexical representation of the values, which would usually be a tough task.
Cheers, Andreas
1. https://meta.wikimedia.org/wiki/Wikidata/Development/Phase_2_JSON
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 object.
I agree - it should either be "value", or the same as the top-level property, as in:
"location": { "location": { "latitude" : 32.233, "longitude" : -2.233, }
"as-of": { ... } }
Something that imho would also be useful, is a way to specify the data type - this could be optional. For the Geo example something like the following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data type from the keys and/or the lexical representation of the values, which would usually be a tough task.
I agree that at least for the external representation, every value should always be accompanied by its data type. It's just a pain having to look up the data type, or maintain a mapping locally.
The question is how to represent this structurally.
"location": { "value": { "value": { "latitude" : 32.233, "longitude" : -2.233, }, "type": "geo" } }
or, resp:
"location": { "location": { "value": { "latitude" : 32.233, "longitude" : -2.233, }, "type": "geo" } }
The latter makes more sense to me. But it's a lot of overhead. Alternatively:
"location": { "value": { "_type": "geo" "latitude" : 32.233, "longitude" : -2.233, }, }
Using "magic" keys (prefixed with "_" or whatever) is kind of nasty, but saves quite a bit of structural complexity.
-- daniel
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, instead of an associative array reachable through a "qualifiers" key? I am just imagining possible collisions, e.g. if someone wants to use "rank" as a qualifier that is independent from the Wikidata rank.
Cheers, Andreas
On 17 October 2012 15:29, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
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 object.
I agree - it should either be "value", or the same as the top-level property, as in:
"location": { "location": { "latitude" : 32.233, "longitude" : -2.233, }
"as-of": { ... } }
Something that imho would also be useful, is a way to specify the data type - this could be optional. For the Geo example something like the following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data type from the keys and/or the lexical representation of the values, which would usually be a tough task.
I agree that at least for the external representation, every value should always be accompanied by its data type. It's just a pain having to look up the data type, or maintain a mapping locally.
The question is how to represent this structurally.
"location": { "value": { "value": { "latitude" : 32.233, "longitude" : -2.233, }, "type": "geo" } }
or, resp:
"location": { "location": { "value": { "latitude" : 32.233, "longitude" : -2.233, }, "type": "geo" } }
The latter makes more sense to me. But it's a lot of overhead. Alternatively:
"location": { "value": { "_type": "geo" "latitude" : 32.233, "longitude" : -2.233, }, }
Using "magic" keys (prefixed with "_" or whatever) is kind of nasty, but saves quite a bit of structural complexity.
-- daniel
-- Daniel Kinzler, Softwarearchitekt Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
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 a.schultz@mes-semantics.com:
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, instead of an associative array reachable through a "qualifiers" key? I am just imagining possible collisions, e.g. if someone wants to use "rank" as a qualifier that is independent from the Wikidata rank.
Cheers, Andreas
On 17 October 2012 15:29, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
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 object.
I agree - it should either be "value", or the same as the top-level property, as in:
"location": { "location": { "latitude" : 32.233, "longitude" : -2.233, }
"as-of": { ... } }
Something that imho would also be useful, is a way to specify the data type - this could be optional. For the Geo example something like the following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data type from the keys and/or the lexical representation of the values, which would usually be a tough task.
I agree that at least for the external representation, every value should always be accompanied by its data type. It's just a pain having to look up the data type, or maintain a mapping locally.
The question is how to represent this structurally.
"location": { "value": { "value": { "latitude" : 32.233, "longitude" : -2.233, }, "type": "geo" } }
or, resp:
"location": { "location": { "value": { "latitude" : 32.233, "longitude" : -2.233, }, "type": "geo" } }
The latter makes more sense to me. But it's a lot of overhead. Alternatively:
"location": { "value": { "_type": "geo" "latitude" : 32.233, "longitude" : -2.233, }, }
Using "magic" keys (prefixed with "_" or whatever) is kind of nasty, but saves quite a bit of structural complexity.
-- daniel
-- Daniel Kinzler, Softwarearchitekt Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
-- Telefon/Phone +49 6441 87087-32 · Telefax/Fax +49 6441 87087-17 E-Mail a.schultz@mes-semantics.com · Web http://mes-semantics.com
MediaEvent Services GmbH & Co. KG
Berlin Office: Stendaler Straße 4 · 10559 Berlin · Germany Wetzlar Office: Charlotte-Bamberg-Str. 6 · 35578 Wetzlar · Germany
Handelsregister/Commercial Register: Amtsgericht Wetzlar HRA 4015 USt-IdNr./VAT Reg.No. DE206509024
Komplementärin: MediaEvent Services Verwaltungs GmbH Handelsregister/Commercial Register: Amtsgericht Wetzlar HRB 5079 Geschäftsführer/Managing Director: Tim Ebert ________________________________________________________________
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Yep, there are many reasons why geographic coordinates should be reified, largely because some people need more information than others.
Today all the people who got into geography in the last few years use WGS84 as a datum so it's fashionable to not specify any datum. That goes back to the bad old days when visual surveying was the only game in town so you could specify locations on an island relative to each other quite accurately but need to get a fix against the stars to know where the island as a whole was.
Even neogeography projects, however, sometimes need to specify a datum. A while back I was collecting a data set on the Hollywood Walk of Fame and the requirements there were: (i) stars get located on the right side of the street, (ii) stars get located in the right order, and (iii) stars get located on the right block. WGS84 (a standard GPS unit) isn't quite good enough to do these three things, particularly close to the Hollywood and Vine intersection where there are some big buildings with metal in them and probably some QRM too. Satisfying those three requirements is a matter of creating your own datum which you could with some kind of DGPS or in my case merging ground observations with published data.
There also are things that have two coordinates, different levels of accuracy, 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: [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] 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". 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 object.
Something that imho would also be useful, is a way to specify the data type - this could be optional. For the Geo example something like the following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data type from the keys and/or the lexical representation of the values, which would usually be a tough task.
Cheers, Andreas
1. https://meta.wikimedia.org/wiki/Wikidata/Development/Phase_2_JSON
On 17 October 2012 15:41, paul@ontology2.com wrote:
Yep, there are many reasons why geographic coordinates should be reified, largely because some people need more information than others.
Today all the people who got into geography in the last few years use WGS84 as a datum so it's fashionable to not specify any datum. That goes back to the bad old days when visual surveying was the only game in town so you could specify locations on an island relative to each other quite accurately but need to get a fix against the stars to know where the island as a whole was.
Even neogeography projects, however, sometimes need to specify a datum. A while back I was collecting a data set on the Hollywood Walk of Fame and the requirements there were: (i) stars get located on the right side of the street, (ii) stars get located in the right order, and (iii) stars get located on the right block. WGS84 (a standard GPS unit) isn't quite good enough to do these three things, particularly close to the Hollywood and Vine intersection where there are some big buildings with metal in them and probably some QRM too. Satisfying those three requirements is a matter of creating your own datum which you could with some kind of DGPS or in my case merging ground observations with published data.
There also are things that have two coordinates, different levels of accuracy, 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: [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] 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". 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 object.
Something that imho would also be useful, is a way to specify the data type - this could be optional. For the Geo example something like the following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data type from the keys and/or the lexical representation of the values, which would usually be a tough task.
Cheers, Andreas
I think that perhaps many of these issues have been dealt with already, and encapsulated in the GeoJSON standard: http://www.geojson.org/geojson-spec.html
So why not use this, or at least a subset of it?
Will Temperley