Wikidata June 2014

wikidata@lists.wikimedia.org

43 participants
36 discussions

[Wikidata-l] Weekly Summary #112
by John Lewis 09 Jun '14

09 Jun '14

Here is the latest weekly summary for Wikidata! As always; feedback is appreciated :) Discussions - Closed RfAs: FakirNL <https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrat…> (Successful), Josve05a <https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrat…> (Unsuccessful) - Open RfAs: Taketa <https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrat…> , Jianhui67 <https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrat…> , 555 <https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrat…> Events <https://www.wikidata.org/wiki/Wikidata:Events>/Press/Blogs <https://www.wikidata.org/wiki/Wikidata:Press_coverage>[edit <https://www.wikidata.org/w/index.php?title=Wikidata:Status_updates/2014_06_…> ] - Magnus Manske writes about how the Wikidata Game has developed over two weeks <http://magnusmanske.de/wordpress/?p=213> Other Noteworthy Stuff - User:Thepwnco <https://www.wikidata.org/wiki/User:Thepwnco> is working on some Wikidata:Tours <https://www.wikidata.org/wiki/Wikidata:Tours> during for a FOSS project <https://www.mediawiki.org/wiki/Feed_the_Gnomes_-_Wikidata_Outreach> Did you know? - Newest properties: Italian Chamber of Deputies ID <https://www.wikidata.org/wiki/Property:P1341>, eye color <https://www.wikidata.org/wiki/Property:P1340>, number of injured <https://www.wikidata.org/wiki/Property:P1339>, EPSG ID <https://www.wikidata.org/wiki/Property:P1338> Development - Did a lot of cleanup in Wikibase.git - thePHPcc thinghy - Released DataValues Time 0.6 - Add time support to QueryEngine - Release Wikibase DataModel 0.8 <https://github.com/wmde/WikibaseDataModel/blob/master/RELEASE-NOTES.md#vers…> - Worked on the way deleted items are formatted (= shown on other items) - Released ValueView 0.6, which includes refactoring of the entity suggester code, bug fixes. - Fix issue with entering strings (newline character sometimes got added and then cause api error) - Fix bug 64658 <https://bugzilla.wikimedia.org/show_bug.cgi?id=64658> (date adjustment dialogue doesn't show up on Firefox with Monobook skin) - Fix bug 64887 <https://bugzilla.wikimedia.org/show_bug.cgi?id=64887> (issue with display of globecoordinate when precision does not match predefined precisions) See current sprint items <https://bugzilla.wikimedia.org/buglist.cgi?list_id=218716&resolution=---&re…> for what we’re working on next. You can view the commits currently in review here <https://gerrit.wikimedia.org/r/#/q/(+project:mediawiki/extensions/Wikibase+…> and the ones that have been merged here <https://gerrit.wikimedia.org/r/#/q/(+project:mediawiki/extensions/Wikibase+…> . You can see all open bugs related to Wikidata here <https://bugzilla.wikimedia.org/buglist.cgi?emailcc1=1&list_id=151540&resolu…> Monthly Tasks - Fix a format or content violation <https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violatio…> for the academic degree (P512) <https://www.wikidata.org/wiki/Property:P512> property - Hack on one of these <https://bugzilla.wikimedia.org/buglist.cgi?keywords=need-volunteer%2C%20&ke…> . - Help fix these items <https://www.wikidata.org/wiki/Wikidata:The_Game/Flagged_items> which has been flagged using Wikidata - The Game. - Help develop the next summary here! <https://www.wikidata.org/wiki/Wikidata:Status_updates/Next> - Contribute to a Showcase item <https://www.wikidata.org/wiki/Wikidata:Showcase>

3 2

[Wikidata-l] WIkiquote Phase 2
by John Lewis 08 Jun '14

08 Jun '14

Hey everyone, Lydia is focusing on some Outreach tasks at the moment so I have volunteered to make this announcement. The development team are currently planning to enable Phase 2 for all language editions of Wikiquote on June 10th. For those who don't know, Phase 2 is enabling data access from Wikiquote to Wikidata and vice versa. Lydia also wants to thank all users who helped make the Phase 1 deployment a successful launch on all Wikiquote languages. Thanks, John Lewis

2 1

Re: [Wikidata-l] What is the point of labels?
by Michael Erdmann 07 Jun '14

07 Jun '14

