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,
On Tue, May 3, 2016 at 1:08 PM David Abián 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
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@tu-dresden.de> wrote:
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@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>, oranother.
* Change our current CSS rules to show properties in a more compacted way. * Create a table of contents that automatically appears when morethan 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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@tu-dresden.de wrote:
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@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
[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
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 [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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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ó:
On Tue, May 3, 2016 at 1:08 PM David Abián <davidabian@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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
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@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?
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».
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@gmail.com wrote:
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@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?
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».
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
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@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@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.
On 3 May 2016 at 17:47, Brill Lyle wp.brilllyle@gmail.com wrote:
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
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?
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 wrote:
On 3 May 2016 at 17:47, Brill Lyle wp.brilllyle@gmail.com wrote:
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
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
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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.orgmailto:wikidata-bounces@lists.wikimedia.org> on behalf of Brill Lyle <wp.brilllyle@gmail.commailto:wp.brilllyle@gmail.com> Reply-To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.orgmailto:wikidata@lists.wikimedia.org> Date: Wednesday, May 4, 2016 at 1:10 PM To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.orgmailto: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:BrillLylehttps://en.wikipedia.org/wiki/User:BrillLyle Secretary, Wikimedia NYChttps://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC
On Wed, May 4, 2016 at 8:15 AM, Andrew Gray <andrew.gray@dunelm.org.ukmailto:andrew.gray@dunelm.org.uk> wrote: On 3 May 2016 at 17:47, Brill Lyle <wp.brilllyle@gmail.commailto:wp.brilllyle@gmail.com> wrote:
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
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.ukmailto:andrew.gray@dunelm.org.uk
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.orgmailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@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”:
