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
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
missing
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 store
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
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
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 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 of the
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 translated
On 19 December 2012 15:11, Daniel Kinzler daniel.kinz...@wikimedia.de 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
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 is a
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
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 marty...@graphity.org
Hey wikidatians,
occasionally checking
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 both
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
will be
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,
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 not the
On 19 December 2012 17:03, Daniel Kinzler daniel.kinz...@wikimedia.de 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
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.
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
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
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 a
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
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
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:
On 19 December 2012 20:01, jmccl...@hypergrove.com 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
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,
jmccl...@hypergrove.com wrote:
Hi Gregor - the root of the
misconception I likely have about significant
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 of
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
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
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
33 matches
Mail list logo
