On 18 December 2014 at 20:52, Lydia Pintscher lydia.pintsc...@wikimedia.de
wrote:
On Thu, Dec 18, 2014 at 8:38 PM, Gregor Hagedorn g.m.haged...@gmail.com
wrote:
https://tools.wmflabs.org/tree-of-life/
is problematic at first looks.
Bacteria, prokaryotes, monera and eukaryoates as sister
may be wrong) a mashup-error occurring when uncritically combining data
from
different sources, each source being internally consistent and correct.
This
may be something that needs to be addressed by the tool.
Good point, yes. Any ideas how?
Perhaps just help understanding this
https://tools.wmflabs.org/tree-of-life/
is problematic at first looks.
Bacteria, prokaryotes, monera and eukaryoates as sister groups on the same
level?
Prokaryotes contain as only subtaxon Archaea (but no bacteria)?
Also, the mixed use of scientific and common names (variously as singular
or
But the problem seems to be that http://www.wikidata.org/wiki/Q1000
actually seems to be an information resource, i.e. under this URI html
content is directly being returned (rather than being http 303
redirected).
Also, checking with http://validator.linkeddata.org/vapour I received
an error
But the problem seems to be that http://www.wikidata.org/wiki/Q1000
actually seems to be an information resource, i.e. under this URI html
content is directly being returned (rather than being http 303
redirected).
Also, checking with http://validator.linkeddata.org/vapour I received
an error
This is great, but the solution I saw (i.e.
{{#property:population|current-value=30900}}) makes the whole
Wikidata absolutely useless.
(I asked Luca back about this, and perhaps one point is that the term
current is too easily misunderstood. The point is not that wikidata
should have such
On 4 April 2013 22:23, Michael Hale hale.michael...@live.com wrote:
trench, then I just want to update it on Wikidata, and then every article
that references it will be updated. I don't want to have to update it on
Wikidata and then go do a null edit on every article that uses that
My concern is, that the Wikidata editors, those not with random
editing behavior, but those who are curators/caretakers of specific
pages, experience a disempowerment, because they loose control.
I view the decision to inform about wikidata changes only in the
short-lived recentchanges, but not
On 5 April 2013 20:05, Michael Hale hale.michael...@live.com wrote:
The thing to remember is that the history of a page is the history of the
wiki markup for the page, not the history of the rendered HTML. It would be
misleading if edits were shown in the markup history for an article each
On 5 April 2013 21:41, Michael Hale hale.michael...@live.com wrote:
Well, I could make a view that shows the diff of a Wikipedia article stacked
on top of the diff for the corresponding Wikidata item on my computer in a
few minutes. But diffs can be very long sometimes, so there would be a lot
On 5 April 2013 23:19, Michael Hale hale.michael...@live.com wrote:
So you agree that it is more important to reduce clutter than to add
functionality that very few people use?
No, I strongly disagree with this. I think the functionality of being
able to curate the page Wikipedia editors care
On 5 April 2013 23:53, Michael Hale hale.michael...@live.com wrote:
But you do agree that it is easier to curate articles by updating one value
in a database than updating the value separately everywhere it appears?
Absolutely.
But in my experience Wikipedia editors care about the product of a
when templates (or, in the case of wikidata, properties) get deleted or
renamed.
Nobody has come up with a good solution yet.
I think we did discuss a simple, working solution: Saving the value
together with the Wikipedia page.
The major argument against that was: it is a waste of storage to
don't see what value we'd gain from storing that extra metadata. Every
scenario I can think of where you care about past states of the database is
already handled by the compare selected revisions feature.
If that is so simple, can the {{#property:xxx}} call in a wikipedia
simply resolve to
2013/2/20 Lydia Pintscher lydia.pintsc...@wikimedia.de:
http://blog.wikimedia.de/2013/02/20/the-future-of-wikidata/
Very good, congratulations!
With great respect for your work,
Gregor
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
Some of our insights into the SMW RDF export (which we found to be
difficult to configure and use):
1. Probably most relevant: total lack of support for xml:lang, which would
have been essential to our purposes.
Wikidata should be planned with support for language in mind.
2. We also found that
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
I like it.
For multilingual wikis like commons a presumably fairly simple
extension it might be valuable to support besides #property also
#propertylabel and #itemlabel, only with the id and of parameter. I
think this does not really to complexity much.
Gregor
ON COORDINATES:
a) what you describe is more specific than a geolocation (which may be
expressed by other means than coordinates). I suggest to give the data
type the more specific name:
geocoordinates
b) with respect to precision: I don't understand the reasoning to
stick this to degrees.
geocoordinates
Yep, agreed. Or just coordinates.
yes, probably better without a geo if it shall work for moon or mars as well.
However, http://en.wikipedia.org/wiki/Coordinate_system is far broader
term. But I cannot find a correct superclass term for
Geographic/Selenographic/Martiographic(?)
Hm the second one is only relevant for output.
I think this is a fundamental misunderstanding: The original one is
not for output but is the primary value for interpretation, for
understanding whether a value in Wikidata is correct of fake, or a
software conversion error, or what. If I want to
I don't like significant digits because it depends on the writing system
(base
10). I'd much rather express this as absolute values.
Yes, I would like too. What I argue is that the problem is that you
simply in 99.9 % (not a researched of number of course) of cases
simply don't know more
On 21 December 2012 19:36, jmccl...@hypergrove.com wrote:
The xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive and
xsd:maxExclusive facets are absolute expressions not relative +/-
expressions, in order to accommodate fast queries. These four facets permit
specification of ranges with an
I believe there are a lot of dangerous assumptions on
http://simia.net/valueparser/
First: there is no indication in a number that it is _not_ endlessly precise.
Apostles = 12
has no uncertainty, representing it as
12 ± 1 is wrong, but also 12 ± 0.5 is wrong.
The same applies to a number like
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
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
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
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
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
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
It would be possible and very flexible, and certainly more powerful than the
current system. But we would loose the convenience of having one date, which
we need for query answering (or we could default to the lower or upper
bound, or the middle, but all of these are a bit arbitrary).
I
Now, I don't think we need or want ranges as a data type at all (better have
separate properties for the beginning and end).
I am afraid this will then put a heavy burden on users to enter,
proofread, and output values. Data input becomes dispersed, because
the value 18-25 cm length has to be
I don't see this as a big overhead. It is more a problem for ordering,
but internally, wikidata could store a midpoint value for intervals
where no explicit central value is given, and use these for ordering
purposes.
Well, I would call that mid point simple the value, and the range would be
(ASIDE: Regarding presentation: it is not always algorthmically eay
whether to present 0.01 m as 1 * 10e-14 or a 10 fm = 10 *
10-15. In a scientific context, only the SI steps should be used, in
another context the closest decimal may be appropriate.)
But floating point numbers
Marco wrote:
So I assume that single facts (or database items) are not copyrightable just
like single words. Only the database (or even a view?) as a selection and
arrangement of various items is copyrightable.
Yes, a database may be copyrightable, if the creativity in selecting
and arranging
If I'm not mistaken this is what we plan to do. The current system we're
using for the language links can certainly handle it, as it's not WP
specific.
that would be great!
On top of my wish list are the Wiktionaries, since most of the
entities needed to use Wikidata for descriptive knowledge
Hi Michael,
(I cannot speak on behalf of WMF, this is not official)
The plans for Wikidata are to carefully attribute sources of data,
which comes much closer to what you need, i.e. 3rd party data are
separatable. For the start the CC0 license has been chosen which gives
you unlimited re-use
Just to clarify, my concern is about externally made databases, regardless
of whether these are imported directly into Wikidata, or have been
incorporated into Wikipedia first and imported into Wikidata from there. For
example, the population data in Wikipedia's list of ceremonial English
First of all the priority lies on data already present on Wikipedia. Wikidata
should not be a data storage for everything structured in the world, so we
should first start to transfer data already present on Wikipedia to Wikidata.
External data-sources will be interested as well and for sure
Changing the language does not really work, the title of the item
pages remain in English.
http://www.wikidata.org/wiki/Special:RecentChanges?setlang=de
Did it have a German label or just a language link to dewp?
Probably it did not have a manually entered label at the time. After
my post it
Great work, my congratulations!
---
Some first impressions:
Changing the language does not really work, the title of the item
pages remain in English.
http://www.wikidata.org/wiki/Special:RecentChanges?setlang=de
-
(Unterschied | Versionen) . . Sweden (Q34); 17:48 .
You are right, I mixed them up (that comes from not checking).
The usecase for monolingual text are a bit rare, and I am thinking of
things like official motto (which is usually not translated),
I think if it is only usually not, but sometimes indeed translated,
using multilingual for the
I think the topic is relevant for the Wikidata editing UI.
At the hackathon in Berlin we had discussions about a chain of
fallback languages. Have reworked and added some potential
user-interface behaviour to
http://meta.wikimedia.org/wiki/Wikidata/Notes/Language_fallback
Gregor
A city has a Wikipedia page and a corresponding Wikidata-item-page.
One of the item properties is Property:City_mayor.
If the mayor changes, and both have their own pages/items
(http://de.wikipedia.org/wiki/Eberhard_Diepgen to
http://de.wikipedia.org/wiki/Klaus_Wowereit for
But humans (and other entities) should not be represented by strings
in the system, but by items.
I wonder whether this would not be too inflexible. It would burden the
use of wikidata with the responsibility to determine entity-identity
in all cases where only a name-string is known.
In the
I don't mean to spin this out into a tangent about Drupal.
Me neither, my discussion point here is: There are advantages for
opaque (like http:something.org/node123456) and nonopaque
(http:something.org/Bonn,_Northrhine-Westfalia,_Germany) URI/IRI
identifiers.
In the light of the use-case of
I added some comments on
http://meta.wikimedia.org/wiki/Talk:Wikidata/Development/Storyboard_for_linking_Wikipedia_articles_v0.2
Gregor
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
While I agree that it is desirable to support simple, preformatted
Infoboxes that can, with minimal effort be re-used in a large number
of language versions of Wikipedia, I strongly disagree with the demand
to make this the only choice.
I think the present Wikidata approach to allow local
On 14 June 2012 12:33, Gerard Meijssen gerard.meijs...@gmail.com wrote:
Finally, when Wikidata provides data and info boxes, it does not mean that
any project is compelled to use it. As Wikidata matures, it will become
increasingly clear that it is not the best practice.
that may be, but
Gregor, I'm a bit confused -- are you talking about the transclusion design
approach in this statement?
Yes, in the sense that it demands to be the only access to wiki data
content in a Wikipedia.
because, if so, I'd think there'd be a number of
infobox styles that can be selected by an
This seems to be everyone's preference, even though it feels kind of icky to
me.
Oh, well :) I'll rework the draft on that basis soon.
I look forward to it. Maybe it runs against some wall, but then we
have a better basis for comparison.
___
On 23 May 2012 13:19, Daniel Kinzler daniel.kinz...@wikimedia.de wrote:
On 23.05.2012 13:14, Nikola Smolenski wrote:
If we assume that in practice #data-template is usually going to be wrapped
into
a template, what's the point of having it at all? Do you see any technical
reasons for it?
I added some comments on the wiki
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata can (and probably will) store information about each moon of
Uranus, e.g., its mass. It does probably not make sense to store the mass of
Moons of Uranus if there is such an article. It does not help to know that
the article Moons on Uranus also talks (among other things) about some
Would the Word assertion be a possible replacement for the neonym Snak?
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 1 April 2012 13:04, Markus Krötzsch markus.kroetz...@cs.ox.ac.uk wrote:
This is a valid point. It is intended to address this as follows:
* Wikidata items (our content pages) will be in *exact* correspondence to
(zero or more) Wikipedia articles in different languages.
* Differences in
Some initial ideas on the statement. I realize that this is not
priority in the first phase, but perhaps on the wiki a place could be
created to collect some thoughts like those below?
http://meta.wikimedia.org/wiki/Wikidata/Notes/Data_model#The_Metamodel explains:
Statement = (StatementID,
58 matches
Mail list logo
