Aren't pages too long?

List overview All Threads
Download

newer

older

Wikidata Query Help: IMDB id +...

data access for Wikiversity on May...

David Abián

3 May 2016 3 May '16

11:07 a.m.

Hi, I think that most elements on Wikidata are nowadays too long to be easily read by humans. There are many properties (which is great), the information is too scattered, and this problem (if you consider it a problem) will continue growing up. Some suggestions come to mind... * Visually group properties by type, using the division of <https://www.wikidata.org/wiki/Wikidata:Property_proposal>, or another. * Change our current CSS rules to show properties in a more compacted way. * Create a table of contents that automatically appears when more than N properties have been defined for an element. * Combine some of the above. Is there something discussed/planned facing this issue? Regards, -- David Abián - davidabian.com Vocal de Comunicación Wikimedia España Vega Sicilia, 2 47008 - Valladolid https://wikimedia.es Wikimedia España es una asociación sin ánimo de lucro española con CIF G-10413698 inscrita en el Registro Nacional de Asociaciones, Grupo 1, Sección 1, Núm. Nacional 597390. «Imagina un mundo en el que cada persona tenga acceso libre a todo el conocimiento».

Show replies by thread

Lydia Pintscher

3 May 3 May

11:52 a.m.

On Tue, May 3, 2016 at 1:08 PM David Abián <davidabian(a)wikimedia.es> wrote:

...

Hi David, Yes this is a problem I already identified. We've worked on it as well already. As a first step we improved the loading time of large items. As the next step we have moved identifiers into their own section. This already helped a lot by removing identifiers from the rest of the statements where they were mostly clutter. We have also made a few small UI tweaks to improve the spacing. The next step is going to be ordering of statements. For that we have to do some groundwork and then community input. I hope we can start with that in the next 2 months. To summarize: Being worked on but it is an on-going task that will be with Wikidata for a long time as it grows. 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.

Markus Kroetzsch

12:27 p.m.

Hi David, Reasonator has done a lot of pioneering work in this area. We are copying some of it in SQID (and adding own modifications). In general, these projects could be nice playgrounds for experimentation here. If you have suggestions on how to improve these UIs, they are very welcome. I believe Reasonator is grouping properties by built-in rules, whereas SQID is using certain property-classes (P31 on Property pages), where this is available. One could experiment with further approaches or switches ... Markus On 03.05.2016 13:52, Lydia Pintscher wrote:

...

On Tue, May 3, 2016 at 1:08 PM David Abián <davidabian(a)wikimedia.es <mailto:davidabian@wikimedia.es>> wrote: Hi, I think that most elements on Wikidata are nowadays too long to be easily read by humans. There are many properties (which is great), the information is too scattered, and this problem (if you consider it a problem) will continue growing up. Some suggestions come to mind... * Visually group properties by type, using the division of <https://www.wikidata.org/wiki/Wikidata:Property_proposal>, or another. * Change our current CSS rules to show properties in a more compacted way. * Create a table of contents that automatically appears when more than N properties have been defined for an element. * Combine some of the above. Is there something discussed/planned facing this issue? Hi David, Yes this is a problem I already identified. We've worked on it as well already. As a first step we improved the loading time of large items. As the next step we have moved identifiers into their own section. This already helped a lot by removing identifiers from the rest of the statements where they were mostly clutter. We have also made a few small UI tweaks to improve the spacing. The next step is going to be ordering of statements. For that we have to do some groundwork and then community input. I hope we can start with that in the next 2 months. To summarize: Being worked on but it is an on-going task that will be with Wikidata for a long time as it grows. 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 <http://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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

-- Markus Kroetzsch Faculty of Computer Science Technische Universität Dresden +49 351 463 38486 http://korrekt.org/

Magnus Manske

1:03 p.m.

For alternative interfaces that include editing capabilities, see also my demo here: https://tools.wmflabs.org/reasonator/widee/#q=Q42 (this one is optimized for load speed and readability, but it's been around for a while, so no guarantees...) On Tue, May 3, 2016 at 1:27 PM Markus Kroetzsch < markus.kroetzsch(a)tu-dresden.de> wrote:

...

the

information is too scattered, and this problem (if you consider it a problem) will continue growing up. Some suggestions come to mind... * Visually group properties by type, using the division of <https://www.wikidata.org/wiki/Wikidata:Property_proposal>, or

another.

* Change our current CSS rules to show properties in a more compacted way. * Create a table of contents that automatically appears when more

than N

