Re: [Wikidata] weekly summary #201

[Ricordisamoa]

Il 21/03/2016 12:54, Lydia Pintscher ha scritto:

Hey everyone :)

Here's your summary of what's been happening around Wikidata over the 
past week:



  Discussions

  * New request for comments: Reforming the property creation process




  Events /Press/Blogs
  

  * Past: Color History with the Smithsonian!


  * Past: Accessibility Edit-a-Thon at the DC Public Library

  * Past: Admin meetup of the German-language Wikipedia

  * Automatic Extraction of Knowledge from Biomedical literature


  * Identifying problematic statements in Wikidata via multi-level
modeling theory

  * Wikidata as a semantic framework for the Gene Wiki initiative

  * Adding disclosures to Wikidata with Bioclipse




  Other Noteworthy Stuff

  * Dutch language Wikipedia has a consistently low number of articles
unconnected to Wikidata: Duplicity statistics for nlwiki


  * MusicBrainz now uses Wikidata to fetch images for their entities

  * The query service is now linked in the sidebar
  * Mix'n'match  has new
catalogs among them TED speakers
  * Maarten made some reports to make it easier to connect paintings
on Wikidata with images on Wikimedia Commons




I think it should be 
https://www.wikidata.org/wiki/User:Multichill/Image_suggestions instead.




  Did you know?

  * Newest properties
: BBFC
rating , German tax
authority ID , ISO
9362 SWIFT/BIC code
, DNF person ID
, PASE ID
, MetroLyrics ID
, MEK ID
, Companies House ID
, Site of Special
Scientific Interest (England) ID
, ISO 15924 numeric
code , Hungarian
company ID , SHOWA
ID , formatterURL
for Wikidata ID ,
World Heritage criteria (2005)
, TED talk ID
, TED topic ID
, TED speaker ID

  * Query examples: distribution of public art by place




  Development

  * The query service now has Ctrl+enter as a shortcut to run a query
  * Started working on improving input for geocoordinates and dates
(changing the advanced settings)
  * Worked on database performance improvements for the client
(Wikipedia and co) (phabricator:T125838
)
  * Experimenting with arbitrary access for Wikimedia Commons on
http://commons.wikimedia.beta.wmflabs.org
  * Converted more identifiers from string datatype to identifier datatype
  * Worked on improved localization of dates that are very far in the
past or future (phabricator:T127820
)
  * Fixed undo actions going through abuse filter (phabricator:T126861
)
  * Fixed issues in the query service with Internet Explorer 11
  * Improved query service display on s

Re: [Wikidata] identifier datatype is available and conversion is in progress

[Ricordisamoa]

The best list of changes I can find is 
https://www.wikidata.org/wiki/Special:Contributions/Maintenance_script?namespace=120.


Il 17/02/2016 19:11, Lydia Pintscher ha scritto:

Hey folks :)

We have enabled the new datatype for identifiers now. New properties 
will start showing up at 
https://www.wikidata.org/wiki/Special:ListProperties/external-id. As 
announced we will also start converting existing properties with 
datatype string that should be external identifiers. We will start 
with the first eleven from 
https://www.wikidata.org/wiki/User:Addshore/Identifiers/0. We will do 
more over the coming days. There are still a lot of properties to go 
through so please help with that so we can get this over with quickly 
to cause minimal disruption to 3rd parties relying on our data. You 
will also see the identifiers that are already converted moving to a 
new section at the bottom of the item pages. This might need a purge 
still though to clear the cache.


Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de 

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg 
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das 
Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] next Wikidata office hour on January 21st

[Ricordisamoa]

https://webchat.freenode.net/?channels=#wikimedia-office

Il 21/01/2016 17:58, ja...@j1w.xyz ha scritto:

Is this IRC or WebChat?

Thanks,
James Weaver

On Thu, Jan 21, 2016, at 11:10 AM, Lydia Pintscher wrote:

On Mon, Dec 28, 2015 at 2:17 PM, Lydia Pintscher
 wrote:

Hey folks :)

I'll be doing another office hour to talk about all things Wikidata.
As usual I'll give an overview of the past 3 months and what's ahead.
It'll be in #wikimedia-office on Freenode. It'll be on January 21st at
17:00 UTC. For your timezone please see
https://www.timeanddate.com/worldclock/fixedtime.html?hour=17&min=00&sec=0&day=21&month=01&year=2016.

Hey folks :)

Just a reminder that this is happening in a bit less than an hour.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] GerardM's made 2 *million* edits

[Ricordisamoa]

Can I say I'm a little worried by all these 'user' accounts behaving 
like bots? They make spotting their 'real' edits very hard.


Il 06/01/2016 00:33, Asaf Bartov ha scritto:

Hi there.

I thought I'd take a moment to note our colleague GerardM has made his 
*2 millionth* edit to Wikidata some 9 edits ago.


Congratulations, Gerard! Keep up the good work! :)

   A.
--
Asaf Bartov
Wikimedia Foundation 