David, I am not familiar with Wiktionary and its datamodel. But your summary looks like SKOS [1] would be a good fit. Also for your proposal to extend the Wikidata datamodel. In short, SKOS distinguishes between concepts (they carry the semantics ~ Q item) and labels (they are, well, just labels). Concepts and labels are connected via a handful of properties, e.g. skos:prefLabel or skos:altLabel. In ordinary SKOS labels are simple strings but in SKOS-XL (also part of the spec) they are objects (and thus can have properties and relations to other labels (or anything) etc.). Furthermore, SKOS is extensible, i.e. it is based on RDF and one can define subclasses of skos:concept and skos-xl:label and one can define subproperties of skos:prefLabel and skos:altLabel with particular semantics, which might be relevant for Wikidata. With this some label-like wikidata-properties could be defined as subproperties of, say, skos:altLabel to have them show up in pick lists etc. just my 2 cents, michael [1] The spec: http://www.w3.org/TR/skos-reference/ The primer: http://www.w3.org/TR/2009/NOTE-skos-primer-20090818 On 06.06.2014 14:00, wikidata-l-request(a)lists.wikimedia.org wrote: > Message: 3 > Date: Thu, 5 Jun 2014 16:28:30 +0200 > From: David Cuenca<dacuetu(a)gmail.com> > To: "Discussion list for the Wikidata project." > <wikidata-l(a)lists.wikimedia.org> > Subject: [Wikidata-l] What is the point of labels? > Message-ID: > <CAJBSGSoO60AsQbUFkmefqvpE_miwFYxO2vs8jSeq0p0D82JChg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > When I drafted the functional structure that is appearing on items [1], > Gerard pointed out that it is drifting into the lexical area. That made me > think that while useful to have lexical data as an independent item as we > discussed last year for Wiktionary, the current structure "q item <label> > string" doesn't seem to be compatible with that wish, or at least it would > be more difficult to maintain the same label twice. And it is not just one > label per item, there are many, and each one might have different lexical > properties. > > For more efficiency, it seems that we would need statements like "q item > <label> lexical item" to reflect that separation, but that adds further > complexity, because according to the latest Wikidata:Wiktionary proposal > [2], the "lexical item" (W) also contains senses/meanings (S). This is > recurrent, as we already have Q items as the basis for meaning... or at > least a concept that is more or less shared among languages. The only > difference between "Q items" and the proposed "S items" is that S items > represent only one of the lexeme meanings for one particular language, but > other than that they have the same nature as Q items (it should be possible > to add "subclass of" and other statements to them). > > Labels, aliases, and name properties are just normal statements where one > of them is preferred, I have been wondering why don't we treat them as > such... That way we could have some coherence, and have both "Q items" and > "S items" as the units of meaning/sense and later on move the labels > (lexemes), which now are strings, to the lexical items ("W items" in the > example on the page Wikidata:Wiktionary). > > Summing up, labels in their current form make complete sense now, but when > considered together with lexical information, it seems that it would be > convenient to treat all of them as statements that later on could link with > "W items". And as Joe pointed out, there are many more properties that are > equivalent to a label, just more specific, and that now don't show up in > the suggester, nor up above of the page where they should. > > I know that Wiktionary is still in the future and that there are many other > priorities on the way, however since the representation of the items is > being re-considered, I think it is a good moment to think about how to move > little by little in the right direction. I also would like to point out > that by keeping lexical information in wikidata, its complexity is going to > increase inevitably. If new users already struggling to understand it now, > I cannot imagine how will they cope with added elements... > > Micru > > [1]http://lists.wikimedia.org/pipermail/wikidata-l/2014-June/003941.html > [2]https://www.wikidata.org/wiki/Wikidata:Wiktionary -- Dr. Michael Erdmann | erdmann(a)diqa-pm.com | +49 151 6140 1790 DIQA Projektmanagement GmbH | Pfinztalstr. 90 | 76227 Karlsruhe, Germany Handelsregister: Amtsgericht Mannheim HRB 715454 | USt-IdNr: DE283037270 Geschäftsführer: Dr. Michael Erdmann, Dipl.-Wirtsch.-Inf. Daniel Hansch This email may contain confidential information. If you are not the intended recipient please notify the sender immediately and delete this email. Any unauthorized copying, disclosure or distribution of this email is strictly forbidden.

7 18

[Wikidata-l] What is the point of properties?
by David Cuenca 06 Jun '14

06 Jun '14

