On 19/12/12 08:53, Gregor Hagedorn wrote:
I agree. What I propose is that the user interface supports entering
and proofreading "10.6 nm" as "10.6" plus "n" (= nano) plus "meter".
How the value is stored in the data property, whether as 10.6 floating
point or as 1.6e-8 is a second issue -- the la
I don't understand why 1.6e-8 is absolutly necessary for sorting and
comparison. PHP allows for the definition of custom sorting functions. If a
custom datatype is defined, a custom sorting/comparision function can be
defined too. Or am i missing some performance points?
On Wed, Dec 19, 2012 at 1
On 19.12.2012 08:53, Gregor Hagedorn wrote:
>> Displaying the numbers is another question. There I have to agree that it
>> always makes sense to also store a typical used unit for that type of data.
>
> I agree. What I propose is that the user interface supports entering
> and proofreading "10.6
On 19.12.2012 11:56, Friedrich Röhrs wrote:
> I don't understand why 1.6e-8 is absolutly necessary for sorting and
> comparison.
> PHP allows for the definition of custom sorting functions. If a custom
> datatype
> is defined, a custom sorting/comparision function can be defined too. Or am i
> mi
On 19.12.2012 08:34, Nikola Smolenski wrote:
>> Why would it make sense to have both? What is the altitude in the
>> geolocation good for? Is there an example in Wikipedia where it is or
>> would be used, and where a property of its own would not be better?
>
> While at it, why not separate longit
On 19 December 2012 11:56, Friedrich Röhrs wrote:
> I don't understand why 1.6e-8 is absolutly necessary for sorting and
> comparison. PHP allows for the definition of custom sorting functions. If a
> custom datatype is defined, a custom sorting/comparision function can be
> defined too. Or am i m
Hi,
Sorry for my ignorance, if this is common knowledge: What is the use case
for sorting millions of different measures from different objects?
The only use case i can think of where the sorting would be necessary is
lists like "cities in France by size" or "list of cars by fuel/per 100km".
Those
On 19.12.2012 14:34, Friedrich Röhrs wrote:
> Hi,
>
> Sorry for my ignorance, if this is common knowledge: What is the use case for
> sorting millions of different measures from different objects?
Finding all cities with more than 10 inhabitants requires the database to
look through all value
>> In addition to a storage option of the desired unit prefix (this may
>> be considered a original-prefix, since naturally re-users may wish to
>> reformat this).
>
> I see no point in storing the unit used for input.
I think you plan to store the unit (which would be meter), so you
don't want to
Hey wikidatians,
occasionally checking threads in this list like the current one, I get
a mixed feeling: on one hand, it is sad to see the efforts and
resources waisted as Wikidata tries to reinvent RDF, and now also
triplestore design as well as XSD datatypes. What's next, WikiQL
instead of SPARQ
On Wed, Dec 19, 2012 at 11:23 AM, Daniel Kinzler <
daniel.kinz...@wikimedia.de> wrote:
> On 19.12.2012 08:34, Nikola Smolenski wrote:
> > While at it, why not separate longitude and latitude? There are items
> that only
> > have one, f.e. http://en.wikipedia.org/wiki/Prime_meridian#
>
> I'd argue
On 2012-12-19 15:11, Daniel Kinzler wrote:
On 19.12.2012 14:34, Friedrich Röhrs wrote:
Hi,
Sorry for my ignorance, if this is common knowledge: What is the use case for
sorting millions of different measures from different objects?
Finding all cities with more than 10 inhabitants requir
On 19/12/12 12:23, Daniel Kinzler wrote:
On 19.12.2012 08:34, Nikola Smolenski wrote:
What I wanted to say. Additionally, in some cases historical units are not
accurate or accurately known, so possibly we won't even be able to make the
conversion.
I don't think we can sensibly support histori
On 19/12/12 15:33, Nikola Smolenski wrote:
On 19/12/12 12:23, Daniel Kinzler wrote:
I don't think we can sensibly support historical units with unknown
conversions,
because they cannot be compared directly to SI units. So, they
couldn't be used
to answer queries, can't be converted for display,
On 19/12/12 15:23, Martynas Jusevičius wrote:
triplestore design as well as XSD datatypes. What's next, WikiQL
instead of SPARQL?
How did you guessed? Oo
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/l
On Wed, Dec 19, 2012 at 2:32 PM, Marco Fleckinger <
marco.fleckin...@wikipedia.at> wrote:
>
> IMHO this should be part of a model. E.g. Altitudes are usually measured
> in metres or feet, never in km or yards. Distances have the same SI base
> unit but are measured also measured in km, depending o
On 19.12.2012 15:32, Marco Fleckinger wrote:
> Maybe we should make a difference between internal usage and visualization.
> Comparing meters with kilometers and feet is quite difficult, transcaling
> everything on visualization not.
Not maybe. Definitely. Visualization is based on user preference
On 19.12.2012 15:26, Avenue wrote:
> What about the North and South Poles?
I'm sure standard coordinate systems have a convention for representing them.
> Won't we need lots of units that are not SI units (e.g. base pairs, IQ points,
> Scoville heat units, $ and €) and can't readily be translate
On 19.12.2012 15:12, Gregor Hagedorn wrote:
>> I see no point in storing the unit used for input.
>
> I think you plan to store the unit (which would be meter), so you
> don't want to store prefixes, correct?
>
> Please argue why you don't see a point. You want to both the size of
> the universe,
Hi,
On 2012-12-19 15:12, Gregor Hagedorn wrote:
In addition to a storage option of the desired unit prefix (this may
be considered a original-prefix, since naturally re-users may wish to
reformat this).
I see no point in storing the unit used for input.
I think you plan to store the unit (wh
> No, altitudes are sometimes measured in km, at least once you get beyond the
> Earth's surface.
>
> From http://en.wikipedia.org/wiki/Hubble_Space_Telescope:
> Orbit height 559 km (347 mi)
>
> From http://en.wikipedia.org/wiki/Olympus_Mons:
> Peak 21 km (69,000 ft) above datum
Yes, but the first
On 19 December 2012 15:11, Daniel Kinzler wrote:
> If they measure the same dimension, they should be saved using the same unit
> (probably the SI base unit for that dimension). Saving values using different
> units would make it impossible to run efficient queries against these values,
> thereby
On 19.12.2012 16:47, Gregor Hagedorn wrote:
> Daniel confirms (in separate mail) that Wikidata indeed intends to
> convert any derived SI units to a common formula of base units.
>
> Example: a quantity like "1013 hektopascal", the common unit for
> meterological barometric pressure (this used to
>
> I don't think we can sensibly support historical units with unknown
> conversions,
> because they cannot be compared directly to SI units. So, they couldn't be
> used
> to answer queries, can't be converted for display, etc - they arn't units
> in any
> sense the software can understand. This i
On 2012-12-19 16:56, Daniel Kinzler wrote:
On 19.12.2012 16:47, Gregor Hagedorn wrote:
Daniel confirms (in separate mail) that Wikidata indeed intends to
convert any derived SI units to a common formula of base units.
Example: a quantity like "1013 hektopascal", the common unit for
meterologi
Martynas,
could you please let me know where RDF or any of the W3C standards covers
topics like units, uncertainty, and their conversion. I would be very much
interested in that.
Cheers,
Denny
2012/12/19 Martynas Jusevičius
> Hey wikidatians,
>
> occasionally checking threads in this list l
> These all pose the same problems, correct. At the moment, I'm very unsure
> about
> how to accommodate these at all. Maybe we can have them as "custom units",
> which
> are fixed for a given property, and can not be converted.
I think the proposal to use wikidata items for the units (that is b
On 19.12.2012 16:41, Marco Fleckinger wrote:
> I assume there's a table for usual units for different purposes. E.g.
> altitudes
> are displayed in m and ft. Out of that one of those is chosen by the user's
> locale setting. My locale-setting would be kind of "metric system", therefore
> it
> wil
When we speak about dimensions, we talk about properties right?
So when I define the property "height of a person" as an entity, i would
supply the SI unit (m) and the SI multiple (-2, cm) that it should be saved
in (in the database).
When someone then inputs the height in meters (e.g. 1.86m) it
On Wed, 19 Dec 2012, Denny Vrandečić wrote:
Martynas,
could you please let me know where RDF or any of the W3C standards covers
topics like units,
uncertainty, and their conversion. I would be very much interested in that.
NIST has created a standard in OWL: "QUDT - Quantities, Units, Dimensi
it is probably necessary to store the number of
significant decimals.
>
> Yes, that *is* the accuracy value i mean.
Daniel, please use correct terms. Accuracy is a defined concept and
although by convention it may be roughly expressed by using the number
of significant figures, that is n
> Ok, so my use of precision is not precise :) We are stumbling over words here.
> What would you call the level of detail used for presentation, if not
> "precision"?
I would call them significant digits, Wikipedia seems to prefer the
lemma http://en.wikipedia.org/wiki/Significant_figures -- bot
On 19 December 2012 17:03, Daniel Kinzler wrote:
> I'd have thought that we'd have one such table per dimension (such as "length"
> or "weight"). It may make sense to override that on a per-property basis, so
> 2300m elevation isn't shown as 2.3km. Or that can be done in the template that
> render
On 19 December 2012 17:03, Daniel Kinzler wrote:
> Indeed we do: https://wikidata.org/wiki/Wikidata:Glossary
>
> I use "precision" exactly like that: significant digits when rendering output
> or
> parsing intput. It can be used to *guess* at the values accuracy, but is not
> the
> same.
(I can
Denny,
you're sidestepping the main issue here -- every sensible architecture
should build on as much previous standards as possible, and build own
custom solution only if a *very* compelling reason is found to do so
instead of finding a compromise between the requirements and the
standard. Wikida
My philosophy is this: We should do whatever works best for Wikidata and
Wikidata's needs. If people want to reuse our content, and the choices
we've made make existing tools unworkable, they can build new tools
themselves. We should not be clinging to "what's been done already" if it
gets in the w
Martynas,
I think you misinterpret the thread. There is no discussion not to
build on the datatypes defined in http://www.w3.org/TR/xmlschema-2/
What we are doing is discussing compositions of elements, all typed to
xml datatypes, that shall be able to express scientific and
engineering requireme
Hi Gregor - the root of the misconception I likely have about
significant digits and the like, is that such is one example of a
rendering parameter not a semantic property. But maybe I've missed the
part of the discussion that cleanly separates these things into buckets,
and perhaps I have my he
I suspect what Martynas is driving at is that XMLS defines
**FACETS** for its datatypes - accepting those as a baseline, and then
extending them to your requirements, is a reasonable, community-oriented
procss. However, wrapping oneself in the flag of "open development" is
to me unresponsive to
Wow, what a long thread. I was just about to chime in to agree with Sven's
point about units when he interjected his comment about blithely ignoring
history, so I feel compelled to comment on that first. It's fine to ignore
standards *for good reasons*, but doing it out of ignorance or gratuitous
For convertion between units, why not using the already built-in system of
"Languages Translation" ?
Hence, if people gives the value in Meter someone else could give it in
Foot with the right precision and there will just be a link of
"Translation" between those two
Same apply for Units being gi
Here's a suggestion. Property names for numeric information seem to
be on the table -- these should be viewed systematically not
haphazardly.
If all text properties had a "dotted" lower-case name,
life would be simpler in SMW land all around and maybe Wikidata land
too. All page names have an
It would be much more easier if this could be done automatically, so
everybody could set there preferred data system SI or CGS or what ever.
Sk!d
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki
Using the dotted notation, XSD datatype facets such as below can be
specified easily as properties using a simple colon:
Property:
.anyType:equal - (sameAs equivaluent) redirect to page/object with
actual numeric value
Property: .anyType:ordered - a boolean property
Property: .anyType:bound
On 19 December 2012 20:01, wrote:
> Hi Gregor - the root of the misconception I likely have about significant
> digits and the like, is that such is one example of a rendering parameter
> not a semantic property.
It is about semantics, not formatting.
In science and engineering, the number of s
totally agree - hopefully XSD facets provide a solid start to
meeting those concrete requrements - thanks.
On 19.12.2012 14:09,
Gregor Hagedorn wrote:
> On 19 December 2012 20:01,
wrote:
>
>> Hi Gregor - the root of the
misconception I likely have about significant digits and the like, is
> totally agree - hopefully XSD facets provide a solid start to meeting those
> concrete requrements
they don't. They allow to define derived datatypes and thus apply to
the datatype, not the measurement. Different measurements of the same
datatype may be of different precision. --gregor
For me the question is how to name the precision information. Do not
the XSD facets "totalDigits" and "fractionDigits" work well enough? I
mean
.number:totalDigits contains a positive power of ten for
precision
.number:fractionDigits contains a negative power of ten for
precision
The use o
I think that Tom Morris tragically misunderstood my point, although that
was likely helped by the fact that, as I've insinuated already, the many
standards and acronyms being thrown about are largely lost on me.
My point is not "We can just throw everything out because we're big and
awesome and ha
The NIST ontology defines 4 basic classes that are great:
_qudt:QuantityKind [11]_, _qudt:Quantity [12]_, _qudt:QuantityValue
[13]_, _qudt:Unit [14]_
but the properties set leaves me a bit
thirsty. Take "Area" as an example. I'd like to reference properties
named .ft2 and .m2 so that, for in
Finally, we have the rest of the Wikimania videos available, including this
one of the Wikidata panel in the "sister projects" session:
http://www.youtube.com/watch?v=xi8Yf9c3wXg (starts at 22:45)
The other Wikidata session is here:
http://www.youtube.com/watch?v=05HxNwxiNZ0
Cheers,
Katie
--
If one has time to read prior art, I'd suggest giving the Health Level
7 v3.0 Data Types Specification
http://amisha.pragmaticdata.com/v3dt/report.html a look.
Of course HL7 has a lot of things to worry about which are off topic
for us, starting with a prior completely different version of the
sta
52 matches
Mail list logo