Imagine a world in which every single human being can freely share 
in the sum of all knowledge. Help us make it a reality!

https://donate.wikimedia.org


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Programming question

[Ricordisamoa]

Hi,
Here  you 
can see many Wikidata-related web apps. Some of them have links to the 
source code.
If you're "completely new to programming", your best bet may be to start 
client-side only (JavaScript & CSS) and add the server side later (PHP, 
Python, etc.)
See also https://wikitech.wikimedia.org/wiki/Help:Tool_Labs/Web and good 
luck!


Il 23/12/2015 18:20, Ádám Harangozó ha scritto:

Hey all,

I would like to ask about programming web apps using Wikidata. I'm 
completely new to programming, and I just started learning Python. My 
question is  if I would like to make apps like Mix 'n' Match or the 
Wikidata Game, or stuff like Histropedia, Tree of Life, and Sum of All 
Paintings, what programming languages/skills do I need to learn? Also, 
is it worth to start learning how to use frameworks like Django or 
Ruby or these come latar? (And if yes, which framework do you think is 
suitable?) Thanks!


Best,
Adam


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Duplicate identifiers (redirects & non-redirects)

[Ricordisamoa]

I think Tom is referring to external identifiers such as MusicBrainz 
artist ID  etc. and whether 
Wikidata items should show all of them or 'preferred' ones only as we 
did for VIAF redirects 
.


Il 01/10/2015 00:48, Addshore ha scritto:



On 30 September 2015 at 20:58, Tom Morris > wrote:


I think I've seen something somewhere saying that the prevailing
sentiment is that obsolete identifiers which are just redirects to
a new identifier should be removed.


I hope not. See my post at 
http://addshore.com/2015/04/redirects-on-wikidata/ Redirects should 
remain!


Also see http://addshore.com/2015/09/un-deleting-50-wikidata-items/


There's also the case of sites like MusicBrainz which keep the
non-canonical IDs without redirecting to the canonical ID, but
will tell you which ID is preferred, e.g. Fritz Kreisler


https://musicbrainz.org/artist/590fcad4-2ba4-43bc-a22f-a4bb9b496fe8
https://musicbrainz.org/artist/627ac6c2-ee5c-4120-8af3-ab00345447f5
https://musicbrainz.org/artist/bf6d6ce1-ce88-40e6-9424-11d11d2e54ea

where all the tabs for the second two pages actually point to the
first, canonical entry.

Is there an established policy for either the redirect or
non-redirect case?


See 
https://www.wikidata.org/wiki/Wikidata:Deletion_policy#Deletion_of_items_.28Phase_I.29 
which says "Items should not be deleted when - The item redirects to 
another item"


Also see https://www.wikidata.org/wiki/Help:Merge#Create_redirect 
which says redirects should be created when items are merged



I'd argue that even the obsolete identifiers are useful for
inbound resolution and reconciliation. Aggressively pruning them
just makes more work for people, because they must resolve the
identifier that they have in hand to its canonical form (probably
by hitting the issuing authority) before using it for Wikidata
lookups.

What do others think?

Tom

___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata




--
Addshore


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata needs your votes

[Ricordisamoa]

The 2nd round starts today! You can vote from 
http://hauptvoting.welt.de/mainvoting/list


Il 12/08/2015 14:47, Lydia Pintscher ha scritto:

Hey folks,

As you know Wikidata is one of the 100 winners of the "Germany - Land
der Ideen" competition 2015. We now have the chance to win the
Public’s Choice Award as well! At the moment, Wikidata is ranked 15th.
We need to be among the first 10 to enter the next round and win the
Public’s Choice Award. Voting is open until 23 August.