properties have been defined for an element. * Combine some of the above. Is there something discussed/planned facing this issue? Hi David, Yes this is a problem I already identified. We've worked on it as well already. As a first step we improved the loading time of large items. As the next step we have moved identifiers into their own section. This already helped a lot by removing identifiers from the rest of the statements where they were mostly clutter. We have also made a few small UI tweaks to improve the spacing. The next step is going to be ordering of statements. For that we have to do some groundwork and then community input. I hope we can start with that in the next 2 months. To summarize: Being worked on but it is an on-going task that will be with Wikidata for a long time as it grows. 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 <http://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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

-- Markus Kroetzsch Faculty of Computer Science Technische Universität Dresden +49 351 463 38486 http://korrekt.org/ _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Federico Leva (Nemo)

1:05 p.m.

My main issues are * there isn't a TOC, which is sorely needed to be able to jump to the various sections (e.g. identifiers, sitelinks); * there is only one "add statement" button and it's in an unpredictable position. The two issues are very easy to fix IMHO: just add a TOC and a second button at the top. Nemo

Gerard Meijssen

1:37 p.m.

Hoi, For several years the Reasonator has done a stellar job. It is much better at providing information based on the Wikidata data. It just does not have a priority to provide an interface like this. The beauty of the Reasonator that it can easily provide you the same information in other languages.. Thanks, GerardM https://tools.wmflabs.org/reasonator/?q=Q181 https://tools.wmflabs.org/reasonator/?q=Q181&lang=ru https://tools.wmflabs.org/reasonator/?q=Q181&lang=ar https://tools.wmflabs.org/reasonator/?q=Q181&lang=sv On 3 May 2016 at 13:07, David Abián <davidabian(a)wikimedia.es> wrote:

...

Benjamin Good

3:58 p.m.

I think no one would disagree that the current viewing experience on the main wikidata.org interface is not ideal. Keep in mind though that this is fundamentally an impossible UI task. There are many many different ways that the data about an item in wikidata might be best used/viewed depending on who is doing the viewing and why. Having the same interface attempt to support viewing data about astronomy and art history is just never going to be great for either. While I applaud and encourage the ongoing development of the default interface, I think it would benefit the community to think past that interface to the kinds of purpose built wikidata-driven applications that serve and benefit from specific communities. Anything we can do to make it easier for people to build good apps (in addition to those in the MediaWiki family) that read and write to wikidata could have a huge impact on its ultimate impact. One of the things that freebase (RIP) did in this regard was the Acre [1] hosted development environment. While clearly it didn't tip the balance for them, I think it was a powerful idea that we could probably learn from. -Ben [1] http://wiki.freebase.com/wiki/Acre On Tue, May 3, 2016 at 6:37 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

...

_______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

zehetner

4:22 p.m.

I also think Reasonator does a very good job displaying Wikidata information. I'm experimenting with a Reasonator version which allows to add some basic analysis tools for genes and proteins [1]. It's called Reasomics and when switched on top of page to on pages with gene and protein items (e.g. the BRCA1 gene [2]) additional information/links are displayed and right now some sequence analysis tools can be called. It also checks if the sequence data on Wikidata are out-of-date compared with the latest Ensembl version (as is the case at the moment) an shows some warnings. [1] https://tools.wmflabs.org/reasomics/ [2] https://tools.wmflabs.org/reasomics/?q=Q227339 It's really just some experimental work in progress so it might not be working at times. Cheers Günther On 2016-05-03 15:03, Magnus Manske wrote:

...

For alternative interfaces that include editing capabilities, see also my demo here: https://tools.wmflabs.org/reasonator/widee/#q=Q42 [6] (this one is optimized for load speed and readability, but it's been around for a while, so no guarantees...) On Tue, May 3, 2016 at 1:27 PM Markus Kroetzsch <markus.kroetzsch(a)tu-dresden.de> wrote:

On Tue, May 3, 2016 at 1:08 PM David Abián

<davidabian(a)wikimedia.es

<mailto:davidabian@wikimedia.es>> wrote: Hi, I think that most elements on Wikidata are nowadays too long

to be

easily read by humans. There are many properties (which is

great), the

information is too scattered, and this problem (if you

consider it a

problem) will continue growing up. Some suggestions come to mind... * Visually group properties by type, using the division of <https://www.wikidata.org/wiki/Wikidata:Property_proposal

[1]>, or another.

* Change our current CSS rules to show properties in a more compacted way. * Create a table of contents that automatically appears when

more than N

well

already. As a first step we improved the loading time of large

items. As

the next step we have moved identifiers into their own section.

This

already helped a lot by removing identifiers from the rest of the statements where they were mostly clutter. We have also made a