Since the very beginning I have kept myself busy with properties, thinking about which ones fit, which ones are missing to better describe reality, how integrate into the ones that we have. The thing is that the more I work with them, the less difference I see with normal items.... and if soon there will be statements allowed in property pages, the difference will blur even more. I can understand that from the software development point of view it might make sense to have a clear difference. Or for the community to get a deeper understanding of the underlying concepts represented by words. But semantically I see no difference between: cement (Q45190) <emissivity (P1295)> 0.54 and cement (Q45190) <emissivity (Q899670)> 0.54 Am I missing something here? Are properties really needed or are we adding unnecessary artificial constraints? Cheers, Micru

9 21

[Wikidata-l] What is the point of labels?
by David Cuenca 06 Jun '14

06 Jun '14

When I drafted the functional structure that is appearing on items [1], Gerard pointed out that it is drifting into the lexical area. That made me think that while useful to have lexical data as an independent item as we discussed last year for Wiktionary, the current structure "q item <label> string" doesn't seem to be compatible with that wish, or at least it would be more difficult to maintain the same label twice. And it is not just one label per item, there are many, and each one might have different lexical properties. For more efficiency, it seems that we would need statements like "q item <label> lexical item" to reflect that separation, but that adds further complexity, because according to the latest Wikidata:Wiktionary proposal [2], the "lexical item" (W) also contains senses/meanings (S). This is recurrent, as we already have Q items as the basis for meaning... or at least a concept that is more or less shared among languages. The only difference between "Q items" and the proposed "S items" is that S items represent only one of the lexeme meanings for one particular language, but other than that they have the same nature as Q items (it should be possible to add "subclass of" and other statements to them). Labels, aliases, and name properties are just normal statements where one of them is preferred, I have been wondering why don't we treat them as such... That way we could have some coherence, and have both "Q items" and "S items" as the units of meaning/sense and later on move the labels (lexemes), which now are strings, to the lexical items ("W items" in the example on the page Wikidata:Wiktionary). Summing up, labels in their current form make complete sense now, but when considered together with lexical information, it seems that it would be convenient to treat all of them as statements that later on could link with "W items". And as Joe pointed out, there are many more properties that are equivalent to a label, just more specific, and that now don't show up in the suggester, nor up above of the page where they should. I know that Wiktionary is still in the future and that there are many other priorities on the way, however since the representation of the items is being re-considered, I think it is a good moment to think about how to move little by little in the right direction. I also would like to point out that by keeping lexical information in wikidata, its complexity is going to increase inevitably. If new users already struggling to understand it now, I cannot imagine how will they cope with added elements... Micru [1] http://lists.wikimedia.org/pipermail/wikidata-l/2014-June/003941.html [2] https://www.wikidata.org/wiki/Wikidata:Wiktionary

1 1

[Wikidata-l] Item metadata
by David Cuenca 05 Jun '14

05 Jun '14

Continuing with the discussion of last week about the nature of properties I follow with my personal crusade to foster a better understanding of Wikidata (which sometimes means asking difficult questions :)). This time I ask about items, or concepts for that matter. To start with I cherry-pick a very insightful question posed by Markus last week, that unfortunately I left unanswered: "The main question is "Did the reference say that pianos are instruments?" but not "Did the reference say pianos are instruments because of the definition of 'piano'?" Therefore, we don't need to put this information in our labels." To my mind that is a problem that, as the chicken and the egg, can be settled with just a word: emergence. There is no such thing as a piano or a concept of a piano. But both of them, concept and object, co-evolved over time and now we recognize certain objects as "pianos". Timeline: https://en.wikipedia.org/wiki/Piano#History There have been so many innovations upon innovations, versions, and even name changes, that what we call now "piano" is very different from what it was long ago. Same can be said about other concepts like "country of citizenship", which is not a valid concept when talking about historic people. When we are creating an item we are capturing a moment of time of the past, according to a source in a different past. Eventually this item might change its label, change its meaning, or become obsolete. So when I look in Wikidata for: - a way to reflect label changes over time: yes, that will be possible with the mono-lingual datatype + qualifiers, creating a property "label" - a way to reflect that the concept is obsolete: perhaps it could be reflected with start/end date - a way to indicate a different item with a related meaning: it can be done with properties This information is not about the item itself, but we treat it as other statements. In my opinion these kind of statements are different (as labels, or descriptions), since they don't refer to the represented entity, but to the container that represents the entity. Like the walls of a bubble. I can imagine that there will be some confusion between labels that can accept qualifiers, other than don't, and aliases that can edited in one language but not in other, and all this not grouped with other statements that belong to the same metadata group. So I candidly ask: does it make sense to treat item metadata statements just as any other statement? Would it bring more confusion or less? Cheers, Micru

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikidata June 2014