The information about the competition and projects is available in
English 
(https://www.land-der-ideen.de/en/projects-germany/landmarks-land-ideas/competition-2015-urban-space-rural-space-cyberspace
andhttps://www.land-der-ideen.de/en/projects-germany/landmarks-land-ideas/2015-award-recipients/category-science/wikidata)
but the voting process only in German. But it’s pretty easy to vote
anyway:
* Go to the Wikidata voting page at
https://www.land-der-ideen.de/ausgezeichnete-orte/preistraeger/wikidata
* Click the yellow button on the right ("Jetzt abstimmen").
* Type in your email address and tick the box to agree to the voting rules.
* You will receive a link via email. Click the link within 24 hours.

You can repeat this daily until 23 August. You have one vote every day.

Let's win this! :D


Cheers
Lydia




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata API for fetching images related to a Linked Data Item

[Ricordisamoa]

Wikibase is hardcoded to use Wikimedia Commons as file repository 
(T90492 ).
The imageinfo API 
 
can be used to get URLs for displaying.

See also T76827 .

Il 14/08/2015 11:31, Sachini Herath ha scritto:

Hi everyone,

I’m Sachini Herath, an undergraduate from Sri Lanka. I am working on 
building Linked Data mapping tools for Drupal 8 as my Google Summer of 
Code 2015 project. The tools would enable the users to map Drupal 
entities to Linked Data items. Details of the project can be found in 
my blog. http://alongthetrail-sachini.rhcloud.com/


To select a Linked Data item, a dropdown element similar to 
freebase-suggest widget 
 is being 
developed, but in a more generic approach so that it can be configured 
with any Linked Data Provider.


For Wikidata, I'm using "*wbsearchentities*" API for querying and 
"*wbgetentities*" for retrieving information about individual items in 
json format. However I could not find a way to reconstruct the url of 
image property for an item, so that I can fetch the image (property 
P18, P154 etc) for displaying. Are there any APIs or alternative 
methods to fetch images from Wikidata?


I would also like to hear about any optimizations that can be done for 
the query or alternate APIs. For example an API to return id, label, 
description and image urls in just one/ few call/s.


Thank you
Sachini


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata needs your votes

[Ricordisamoa]

Il 12/08/2015 14:47, Lydia Pintscher ha scritto:

Hey folks,

As you know Wikidata is one of the 100 winners of the "Germany - Land
der Ideen" competition 2015. We now have the chance to win the
Public’s Choice Award as well! At the moment, Wikidata is ranked 15th.


Now 7th!


We need to be among the first 10 to enter the next round and win the
Public’s Choice Award. Voting is open until 23 August.

The information about the competition and projects is available in
English 
(https://www.land-der-ideen.de/en/projects-germany/landmarks-land-ideas/competition-2015-urban-space-rural-space-cyberspace
and 
https://www.land-der-ideen.de/en/projects-germany/landmarks-land-ideas/2015-award-recipients/category-science/wikidata)
but the voting process only in German. But it’s pretty easy to vote
anyway:
* Go to the Wikidata voting page at
https://www.land-der-ideen.de/ausgezeichnete-orte/preistraeger/wikidata
* Click the yellow button on the right ("Jetzt abstimmen").
* Type in your email address and tick the box to agree to the voting rules.
* You will receive a link via email. Click the link within 24 hours.

You can repeat this daily until 23 August. You have one vote every day.

Let's win this! :D


Cheers
Lydia




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] I can haz edit summary!

[Ricordisamoa]

Il 30/07/2015 17:49, Bene* ha scritto:

Hi Ricordisamoa,

did you see my script [1] which also aims to fix that bug? I think I 
might integrate some parts of it into your script. What's your opinion?


I assume [1] is User:Bene*/summary.js 
<https://www.wikidata.org/wiki/User:Bene*/summary.js>, am I right?
It really looks like I stole your code even though I didn't knew it 
before. That's embarrassing... :-[ :-[ :-[


But honestly I like the summary being always visible and not being reset 
after every edit.




Best regards
Bene

Am 30.07.2015 um 13:11 schrieb Ricordisamoa:
For T47224 <https://phabricator.wikimedia.org/T47224> I've created a 
new script 
<https://www.wikidata.org/wiki/MediaWiki:Gadget-EditSummary.js> that 
lets you use custom comments for all of your Wikibase actions on a page.

If you like it we can make it a real gadget.


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata] I can haz edit summary!

[Ricordisamoa]

For T47224  I've created a new 
script  
that lets you use custom comments for all of your Wikibase actions on a 
page.

If you like it we can make it a real gadget.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Freebase is dead, long live :BaseKB

[Ricordisamoa]

Il 17/07/2015 19:42, Tom Morris ha scritto:
3,000 judgments per person per day sounds high to me, particularly on 
a sustained basis, but it really depends on the type of task.  Some of 
the tasks were very simple with custom high performance single purpose 
"games" designed around them.  For example, Genderizer presented a 
person's information and allowed choices of Male, Female, Other, and Skip.


Sounds alike to https://tools.wmflabs.org/wikidata-game/

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] [Wikidata-l] Call for development openness

[Ricordisamoa]

Il 17/02/2015 13:33, Ricordisamoa ha scritto:

Il 17/02/2015 12:53, Lydia Pintscher ha scritto:

On Tue, Feb 17, 2015 at 12:43 PM, Ricordisamoa
  wrote:

Hi.
I recently started following mediawiki/extensions/Wikibase on Gerrit, and
quite astonishingly found that nearly all of the 100 most recently updated
changes appear to be owned by WMDE employees (exceptions being one change by
Legoktm and some from L10n-bot). This is not the case, for example, with
mediawiki/core.
While this may be desired by the Wikidata team for corporate reasons, I feel
that encouraging code review by volunteers would empower both Wikidata and
third-party communities with new ways of contributing to the project and
raise awareness of the development team's goals in the long term.

How would you like to see us encourage this more? It is nothing we
actively do not want of course.
Using a single code review system and a simpler repository structure 
will indirectly encourage them.
I'm now seeing Wikibase/Programmer's guide to Wikibase 
<https://www.mediawiki.org/wiki/Wikibase/Programmer%27s_guide_to_Wikibase>, 
which seems fairly detailed but partly duplicates the Gerrit help pages.