few small

UI tweaks to improve the spacing. The next step is going to be

ordering

of statements. For that we have to do some groundwork and then

community

input. I hope we can start with that in the next 2 months. To summarize: Being worked on but it is an on-going task that

will be

with Wikidata for a long time as it grows. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher [2] Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de [3] <http://www.wikimedia.de [3]> 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata [4]

-- Markus Kroetzsch Faculty of Computer Science Technische Universität Dresden +49 351 463 38486 http://korrekt.org/ [5] _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata [4]

Links: ------ [1] https://www.wikidata.org/wiki/Wikidata:Property_proposal [2] http://about.me/lydia.pintscher [3] http://www.wikimedia.de [4] https://lists.wikimedia.org/mailman/listinfo/wikidata [5] http://korrekt.org/ [6] https://tools.wmflabs.org/reasonator/widee/#q=Q42 _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Brill Lyle

4:47 p.m.

As someone very intimidated and overwhelmed by the Wikidata interface, I agree the list of elements is too long. I was trying to update Authority Control for a Wikipedia entry and it was a lot of scrolling around to make sure I wasn't adding duplicates, etc. A Table of Contents would be a huge help, especially if it was similar in behavior to the existing Wikipedia TOC model that Wikipedians are used to seeing. Disagree that this is "fundamentally an impossible UI task." The example Reasonator with Sources and Files selected is pretty danged nice! My biggest gripe with Wikidata is the UI, as it seems like both a functional (too long, intimidating) as well as visual (clunky, complicated, not super pretty) barrier. There are solutions to these barriers, although I understand the solutions are not trivial. While the focus of Wikidata is clearly on data and responsiveness, necessitating UI and a focus on the more non-tech users is a lower priority, I am glad it is part of the ongoing conversation. - Erika *Erika Herzog* Wikipedia *User:BrillLyle* <https://en.wikipedia.org/wiki/User:BrillLyle> Secretary, Wikimedia NYC <https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC> On Tue, May 3, 2016 at 11:58 AM, Benjamin Good <ben.mcgee.good(a)gmail.com> wrote:

...

I think no one would disagree that the current viewing experience on the main wikidata.org interface is not ideal. Keep in mind though that this is fundamentally an impossible UI task. > > On 3 May 2016 at 13:07, David Abián <davidabian(a)wikimedia.es> wrote: > >> Hi, >> >> I think that most elements on Wikidata are nowadays too long to be >> easily read by humans. There are many properties (which is great), the >> information is too scattered, and this problem (if you consider it a >> problem) will continue growing up. >> >>

David Abián

9:06 p.m.

Thank you very much for all your comments. If you let me write a personal reflection, I think we need to integrate good ideas concerning UX (reasonators and any other external tool) as a part of the software before it's too late. On Wikipedia, I fear that it's already too late, so late that I'm seeing hard to improve the (old, ugly) current skin by default, Vector, even when we had a better idea of design, Winter. The obsolete interface of Wikipedia has become the unmistakable identity of the project (even appearing on cinema, parody, theater or The Simpsons), most people know how to use it, and the results of an abrupt replacement are completely unexpected. But Wikidata hasn't got such an impact yet, it's younger and more flexible, and we can still significantly improve its interface making a mistake when necessary. (I would also encourage to include any kind of external tools, not only related to the appearance, as a part of the MediaWiki software... but that wouldn't be related to this thread.) ;-) Regards, El 03/05/16 a las 13:52, Lydia Pintscher escribió:

...

-- David Abián - davidabian.com Vocal de Comunicación Wikimedia España Vega Sicilia, 2 47008 - Valladolid https://wikimedia.es Wikimedia España es una asociación sin ánimo de lucro española con CIF G-10413698 inscrita en el Registro Nacional de Asociaciones, Grupo 1, Sección 1, Núm. Nacional 597390. «Imagina un mundo en el que cada persona tenga acceso libre a todo el conocimiento».

Andrew Gray

4 May 4 May

12:15 p.m.

On 3 May 2016 at 17:47, Brill Lyle <wp.brilllyle(a)gmail.com> wrote:

...

Brill Lyle

5:10 p.m.

