[Wikidata-l] Data_model: Metamodel: Statement

2012-03-31 Thread Gregor Hagedorn
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,

Re: [Wikidata-l] Data_model: Metamodel: Wikipedialink

2012-04-01 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data_model: Metamodel: Wikipedialink

2012-04-04 Thread Gregor Hagedorn
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

[Wikidata-l] SNAK - assertion?

2012-04-04 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

2012-05-22 Thread Gregor Hagedorn
I added some comments on the wiki ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [wikidata-intern] Re: Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

2012-05-23 Thread Gregor Hagedorn
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?

Re: [Wikidata-l] [wikidata-intern] Re: Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

2012-05-24 Thread Gregor Hagedorn
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. ___

Re: [Wikidata-l] Wikidata Transclusions

2012-06-14 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Wikidata Transclusions

2012-06-14 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Wikidata Transclusions

2012-06-14 Thread Gregor Hagedorn
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

Re: [Wikidata-l] reworked storyboard for linking Wikipedia articles

2012-06-20 Thread Gregor Hagedorn
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

Re: [Wikidata-l] DBpedia usage in the bbc

2012-07-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] watching Wikidata changes that affect my wiki

2012-08-14 Thread Gregor Hagedorn
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

[Wikidata-l] changing wikidata-item properties with multilingual labels

2012-08-14 Thread Gregor Hagedorn
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

Re: [Wikidata-l] changing wikidata-item properties with multilingual labels

2012-08-14 Thread Gregor Hagedorn
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

Re: [Wikidata-l] changing wikidata-item properties with multilingual labels

2012-08-17 Thread Gregor Hagedorn
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

Re: [Wikidata-l] wikidata.org is live (with some caveats)

2012-10-30 Thread Gregor Hagedorn
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 .

Re: [Wikidata-l] wikidata.org is live (with some caveats)

2012-10-31 Thread Gregor Hagedorn
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

Re: [Wikidata-l] wikidata.org is live (with some caveats)

2012-11-01 Thread Gregor Hagedorn
But translatewiki.net can also help translate things like donation banners or policy pages, right? So, why not properties on Wikidata? I think that would be great! But it's more like translating page content, not system messages. I am intrigued by the idea as well. Yes, it is not system

Re: [Wikidata-l] Introduction and some questions on Wikidata

2012-11-14 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Wikidata license (was Introduction and some questions on Wikidata)

2012-11-16 Thread Gregor Hagedorn
I believe Avenue is referring here to the sui generis database right (in http://en.wikipedia.org/wiki/Directive_on_the_legal_protection_of_databases the section sui generis, not the one Copyright). This only exists in Europe. Database rights are relevant for new data imported into Wikidata by

Re: [Wikidata-l] Wikidata license (was Introduction and some questions on Wikidata)

2012-11-16 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Wikidata-l Digest, Vol 12, Issue 10

2012-11-20 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Suggestions

2012-12-09 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Wikidata license (was Introduction and some questions on Wikidata)

2012-12-10 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-18 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-18 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-18 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-18 Thread Gregor Hagedorn
(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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-20 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-21 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-21 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Data values

2012-12-21 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Update to time and space model

2013-01-08 Thread Gregor Hagedorn
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.

Re: [Wikidata-l] Update to time and space model

2013-01-08 Thread Gregor Hagedorn
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(?)

Re: [Wikidata-l] Is the inclusion syntax powerful enough?

2013-01-10 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Coordinate datatype -- update

2013-01-18 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Fwd: Todos for RDF export

2013-01-29 Thread Gregor Hagedorn
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

Re: [Wikidata-l] some good news about the future of Wikidata

2013-02-20 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-04 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-04 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Gregor Hagedorn
On 6 April 2013 23:05, Michael Hale hale.michael...@live.com wrote: No, it is not an example of a solution. If you wrote a property inclusion like that, and then someone changed the value on Wikidata, and then someone made an arbitrary edit somewhere else in the article, then when they save

Re: [Wikidata-l] entity vs Special:EntityData

2013-06-28 Thread Gregor Hagedorn
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

Re: [Wikidata-l] entity vs Special:EntityData

2013-06-28 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Tree Of Life

2014-12-18 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Tree Of Life

2014-12-19 Thread Gregor Hagedorn
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

Re: [Wikidata-l] Tree Of Life

2014-12-19 Thread Gregor Hagedorn
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