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(a)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(a)mes-semantics.com · Web
________________________________________________________________
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
________________________________________________________________