That would be great, very helpful. Would this be a problematic value exists check, in terms of creating a lag in responsiveness? I am also not clear on the fact that one of the Authority Control elements is populating in the top Statements section vs. the lower Identifiers section -- i.e., *ISNI* for https://www.wikidata.org/wiki/Q1160089 I wanted to update Father Berrigan's Authority Control and am having a really difficult time knowing what the best practices are -- if best practices exist -- for the reference area of Wikidata Identifiers. I would pull from the bottom "History" section here on VIAF -- https://viaf.org/viaf/66488489/#Berrigan,_Daniel. -- as the reference for these. It's probably me thinking of references as they exist on Wikipedia vs. how they exist on Wikidata. But I've seen references on Wikidata presented in different ways, so wasn't sure. - Erika *Erika Herzog* Wikipedia *User:BrillLyle* <https://en.wikipedia.org/wiki/User:BrillLyle> Secretary, Wikimedia NYC <https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC> On Wed, May 4, 2016 at 8:15 AM, Andrew Gray <andrew.gray(a)dunelm.org.uk> wrote:

...

On 3 May 2016 at 17:47, Brill Lyle <wp.brilllyle(a)gmail.com> wrote:

make

sure I wasn't adding duplicates, etc. A Table of Contents would be a huge

A duplicates check seems a good idea - I've wondered about this before, having added a lot of duplicate values in the past! A quick UI suggestion - https://phabricator.wikimedia.org/T134371 - any thoughts? -- - Andrew Gray andrew.gray(a)dunelm.org.uk _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Young,Jeff (OR)

5:21 p.m.

The canonical form for VIAF URIs is http://viaf.org/viaf/66488489. That’s the form used in the VIAF linked data and informally declared on the HTML page as the “Permalink”: [cid:CA6352AE-CBDB-4BE0-B533-FA07AE44A508] From: Wikidata <wikidata-bounces@lists.wikimedia.org<mailto:wikidata-bounces@lists.wikimedia.org>> on behalf of Brill Lyle <wp.brilllyle@gmail.com<mailto:wp.brilllyle@gmail.com>> Reply-To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.org<mailto:wikidata@lists.wikimedia.org>> Date: Wednesday, May 4, 2016 at 1:10 PM To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.org<mailto:wikidata@lists.wikimedia.org>> Subject: Re: [Wikidata] Aren't pages too long? That would be great, very helpful. Would this be a problematic value exists check, in terms of creating a lag in responsiveness? I am also not clear on the fact that one of the Authority Control elements is populating in the top Statements section vs. the lower Identifiers section -- i.e., ISNI for https://www.wikidata.org/wiki/Q1160089 I wanted to update Father Berrigan's Authority Control and am having a really difficult time knowing what the best practices are -- if best practices exist -- for the reference area of Wikidata Identifiers. I would pull from the bottom "History" section here on VIAF -- https://viaf.org/viaf/66488489/#Berrigan,_Daniel. -- as the reference for these. It's probably me thinking of references as they exist on Wikipedia vs. how they exist on Wikidata. But I've seen references on Wikidata presented in different ways, so wasn't sure. - Erika Erika Herzog Wikipedia User:BrillLyle<https://en.wikipedia.org/wiki/User:BrillLyle> Secretary, Wikimedia NYC<https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC> On Wed, May 4, 2016 at 8:15 AM, Andrew Gray <andrew.gray@dunelm.org.uk<mailto:andrew.gray@dunelm.org.uk>> wrote: On 3 May 2016 at 17:47, Brill Lyle <wp.brilllyle@gmail.com<mailto:wp.brilllyle@gmail.com>> wrote:

...

A duplicates check seems a good idea - I've wondered about this before, having added a lot of duplicate values in the past! A quick UI suggestion - https://phabricator.wikimedia.org/T134371 - any thoughts? -- - Andrew Gray andrew.gray@dunelm.org.uk<mailto:andrew.gray@dunelm.org.uk> _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org<mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata

Brill Lyle

9:23 p.m.

Not really what I was asking. I understand the URI and what the permalink does/is. But thanks anyway. - Erika *Erika Herzog* Wikipedia *User:BrillLyle* <https://en.wikipedia.org/wiki/User:BrillLyle> Secretary, Wikimedia NYC <https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC> On Wed, May 4, 2016 at 1:21 PM, Young,Jeff (OR) <jyoung(a)oclc.org> wrote:

...

The canonical form for VIAF URIs is http://viaf.org/viaf/66488489. That’s the form used in the VIAF linked data and informally declared on the HTML page as the “Permalink”:

2907

days inactive

2908

days old

wikidata@lists.wikimedia.org

Manage subscription

13 comments

11 participants

tags (0)

participants (11)

Andrew Gray
Benjamin Good
Brill Lyle
David Abián
Federico Leva (Nemo)
Gerard Meijssen
Lydia Pintscher
Magnus Manske
Markus Kroetzsch
Young,Jeff (OR)
zehetner