Based on the feedback so far I have frozen the datatype for time [1] and updated the datatype for coordinates. There are now two distinct members:
* precision: which actually means the precision in the representation, i.e. by the degree or arcsecond, etc., and which is used to calculate different representations
* dimension: which represents the "size" of the object / target area in meter, and which can be used to choose the scale for a map or to represent uncertainty about the coordinate [2]
The dimension parameter is based on the work of Max Semenik in the GeoData extension and recognized as a solution to the discussion that happened here on the list.
If you have any further comments on the datatype for coordinates, say so here. Otherwise I will move to quantities next :)
Cheers, Denny
[1] http://meta.wikimedia.org/wiki/Wikidata/Data_model#Dates_and_times [2] < http://meta.wikimedia.org/wiki/Wikidata/Development/Representing_values#Coor...
[3] https://www.mediawiki.org/wiki/Extension:GeoData#Glossary
2013/1/17 Denny Vrandečić denny.vrandecic@wikimedia.de:
Based on the feedback so far I have frozen the datatype for time [1] and updated the datatype for coordinates.
***CUT***
Sorry if my question appears silly, but I'll take the risk.
I assume this deals with "how the system recognizes the data we put in", and not with "how the user puts the data into the system", am I right?
In other words, will I/we be forced to use THIS way of inserting datas, or we'll put them they way we know/can and then the system will recalculate them in this way?
Exactly. This is about the backend and the API. The user will rather use a Widget maybe similar to this one:
http://localhost/~denny_WMDE/valueparser/time.html
2013/1/17 Luca Martinelli martinelliluca@gmail.com
2013/1/17 Denny Vrandečić denny.vrandecic@wikimedia.de:
Based on the feedback so far I have frozen the datatype for time [1] and updated the datatype for coordinates.
***CUT***
Sorry if my question appears silly, but I'll take the risk.
I assume this deals with "how the system recognizes the data we put in", and not with "how the user puts the data into the system", am I right?
In other words, will I/we be forced to use THIS way of inserting datas, or we'll put them they way we know/can and then the system will recalculate them in this way?
-- Luca "Sannita" Martinelli http://it.wikipedia.org/wiki/Utente:Sannita
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
I heard this URL might be better than the previous on most setups:
http://simia.net/valueparser/time.html
2013/1/17 Denny Vrandečić denny.vrandecic@wikimedia.de
Exactly. This is about the backend and the API. The user will rather use a Widget maybe similar to this one:
http://localhost/~denny_WMDE/valueparser/time.html
2013/1/17 Luca Martinelli martinelliluca@gmail.com
2013/1/17 Denny Vrandečić denny.vrandecic@wikimedia.de:
Based on the feedback so far I have frozen the datatype for time [1] and updated the datatype for coordinates.
***CUT***
Sorry if my question appears silly, but I'll take the risk.
I assume this deals with "how the system recognizes the data we put in", and not with "how the user puts the data into the system", am I right?
In other words, will I/we be forced to use THIS way of inserting datas, or we'll put them they way we know/can and then the system will recalculate them in this way?
-- Luca "Sannita" Martinelli http://it.wikipedia.org/wiki/Utente:Sannita
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
2013/1/17 Denny Vrandečić denny.vrandecic@wikimedia.de:
I heard this URL might be better than the previous on most setups:
Thanks. :)
On 17 January 2013 10:19, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:
If you have any further comments on the datatype for coordinates, say so here.
http://meta.wikimedia.org/wiki/Wikidata/Development/Representing_values#Coordinate
Nine decimal places seems excessive.
We can apply some rudimentary validation: no latitude or longitude values greater than 360, for instance (perhaps other criteria dependent on the coordinate system); latitude and longitude should have the same number of decimal places; trailing zeroes are significant and must not be discarded.
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Nine decimals is what is used for WAAS reference stations, which appear in Wikipedia.
< http://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#List_of_reference...
I actually also think it is a bit excessive, but it is there and looks legit. I'd rather support it than not (and save 20 MB of disk space).
Some of the validations sound useful (no values greater than 360), others a bit restrictive (same number of decimal places). I'd prefer the software to be rather lax than draconic (it *is* a wiki, after all). I agree about trailing zeros. They are covered by the precision parameter.
Thanks for the input! Cheers, Denny
2013/1/17 Andy Mabbett andy@pigsonthewing.org.uk
On 17 January 2013 10:19, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:
If you have any further comments on the datatype for coordinates, say so here.
<
http://meta.wikimedia.org/wiki/Wikidata/Development/Representing_values#Coor...
Nine decimal places seems excessive.
We can apply some rudimentary validation: no latitude or longitude values greater than 360, for instance (perhaps other criteria dependent on the coordinate system); latitude and longitude should have the same number of decimal places; trailing zeroes are significant and must not be discarded.
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Denny Vrandečić schrieb am 17.01.2013 11:19:
- dimension: which represents the "size" of the object / target area in
meter, and which can be used to choose the scale for a map or to represent uncertainty about the coordinate [2]
1) Can you explain, what are the motives for putting a dimension value directly down to the datatype level. I thought this is just another object property (or qualifier?) like the name, ISO-region, type, source, acquisition date.
2) IMO there is potential confusion between dim as the actual objects size (eg. 20 meter for a building) and dim as a value to control the map scale for showing this object (eg. 200 meter for a building which is really only 20 meter). Maybe it would be more clear if this thing is called "map scale" or the like.
Alex
2013/1/17 Alexrk alexrk2@yahoo.de
- Can you explain, what are the motives for putting a dimension value
directly down to the datatype level. I thought this is just another object property (or qualifier?) like the name, ISO-region, type, source, acquisition date.
In order not to loose the Dim-data that is already available from the Wikipedias, and to use this for scaling. It should really only describe the rough dimension. I would expect that a building would still have something like "area" or similar in its own property. Dimension is used for scaling and uncertainty.
- IMO there is potential confusion between dim as the actual objects size
(eg. 20 meter for a building) and dim as a value to control the map scale for showing this object (eg. 200 meter for a building which is really only 20 meter). Maybe it would be more clear if this thing is called "map scale" or the like.
Yes, maybe "dimension" is not a good term. "scale" could be better, but I can see in the GeoData extension that there was a shift from scale to dim, so I assume they might have reasons for that. I put Max Semenik into the discussion, and hope he can enlighten us a bit on it, since he was working on this for far longer than me.
Alex
http://de.wikipedia.org/wiki/**Benutzer:Alexrk2http://de.wikipedia.org/wiki/Benutzer:Alexrk2
______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
See https://en.wikipedia.org/wiki/Scale_(map) Scale (e.g. 1:10,000) is a paper cartography term, it makes little sense for computer displays especially for web view. So as a parameter that controls what should be shown on the map when an object is centered on, I chose dim(ension) which can be used objectively to calculate zoom, scale, magnification or whatever is used n a particular mapping system.
On Fri, Jan 18, 2013 at 3:40 PM, Denny Vrandečić < denny.vrandecic@wikimedia.de> wrote:
2013/1/17 Alexrk alexrk2@yahoo.de
- Can you explain, what are the motives for putting a dimension value
directly down to the datatype level. I thought this is just another object property (or qualifier?) like the name, ISO-region, type, source, acquisition date.
In order not to loose the Dim-data that is already available from the Wikipedias, and to use this for scaling. It should really only describe the rough dimension. I would expect that a building would still have something like "area" or similar in its own property. Dimension is used for scaling and uncertainty.
- IMO there is potential confusion between dim as the actual objects
size (eg. 20 meter for a building) and dim as a value to control the map scale for showing this object (eg. 200 meter for a building which is really only 20 meter). Maybe it would be more clear if this thing is called "map scale" or the like.
Yes, maybe "dimension" is not a good term. "scale" could be better, but I can see in the GeoData extension that there was a shift from scale to dim, so I assume they might have reasons for that. I put Max Semenik into the discussion, and hope he can enlighten us a bit on it, since he was working on this for far longer than me.
Alex
http://de.wikipedia.org/wiki/**Benutzer:Alexrk2http://de.wikipedia.org/wiki/Benutzer:Alexrk2
______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
In order not to loose the Dim-data that is already available from the Wikipedias, and to use this for scaling. It should really only describe the rough dimension. I would expect that a building would still have something like "area" or similar in its own property. Dimension is used for scaling and uncertainty.
Dimension of a building, locality, etc. is well understood, it is the size of location, without respect to shape. Location uncertainty is well understood. Confounding the two seems to introduce the inability of interpreting the information afterwards for many downstream processing cases. I would plead to support both dimension and uncertainty or none. --gregor