The messy naming conventions play a role too, i.e. Extension:Wikibase is
supposed to host technical documentation but instead redirects to the
Wikibase portal, with actual documentation split into Extension:Wikibase
Repository and Extension:Wikibase Client, apparently ignoring the fact that
the code is actually developed in a single repository (correct me if I'm
wrong). Just to add some more confusion, there's also Extension:Wikidata
build with no documentation.

There are different repositories. They just get merged into one for deployment.
Really? AFAICS development occurs on mediawiki/extensions/Wikibase 
<https://git.wikimedia.org/summary/?r=mediawiki/extensions/Wikibase.git> 
and on GitHub.
mediawiki/extensions/WikibaseRepository 
<https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseRepository.git> 
and mediawiki/extensions/WikibaseClient 
<https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseClient.git> 
also exist but have always been empty.


https://phabricator.wikimedia.org/T106002
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] property label/alias uniqueness

[Ricordisamoa]

I agree too.
Also note that property IDs are language-neutral, unlike english names 
of templates, magic words, etc.


Il 13/07/2015 11:45, Jane Darnell ha scritto:
Me too. On the point of Wikipedia templates, I would like to remind 
you that templates are a dramatically confusing mess on Wikipedia, and 
lots of those "unique, localized names" do not lend themselves to 
reuse, which is why we have so many doubles and why the translation 
extension hasn't been able to use them yet. Andy Mabbett has spent a 
lot of time and effort in trying to clean this up a bit on the English 
Wikipedia by merging and consolidating various popular templates, and 
I believe that properties are starting to move in the same direction. 
I certainly don't think we want to look at Wikipedia templates as an 
example of how to go about doing this.


On Mon, Jul 13, 2015 at 9:10 AM, John Erling Blad > wrote:


I for one agree with Gerard that this is a problem.

John


søn. 12. jul. 2015, 18.08 skrev Daniel Kinzler
mailto:daniel.kinz...@wikimedia.de>>:

Am 12.07.2015 um 15:31 schrieb Gerard Meijssen:
> Hoi,
> You do not get it.

Indeed. This is why I am asking questions.

> There are many properties. Consequently the scale of things
> is substantially different.

There are far, far more templates than properties. And we use
unique, localized
names for templates. Why not for properties? And if we don't
want this for
properties, why do the same arguments not apply for template
names?

> It has been demonstrated that languages will have
> homonyms and consequently it is NOT a good idea to use
labels or whatever you
> call them for properties. You can use them as long as
internally you use the
> P-number.

Internally, we always use the P-number. Unless with
"internally" you mean "in
wikitext". This is the point under discussion: whether we want
localized names
for use in wikitext.

> You can use a text as long as the combination of label and
description
> is unique. This combination may be useful.

This is how we do it for items. This works quite well with a
selector widget. It
does not work inside wikitext - there, you either need a
unique name, or rely on
the plain ID.

For items, sitelinks act as a per-language unique name. For
properties, we
decided to require a unique label, since we can't use
sitelinks there, and the
number is low enough (a few thousand, compared to tens of
millions of items)
that ambuguities should be rare.

> At the same time be aware that property labels will be wrong
and will need to be
> changed at a later date.

This is why we want to make aliases unique. If we have unique
aliases, labels
can change without breaking anything.

> When this presents a problem for the comparison with
> external sources, it is tough. It is best to indicate this
from the start.

Why would labels or aliases be used for comparison with
external sources?
Properties can be linked to external vocabularies via
statements, just like we
do it for items. Relying on labels for doing this would be
asking for trouble.

> The argument about what happens in MediaWiki is secondary.
And sorry that not
> everyone cares or knows about that in your way. The point is
very much that at
> the scale of thousands and thousands of properties it does
not scale. This point
> has been made plenty of times by now.

Really? How and where? I only hear you asserting it, but I see
no evidence. I
see it scaling perfectly well on Wikidata. Property names
already *are* unique,
always have been. I know of no major problems with this. There
are some issues
with cultural differences and homonyms (e.g. the distinction
between sex and
gender, or the double meaning of "editor" in Portuguese), but
these are
relatively rare, and no worse than naming dicussions on Wikipedia.

--
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata




___

Re: [Wikidata] property label/alias uniqueness

[Ricordisamoa]

OT: French spelling checker?

Il 10/07/2015 16:56, Thomas Douillard ha scritto:



This is at the cost of renaming properties becoming a burden, si this 
overall increase the maintenance cost. Understanding the comment part 
on the other band is a matter of reading the d'oc, which is the l'East 
we can wait for coming from a template editor. If web think of users 
using for example visual editor then ... It's notre a problème as VE 
will do all the rendering and will translate into labels 
automagically. So ... Who are the users who actually need this ?


Le 10 juil. 2015 00:14, "Lydia Pintscher" 
mailto:lydia.pintsc...@wikimedia.de>> a 
écrit :


On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL
mailto:innovi...@gmail.com>> wrote:
> Lydia,
>
> If I'm not wront the substituion scenario covers your requirements
>
> {{#property:Pxxx}} ==SUBST BY
> ==>{{#property:Pxxx|label="main label at the time of substitution"}}
> {{#property:MainLabelAtSubsTime}}  ==SUBST BY
> ==>{{#property:Pxxx|label="main label at the time of substitution"}}
> {{#property:UnambiuousAliasAtSubsTime}}  ==SUBST BY
> ==>{{#property:Pxxx|label="unambiguous alias at subst time"}}
> {{#property:AmbiuousAliasAtSubsTime}}  ==SUBST BY ==>{{ERROR}}
==> hence the
> editor can fix it
>
> It looks like covering most of cases without adding extra burden
of unicity
> and keeping existing mechanism

I think the comment part is rather ugly and I'd expect more confusing
for editors than it helps tbh. And substituting without the comment
would help the first editor but none of the ones after him/her. So I'm
not convinced this is a solution :/


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de 

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens
e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] property label/alias uniqueness

[Ricordisamoa]

Il 08/07/2015 22:00, Daniel Kinzler ha scritto:

The idea was readability and internationalization.


Which one is more readable and internationalized, 
{{#property:syntymäaika}} or {{#property:P569}} ?

The former makes reading and reusing templates from other wikis much harder.



If there is consensus to not use human readable property names for accessing
data, and solely rely on IDs instead, we could indeed stop all this right now,
and just drop the uniqueness constraint for labels as well as for aliases of
properties.


Yes!



You are right that changing the name of a property shouldn't be as easy as it
currently is. There should at least be a warning.





___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] property label/alias uniqueness

[Ricordisamoa]

I believed that #property with labels was never to be relied on.
It seems that the effort to solve conflicts with aliases is not worth it.

Il 08/07/2015 01:27, Lydia Pintscher ha scritto:

Hey folks :)

Right now the property parser function on Wikipedia and other clients
only works with the label of the property. People are asking us to
make it also work with aliases. In order to do that labels and aliases
need to be unique across properties. There are unfortunately a number
of properties where the label and aliases are not unique. Those need
to be fixed before we can enable the feature. Bene has created a page
that lists all properties that need to have their aliases changed:
https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a
look at this and fix some that'd be much appreciated.


Cheers
Lydia



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] calendar model screwup

[Ricordisamoa]

It's worrying to hear this.
The Italian Wikisource community strove to get calendar models right.

But I'm sure Magnus will come up with a tool to fix them ;-)

Il 30/06/2015 19:38, Lydia Pintscher ha scritto:

Hi everyone,

I have some bad news. We screwed up. I’m really sorry about this. I’d
really appreciate everyone’s help with fixing it.

TLDR: We have a bad mixup of calendar models for the dates in Wikidata
and we need to fix them.

 What happened? 
Wikidata dates have a calendar model. This can be Julian or Gregorian
and the plan is to support more in the future. There are two ways to
interpret this calendar model:
# the given date is in this calendar model
# the given date is Gregorian and this calendar model says if the date
should be displayed in Gregorian or Julian in the user interface

Unfortunately both among the developers as well as bot operators there
was confusion about which of those is to be used. This lead to
inconsistencies in the backend/frontend code as well as different bot
authors treating the calendar model differently. In addition the user
interface had problematic defaults. We now have a number of dates with
a potentially wrong calendar model. The biggest issue started when we
moved code from the frontend to the backend in Mid 2014 in order to
improve performance. Prior to the move, the user interface used to
make the conversion from one model to the other. After the move, the
conversion was not done anywhere anymore - but the calendar model was
still displayed. We made one part better but in the process broke
another part badly :(

 What now? 
* Going forward the date data value will be given in both the
normalized proleptic Gregorian calendar as well as in the calendar
model explicitly given (which currently supports, as said, proleptic
Gregorian and proleptic Julian).
* The user interface will again indicate which calendar model the date
is given in. We will improve documentation around this to make sure
there is no confusion from now on.
* We made a flowchart to help decide what the correct calendar model
for a date should be to help with the clean up.
* We are improving the user interface to make it easier to understand
what is going on and by default do the right thing.
* We are providing a list of dates that need to be checked and
potentially fixed.
* How are we making sure it doesn’t happen again?
* We are improving documentation around dates and will look for other
potential ambiguous concepts we have.

 How can we fix it? 
We have created a list of all dates that potentially need checking. We
can either provide this as a list on some wiki page or run a bot to
add “instance of: date needing calendar model check“ or something
similar as a qualifier to the respective dates. What do you prefer?
The list probably contains dates we can batch-change or approve but
we’d need your help with figuring out which those are.
We also created a flowchart that should help with making the decision
which calendar model to pick for a given date:
https://commons.wikimedia.org/wiki/File:Wikidata_Calendar_Model_Decision_Tree.svg

Thank you to everyone who helped us investigate and get to the bottom
of the issue. Sorry again this has happened and is causing work. I
feel miserable about this and if there is anything more we can do to
help with the cleanup please do let me know.


Let's please keep further discussion about this in one place on-wiki
at https://www.wikidata.org/wiki/Wikidata:Project_chat#calendar_model_screwup


Cheers
Lydia




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] "site link" vs. "sitelink"

[Ricordisamoa]

Il 30/06/2015 10:36, Amir E. Aharoni ha scritto:

Hi,

There's a bikeshed about how "site link" should be spelled: with or 
without space.


Currently almost all messages in the Wikibase software say "sitelink", 
and so does the Wikidata glossary [1]


A counter-argument is that "site link" is a better English expression 
that doesn't create an unnecessary neologism.


See the comments to these Gerrit patches:
https://gerrit.wikimedia.org/r/#/c/218272/
https://gerrit.wikimedia.org/r/#/c/218272/


Hmm... https://gerrit.wikimedia.org/r/#/c/217798/ ?



Though I committed the patch to make it "sitelink" everywhere in the 
UI, I do not have a strong preference for either spelling. I do, 
however, have a strong affinity to consistency in the spelling of 
translatable messages, because this makes life easier for users and 
for translators.


Note, that this will only about the English spelling. Some languages 
(like Hebrew) strongly prefer spelling of compound words with a space, 
and some (like German) tend to spell them in one word. The translation 
is up to the translators. Consistency in the English spelling is only 
supposed to make it easier for the translators.


Can anybody please help resolve this bike shed?

Thank you!

[1] https://www.wikidata.org/wiki/Wikidata:Glossary

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Update frequency on the Wikidata Query API

[Ricordisamoa]

Just ask WDQ for a list of item ids, then pass them to the live API 
.
You may miss some recently edited items, but at least you wouldn't base 
your edits upon outdated revisions (and wbeditentity 
's 
"baserevid" argument completely eliminates the risk).


Il 19/06/2015 00:10, Andra Waagmeester ha scritto:
Indeed the ultimate truth source is on the wikidata site it self. 
However, I am not aware of a way to query the Wikidata site for a list 
of items fitting a certain condition (e.g. all Wikidata items 
containing a claim with the  NCBI Entrez Gene (P351) property.)


It is here that I need to rely on WDQ (and WDQS) and potentially risk 
missing existing items due to delays in which WDQ (and WDAS) gets updated.


I would like to know if I could rely on a given time frame - being it 
seconds, hours,  days, or one week).


I currently assume a delay of a week, but I don't know how accurate 
this assumption is.


Regards,



On Thu, Jun 18, 2015 at 10:23 PM, Stas Malyshev 
mailto:smalys...@wikimedia.org>> wrote:


Hi!

> The way that updates work *in all systems* (polling small lists of
> recent changes at intervals and hoping that this leads to a complete
> change history), it seems quite possible that such systems will
> sometimes miss an update, at least in the long run and under varying
> conditions (high server load, network troubles, update script
down for a
> while, whatever). Insufficient update frequency is maybe not the
biggest
> problem here (it should be in the range of one to a few minutes
for all
> of the services).

Very important point with which I agree - it is completely
possible that
update polling misses an update, WDQS is no exception and it usually
does not treat it as a problem, as the next update can fill up the
missed one. However the ultimate truth source is on the wikidata site
only. Beware of the caches though - if you ask for the same data
on the
same URL twice, I think you can get the same result even if the
underlying data changed in the meantime.

--
Stas Malyshev
smalys...@wikimedia.org 

___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Import of redirects as aliases

[Ricordisamoa]

I've seen countless inaccurate aliases 'inferred' from redirects by bots.
Let's not do that anymore.

Il 19/06/2015 08:57, Federico Leva (Nemo) ha scritto:
Do we have statistics on how many aliases we have compared to the 
redirects in Wikipedia and Wikiquote, especially for proper names? I'd 
suppose that all redirects have been imported by now.


Aliases are a rather efficient way to store redirects for names which 
are used in many forms. My only problem is that there is no way to add 
an alias for languages, e.g. Latin names of learned people; but I hope 
search does or will remedy by searching in all languages anyway.


Nemo

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Lists of things as entities in Wikidata

[Ricordisamoa]

Il 15/06/2015 23:22, Thad Guidry ha scritto:


Freebase simply decided to not keep Wikipedia topic pages that simply 
held "lists of entities", but instead Freebase liked to easily 
generate those same "lists of entities" by using queries. There was no 
need to have hand coded lists in Freebase.  It was a graph database 
and could generate all kinds of lists programmaticlly for a user, and 
keep those lists as views against our user profile for easy tweaking 
or re-use when we wanted to. (stored user queries)


Thad
+ThadGuidry 



Wikidata is not Freebase.
Its primary use is still to link pages between projects, it'll take some 
time before it can serve as a real data source, with queries and all 
that stuff.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata Visualization Challenge

[Ricordisamoa]

Il 26/05/2015 21:54, Jan Ainali ha scritto:

Hi,

I just wanted to let you know that there has been a few more prizes 
added to the contest (including a travel grant to Brazil!). Please 
checkout http://wvc.se for an update list.


Also, if people here are planing to join the contest, please list 
yourself (non-binding) on this list [1], to help us that arranges this 
to be prepared on the scale of the number of participants.


Is there any participant yet?



[1] 
https://se.wikimedia.org/wiki/Projekt:%C3%96ppna_data_2015/Visualisering/T%C3%A4vling/Bidrag


/Med vänliga hälsningar,
Jan Ainali/

Verksamhetschef, Wikimedia Sverige 
0729 - 67 29 48


/Tänk dig en värld där varje människa har fri tillgång till 
mänsklighetens samlade kunskap. Det är det vi gör./

Bli medlem. 
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] weekly summary #159

[Ricordisamoa]

Il 27/05/2015 15:23, Lydia Pintscher ha scritto:

On Wed, May 27, 2015 at 3:20 PM, Ricordisamoa
  wrote:

In what ways could the directory be improved?

I think the directory is good actually. The issue is getting to it
from Wikidata


Added <https://www.wikidata.org/wiki/?diff=219815821&oldid=153709007> to 
Wikidata:Tools.



  and also having a listing of the tools around Wikidata
that are not on tool labs (which I assume can't be listed in the
directory?).


They can: "Note that your tool *does not* have to be hosted on WMF Labs" 
(bold is not mine)





Cheers
Lydia



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] weekly summary #159

[Ricordisamoa]

Il 27/05/2015 15:18, Lydia Pintscher ha scritto:

On Wed, May 27, 2015 at 3:13 PM, Magnus Manske
 wrote:

Well,

https://www.wikidata.org/wiki/Wikidata:Tools/External_tools has 42 tools

https://tools.wmflabs.org/hay/directory/#/search/wikidata has 53 tools

Good point. We also have that... Anyone willing to take on a
simplification/cleanup? Our tools ecosystem is so important and right
now we're not giving it a good representation :/


Cheers
Lydia



In what ways could the directory be improved?

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] weekly summary #159

[Ricordisamoa]

Il 26/05/2015 13:40, Markus Krötzsch ha scritto:

On 26.05.2015 02:18, Stas Malyshev wrote:

Hi!


   o If you are not familiar with SPARQL yet, a tool
  has been created by 
Tpt

  and Bene*
  to generate SPARQL
 queries from natural language questions.
   o To do SPARQL queries from the command line, a command line 
tool
  was crafted by 
Marius

 .


This is awesome! Need more SPARQL tools. I guess the direction to
develop this would be to have GUI that allows to build queries
(something like we see at https://wdq.wmflabs.org/wdq/) and maybe making
ppp-sparql resolved queries - e.g. with actual Q-item for "president"
when I ask for "who is the president of the USA?" - which will be more
efficient.

Should we start some page where we list such tools?



Yes please.


I requested a toolinfo.json to be added to ppp-sparql: 
https://github.com/ProjetPP/PPP-Wikidata-SPARQL/pull/1
Then you would just search for "sparql" here 
.




I was quite surprised by how well ppp-sparql performs based on very 
limited information (it's guesses on simple sentences often yield 
results). Nice work! Maybe it could be more efficient to do some API 
requests to find the right entities rather than filtering many 
alternative labels as part of the query. It's not a pattern that we 
should encourage for production ;-)


Regards,

Markus

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] [Wikidata-l] Wikidata periodic table

[Ricordisamoa]

Il 22/05/2015 17:30, Andy Mabbett ha scritto:

On 8 April 2015 at 00:18, Ricordisamoa  wrote:


I'd like to announce a new Labs tool to show a periodic table.
It is based on WikiPeriod's PHP code (in turn ported from JavaScript) and
features several improvements:

This is very impressive; thank you!


for labels, Wikidata's built-in language fallback is used instead of just
falling back to English;

I'm not sure what you mean, here. Are you suggesting that
tools.wmflabs.org knows what my Wikidata language preferences are?


No. It tries to detect /your browser/'s preferred language and send it 
to Wikidata, which would apply its own fallback rules (e.g. if the 
Neapolitan label can't be found, it returns the Italian one).




Also, I have some suggestions:

   * A drop down to change the language of labels, as demonstrated on
QLabel - <http://googleknowledge.github.io/qlabel/>


Thanks for the suggestion: filed T100045 
<https://phabricator.wikimedia.org/T100045>.
But you can already change language right now, see 
https://tools.wmflabs.org/ptable/?lang=ga for an example.




   * When possible (e.g. on a mobile device), use the device's
preferred language (as done by QRpedia)


It's already possible not only on mobile devices, as I wrote above.



   * Instead of linking to Wikidata items, link to Wikipedia articles
in the chosen language (or link to Resonator)




Created T100046 <https://phabricator.wikimedia.org/T100046>.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Is it possible to use SQL on production databases to pull out Wikidata claim values?

[Ricordisamoa]

I don't think the information you're looking for is available for direct 
queries.
If you need data about a predetermined set of items, just use the 
official Wikidata API: 
https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q107146&props=claims.
For a SQL-like syntax, Wikidata Query  comes in 
handy.


Il 22/05/2015 05:15, Raymond Yee ha scritto:
Is it possible to get claims made in Wikidata using the SQL interface 
to the replicas of the production databases run by Wikimedia Labs 
(https://wikitech.wikimedia.org/wiki/Help:Tool_Labs/Database)?


I see on http://quarry.wmflabs.org/ (a service to "Run SQL queries 
against Wikipedia & other databases from your browser!") queries 
involving the wikidatawiki_p database -- e.g., 
http://quarry.wmflabs.org/query/3152. But I've not been able to find 
queries that pull out values for Wikidata claims.


To provide a concrete example, can one write a SQL query on the 
Wikimedia databases to return claims about the population of Alameda 
County, California (https://www.wikidata.org/wiki/Q107146), which was 
specifically, 1,510,271 in the 2010 census?


P1082 (https://www.wikidata.org/wiki/Property:P1082) is the population 
properly. In 
https://www.wikidata.org/wiki/Special:EntityData/Q107146.json, we see 
the following json fragment:


P1082: [
{
id: "Q107146$8938463B-C469-4162-80F7-96DDDE1429DD",
mainsnak:
{
snaktype: "value",
property: "P1082",
datatype: "quantity",
datavalue:
{
value:
{
amount: "+1510271",
unit: "1",
upperBound: "+1510271",
lowerBound: "+1510271"
},
type: "quantity"
}
}
...
}
]
},

I've looked through the tables in wikidatawiki_p but can't find any 
table that has the claim data.


So I suspect the answer is no -- that although there's lot of metadata 
about Wikidata available to SQL queries on the replicas. (SQL not 
mentioned in https://www.wikidata.org/wiki/Wikidata:Data_access). Is 
this correct?


Thanks,
-Raymond


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] [Wikidata-l] Wikidata periodic table

[Ricordisamoa]

Merged! Thanks to Lucie for reviewing ;-)

Il 08/04/2015 01:22, Ricordisamoa ha scritto:
Forgot: the code is formally under review here 
<https://gerrit.wikimedia.org/r/202610/>. GPL-3.0+ as the old WikiPeriod 
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata identifier / VIAF / query API

[Ricordisamoa]

You can get a page title by item and site via the Wikidata API:
https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q1225937&props=sitelinks&sitefilter=nlwiki&format=json

Il 20/05/2015 16:39, Johan Mijs ha scritto:

Hi Dimitry,

I am not quering FOR the wikibase_item, I want to query WITH the 
wikibase_item as a parameter. Sorry if I was unclear.


Johan

On 20 May 2015, at 16:28, Dmitry Brant > wrote:


Hi Johan,

The wikibase_item is returned as part of the "pageprops" response, so 
your example query is already requesting it correctly. If you look at 
the json response for that query, you can see wikibase_item present 
in the pageprops object.



-Dmitry


On Wed, May 20, 2015 at 9:01 AM, Johan Mijs > wrote:


Hello,

we here at Bibnet (a government agency working for public
libraries) in Brussels greatly admire your work on the Wikidata
project! Thanks to the addition of Wikidata indentifiers to the
viaf.org  project, we finally will be able to
relate the personal names in our library catalog to Wikipedia.

What we do now (without identifiers):
We use the Wikipedia API to query the ’titles’ parameter, based
on the name of an author in our database. Lots of things can go
wrong of course.

Example query:

http://nl.wikipedia.org/w/api.php?action=query&prop=pageprops%7Cinfo%7Cextracts%7Clinks%7Cpageimages&redirects&format=json&explaintext&continue&exchars=1000&exsectionformat=plain&format=json&titles=Dimitri_Verhulst&pithumbsize=150&callback=jQuery17208731340558733791_1432116510465

Result in our library catalog (AquaBrowser software):

http://zbb.staging.aquabrowser.be/?q=author:%22Dimitri%20Verhulst%22&uilang=en

What we want to do (with identifiers):
Keep on using the Wikipedia api (because then there are no costs
for extra development), but query for a Wikidata identifier (I
believe it is called wikibase_item). I only find pageids as a
parameter on
http://nl.wikipedia.org/w/api.php?action=help&modules=query. Is
querying for a Wikidata identifier possible? If not, what is a
possible workaround?

Thank you,

Johan

Johan Mijs
Technology Manager

johan.m...@bibnet.be
+32 (0)2 213 10 27 
+32 (0)473 81 78 70 
skype:johanmijs

Bibnet vzw
www.bibnet.be 
Priemstraat 51
B-1000 Brussel


___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata