Hi,
There are plenty of ways in which Wikidata and VisualEditor could be integrated. Let me ask about the following one:
Given: Let's imagine that the venerable {{Infobox settlement}} template is fully adapted for pulling the data from Wikidata. All the relevant data about the city of Bratislava is entered into its item page on wikidata.org, and in the source of the article [[Bratislava]] you only need to say {{Infobox settlement}} without any parameters.
The people of Bratislava elect a new mayor, and I want to write it in the article. I come to the article [[Bratislava]] and press edit. I click the infobox.
What happens?
As far as I know, no work has been done in this area; PLEASE CORRECT ME if I'm wrong.
My Super-Dream scenario is to be able to edit the Mayor's name write there in the infobox, but I realize that it might be complicated.
My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item.
My acceptable-but-suboptimal scenario is taking the user to https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template ("|mayor =[[Milan Ftáčnik]]") than to go to https://www.wikidata.org/wiki/Q6850543 and find the value.
Does anybody have any more ideas about it? Am I late to the party and this has already been discussed and designed and I missed it? Please enlighten me :)
Thanks!
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Actually that feature was introduced during the Wikidata meetup by User:Vlsergey :) See: https://www.wikidata.org/wiki/Wikidata:Project_chat#Edit_directly_from_infoc...
AFAIK, at the moment it is only deployed on ruwiki, but it works! Check also his other wikidata editors: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/07#WEF_gadg...
However, this poses some problems for sourced statements...
Cheers, Micru
On Tue, Aug 12, 2014 at 9:53 AM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
Hi,
There are plenty of ways in which Wikidata and VisualEditor could be integrated. Let me ask about the following one:
Given: Let's imagine that the venerable {{Infobox settlement}} template is fully adapted for pulling the data from Wikidata. All the relevant data about the city of Bratislava is entered into its item page on wikidata.org, and in the source of the article [[Bratislava]] you only need to say {{Infobox settlement}} without any parameters.
The people of Bratislava elect a new mayor, and I want to write it in the article. I come to the article [[Bratislava]] and press edit. I click the infobox.
What happens?
As far as I know, no work has been done in this area; PLEASE CORRECT ME if I'm wrong.
My Super-Dream scenario is to be able to edit the Mayor's name write there in the infobox, but I realize that it might be complicated.
My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item.
My acceptable-but-suboptimal scenario is taking the user to https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template ("|mayor =[[Milan Ftáčnik]]") than to go to https://www.wikidata.org/wiki/Q6850543 and find the value.
Does anybody have any more ideas about it? Am I late to the party and this has already been discussed and designed and I missed it? Please enlighten me :)
Thanks!
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 12.08.2014 10:15, David Cuenca wrote:
Actually that feature was introduced during the Wikidata meetup by User:Vlsergey :) See: https://www.wikidata.org/wiki/Wikidata:Project_chat#Edit_directly_from_infoc... [5]
AFAIK, at the moment it is only deployed on ruwiki, but it works! Check also his other wikidata editors: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/07#WEF_gadg... [6]
However, this poses some problems for sourced statements...
Cheers, Micru
Especially given that ru.wiki has a pretty low citation culture.
Cheers Yaroslav
David Cuenca, 12/08/2014 10:15:
Actually that feature was introduced during the Wikidata meetup by User:Vlsergey :) See: https://www.wikidata.org/wiki/Wikidata:Project_chat#Edit_directly_from_infoc...
AFAIK, at the moment it is only deployed on ruwiki, but it works! Check also his other wikidata editors: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/07#WEF_gadg...
Is there documentation for this on a dedicated/discoverable page on Meta or wikidatawiki now?
I disagree that this (editing Wikidata properties from the page where they're transcluded) is something that can wait for the perfect solution of world famine. It's much wiser to start with localised implementations on particularly high-impact places. For instance, when we get to fetch {{bio}} data for the lead section of 250k it.wiki articles*, being able to edit it directly from it.wiki will be a killer feature. It's not so important for this to happen within VisualEditor.
We need the data in use now, not in years. (This is not Nupedia.)
Nemo
(*) Hopefully in months rather than years, given Amir has now imported all main data. https://www.wikidata.org/wiki/Wikidata:Bot_requests/Italian_Wikipedia_person_data
On Sun, Sep 14, 2014 at 9:37 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Is there documentation for this on a dedicated/discoverable page on Meta or wikidatawiki now?
https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%...
On 12 August 2014 08:53, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata.
A better scenario is that the editing wizard asks you for the date when the old mayor left office, and why (end of term, death, impeachment...) and likewise the date the new mayor took up office, if different. Then prompts you for your source(s).
2014-08-12 13:33 GMT+03:00 Andy Mabbett andy@pigsonthewing.org.uk:
On 12 August 2014 08:53, Amir E. Aharoni amir.aharoni@mail.huji.ac.il
wrote:
My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata.
A better scenario is that the editing wizard asks you for the date when the old mayor left office, and why (end of term, death, impeachment...) and likewise the date the new mayor took up office, if different. Then prompts you for your source(s).
Of course. I just have to admit that it's more complex to implement. (Maybe it can become a workflow in the future version of the Flow extension, and maybe I'm imagining too much.)
Hello,
My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item.
The problem I see here is that we mostly do not want to replace a value but rather add another preferred one and state that the old one is now deprecated. This means, we also want to have the old major on the Wikidata item but the new major should be marked as preferred. I think we have to think a lot how this can be implemented best in Visual Editor. Maybe we should just add the value entered there just as another preferred value but this is rather a guess because the data might also be simply wrong and should be replaced. We thus have to investigate how often the value should be replaced and how often the old value should be kept as well. Then we can decide a way how the visual editor should use this data without being to complicated but also offering all options to create the data as intended.
My acceptable-but-suboptimal scenario is taking the user to https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template ("|mayor =[[Milan Ftáčnik]]") than to go to https://www.wikidata.org/wiki/Q6850543 and find the value.
We might take the user to the item's page on Wikidata if he wants to make more enhanced edits like replacing an old edit.
Does anybody have any more ideas about it?
For the technical implementation, we have to find a way which data comes from which item and which property. Maybe we can add some data-item and data-property attributes to the HTML tag in which the data is stored so that the visual editor can easy find these transclusions. However, this might also be a security issue if the attributes are added to elements not containing Wikidata data.
All in all, you are surely not late and this discussion has just started at Wikimania (although it is planned much longer to have something like that). Therefore, I think this feature hasn't hightes priority at the moment and needs lots of cooperation with the Visual Editor team. Perhaps we will start developing not before 2016. (Only my personal guess. :-)
Best regards, Bene
@Bene*: The WE-Framework already has an interface for dealing with statement ranks, have you tried the latest version? https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%...
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData
Cheers, Micru
On Tue, Aug 12, 2014 at 11:19 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hello,
My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item.
The problem I see here is that we mostly do not want to replace a value but rather add another preferred one and state that the old one is now deprecated. This means, we also want to have the old major on the Wikidata item but the new major should be marked as preferred. I think we have to think a lot how this can be implemented best in Visual Editor. Maybe we should just add the value entered there just as another preferred value but this is rather a guess because the data might also be simply wrong and should be replaced. We thus have to investigate how often the value should be replaced and how often the old value should be kept as well. Then we can decide a way how the visual editor should use this data without being to complicated but also offering all options to create the data as intended.
My acceptable-but-suboptimal scenario is taking the user to
https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template ("|mayor =[[Milan Ftáčnik]]") than to go to https://www.wikidata.org/wiki/Q6850543 and find the value.
We might take the user to the item's page on Wikidata if he wants to make more enhanced edits like replacing an old edit.
Does anybody have any more ideas about it?
For the technical implementation, we have to find a way which data comes from which item and which property. Maybe we can add some data-item and data-property attributes to the HTML tag in which the data is stored so that the visual editor can easy find these transclusions. However, this might also be a security issue if the attributes are added to elements not containing Wikidata data.
All in all, you are surely not late and this discussion has just started at Wikimania (although it is planned much longer to have something like that). Therefore, I think this feature hasn't hightes priority at the moment and needs lots of cooperation with the Visual Editor team. Perhaps we will start developing not before 2016. (Only my personal guess. :-)
Best regards, Bene
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Am 13.08.2014 00:08, schrieb David Cuenca:
@Bene*: The WE-Framework already has an interface for dealing with statement ranks, have you tried the latest version? https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%...
Actually, I think this script is a very cool framework but is not that less confusing than the actual item page. I think we should hide as much information about the structure behind the data as possible (which perhaps is not that much) because otherwise the users won't understand what they're doing.
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData
Well, that's perhaps the even better idea. However, I could not find that suggestion yet.
Best regards, Bene
Am 13.08.2014 00:16, schrieb Bene*:
Am 13.08.2014 00:08, schrieb David Cuenca:
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData
Well, that's perhaps the even better idea. However, I could not find that suggestion yet.
I think it would be cool to use http://mappings.dbpedia.org/ - it already has mappings for hundreds of templates in different language versions to the dbpedia vocabulary. If we added a mapping for wikidata <-> dbpedia, it should be easy enough to derive a mapping between a wikipedia template and wikidata. Actually, I was under the impression the wikidata <-> dbpedia already existed, but I don't see it on the site right now. Adding Anja Jentzsch, she might know.
Even if it proves too tricky to map individual template parameters this way, it should still be possible to at least detect the class (instanceof) of an item based on the templates the respective wikipedia page contains. We should definitely map dpedia classes to wikidata items.
-- daniel
On Wed, Aug 13, 2014 at 12:55 AM, Daniel Kinzler < daniel.kinzler@wikimedia.de> wrote:
I think it would be cool to use http://mappings.dbpedia.org/ - it already has mappings for hundreds of templates in different language versions to the dbpedia vocabulary. If we added a mapping for wikidata <-> dbpedia, it should be easy enough to derive a mapping between a wikipedia template and wikidata. Actually, I was under the impression the wikidata <-> dbpedia already existed, but I don't see it on the site right now. Adding Anja Jentzsch, she might know.
Even if it proves too tricky to map individual template parameters this way, it should still be possible to at least detect the class (instanceof) of an item based on the templates the respective wikipedia page contains. We should definitely map dpedia classes to wikidata items.
Sergey Skovorodkin is working on a dbpedia<->wikidata mapping as a GsoC for DBpedia this year https://github.com/dbpedia/extraction-framework/wiki/GSoC-2014-Progress-Serg...
I'm CCing him to see if he can report the status or if he might need help with our properties, maybe we are missing some or need to clarify some others. Sometimes we are using qualifiers to extend properties instead of creating new ones.
Cheers, Micru
Hi everyone,
The following spreadsheet contains the latest DBpedia <-> Wikidata mapping effort both for properties and classes (cf. the 2 sheets) made by the GSoC student so far.
https://docs.google.com/spreadsheets/d/18W9xb5KXorotJ7qM58AsqK-myAHEjiDgnZrq...
Since I am his main mentor, feel free to ask me further details. Hope this helps!
Cheers,
Marco
On 8/13/14, 9:14 AM, David Cuenca wrote:
On Wed, Aug 13, 2014 at 12:55 AM, Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de> wrote:
I think it would be cool to use http://mappings.dbpedia.org/ - it already has mappings for hundreds of templates in different language versions to the dbpedia vocabulary. If we added a mapping for wikidata <-> dbpedia, it should be easy enough to derive a mapping between a wikipedia template and wikidata. Actually, I was under the impression the wikidata <-> dbpedia already existed, but I don't see it on the site right now. Adding Anja Jentzsch, she might know. Even if it proves too tricky to map individual template parameters this way, it should still be possible to at least detect the class (instanceof) of an item based on the templates the respective wikipedia page contains. We should definitely map dpedia classes to wikidata items.Sergey Skovorodkin is working on a dbpedia<->wikidata mapping as a GsoC for DBpedia this year https://github.com/dbpedia/extraction-framework/wiki/GSoC-2014-Progress-Serg...
I'm CCing him to see if he can report the status or if he might need help with our properties, maybe we are missing some or need to clarify some others. Sometimes we are using qualifiers to extend properties instead of creating new ones.
Cheers, Micru
Hi all,
The Wikidata <-> DBpedia mapping effort started last year with a manual effort lead by Hady El Hasar. See [1] for a full list of existing mappings. This year, Marco is supervising a GSoC student to generate mappings automatically, that gdoc is their current progress.
@Daniel, I remember you already had the mappings wiki in mind 2 years ago when you presented Wikidata in the MLODE 2012 / DBpedia roadmap session But it was too early for Wikidata back then, maybe now is the time to look closer at this.
We have our 2nd DBpedia Community meeting in Leipzig in 2 weeks http://wiki.dbpedia.org/meetings/Leipzig2014
We'd be glad to have Wikidata devs and community members around and discuss similar ideas.
btw, Wikidata was present in our 1st community meeting in Amsterdam with Gerard Meijssen http://wiki.dbpedia.org/meetings/Amsterdam2014?v=bej#h355-10
Cheers, DImitris
[1] http://mappings.dbpedia.org/index.php?title=Special%3ASearch&search=wiki...
On Wed, Aug 13, 2014 at 1:55 PM, Marco Fossati hell.j.fox@gmail.com wrote:
Hi everyone,
The following spreadsheet contains the latest DBpedia <-> Wikidata mapping effort both for properties and classes (cf. the 2 sheets) made by the GSoC student so far.
https://docs.google.com/spreadsheets/d/18W9xb5KXorotJ7qM58AsqK- myAHEjiDgnZrqNXHEnwk/edit#gid=716082733
Since I am his main mentor, feel free to ask me further details. Hope this helps!
Cheers,
Marco
On 8/13/14, 9:14 AM, David Cuenca wrote:
On Wed, Aug 13, 2014 at 12:55 AM, Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de> wrote:
I think it would be cool to use http://mappings.dbpedia.org/ - it already has mappings for hundreds of templates in different language versions to the dbpedia vocabulary. If we added a mapping for wikidata <-> dbpedia, it should be easy enough to derive a mapping between a wikipedia template and wikidata. Actually, I was under the impression the wikidata <-> dbpedia already existed, but I don't see it on the site right now. Adding Anja Jentzsch, she might know. Even if it proves too tricky to map individual template parameters this way, it should still be possible to at least detect the class (instanceof) of an item based on the templates the respective wikipedia page contains. Weshould definitely map dpedia classes to wikidata items.
Sergey Skovorodkin is working on a dbpedia<->wikidata mapping as a GsoC for DBpedia this year https://github.com/dbpedia/extraction-framework/wiki/ GSoC-2014-Progress-Sergey-Skovorodkin
I'm CCing him to see if he can report the status or if he might need help with our properties, maybe we are missing some or need to clarify some others. Sometimes we are using qualifiers to extend properties instead of creating new ones.
Cheers, Micru
-- Marco Fossati http://about.me/marco.fossati Twitter: @hjfocs Skype: hell_j
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Interesting discussion! Have signed up.]
On 12 August 2014 23:08, David Cuenca dacuetu@gmail.com wrote:
On Tue, Aug 12, 2014 at 11:19 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hello,
My Dream scenario is that the VE understands that the data is pulled from
Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item.
The problem I see here is that we mostly do not want to replace a value but rather add another preferred one and state that the old one is now deprecated. This means, we also want to have the old major on the Wikidata item but the new major should be marked as preferred. I think we have to think a lot how this can be implemented best in Visual Editor. Maybe we should just add the value entered there just as another preferred value but this is rather a guess because the data might also be simply wrong and should be replaced. We thus have to investigate how often the value should be replaced and how often the old value should be kept as well. Then we can decide a way how the visual editor should use this data without being to complicated but also offering all options to create the data as intended.
My acceptable-but-suboptimal scenario is taking the user to
https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template ("|mayor =[[Milan Ftáčnik]]") than to go to https://www.wikidata.org/wiki/Q6850543 and find the value.
We might take the user to the item's page on Wikidata if he wants to make more enhanced edits like replacing an old edit.
Does anybody have any more ideas about it?
For the technical implementation, we have to find a way which data comes from which item and which property. Maybe we can add some data-item and data-property attributes to the HTML tag in which the data is stored so that the visual editor can easy find these transclusions. However, this might also be a security issue if the attributes are added to elements not containing Wikidata data.
All in all, you are surely not late and this discussion has just started at Wikimania (although it is planned much longer to have something like that). Therefore, I think this feature hasn't hightes priority at the moment and needs lots of cooperation with the Visual Editor team. Perhaps we will start developing not before 2016. (Only my personal guess. :-)
@Bene*: The WE-Framework already has an interface for dealing with statement ranks, have you tried the latest version?
https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%...
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData
That's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case.
To VisualEditor, Wikidata properties are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png but is not very user-friendly.
We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language).
Longer-term I'd like to explore editing (rather than just re-using) values on Wikidata from straight within VisualEditor. However, I worry that that would need some exploration as to how we can avoid giving users a difficult set of explanations about differing community expectations of how they should work and what they should and should not do (quite apart from the different licence).
For example, a newbie-ish user of cswiktionary may not appreciate that Wikidata entries are not just magic but also done following some complicated conventions, and without a pan-wiki talk page they won't even notice that they've been bugged about making mistakes and violations until they eventually get blocked and complain that it stopped working.
Maybe the least-controversial thing to edit remotely would be language links, as they are heavily constrained and relatively simple, so maybe that would be the best place to start[2] (replacing the existing too in the sidebar).
Patches welcome! :-)
[0] – https://bugzilla.wikimedia.org/show_bug.cgi?id=50855 [1] – https://bugzilla.wikimedia.org/show_bug.cgi?id=46521 [2] – https://bugzilla.wikimedia.org/show_bug.cgi?id=52105
J.
Hello!
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateDataThat's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case.
To VisualEditor, Wikidata properties are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png but is not very user-friendly.
We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language).
Ok, the transclusion with |{{#property}}| is one point which perhaps isn't too hard to solve. However, most of the infoboxes etc. will perhaps be created by a lua module and then it isn't trivial any more to find the place some specific information comes from. This is the point I think will make the thing tricky.
Longer-term I'd like to explore editing (rather than just re-using) values on Wikidata from straight within VisualEditor. However, I worry that that would need some exploration as to how we can avoid giving users a difficult set of explanations about differing community expectations of how they should work and what they should and should not do (quite apart from the different licence).
For example, a newbie-ish user of cswiktionary may not appreciate that Wikidata entries are not just magic but also done following some complicated conventions, and without a pan-wiki talk page they won't even notice that they've been bugged about making mistakes and violations until they eventually get blocked and complain that it stopped working.
Yes, this is a problem and the reason why I suggested to make the edit interface as intuitive and simple as possible. Concerning the Wikidata policies, we may need some sort of global talk page where users can be notified from any place. However, the better way would be of course to not even let the users make mistakes by explaining the expected format well enough.
Maybe the least-controversial thing to edit remotely would be language links, as they are heavily constrained and relatively simple, so maybe that would be the best place to start[2] (replacing the existing too in the sidebar).
Patches welcome! :-)
Indeed, although the language links are also a very different thing as they are not transcluded in the article at all and do not need Visual Editor for being edited.
Best regards, Bene
On 13 August 2014 20:08, Bene* benestar.wikimedia@gmail.com wrote:
As for mapping Wikipedia templates to wikidata properties I thinkJames F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData
That's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case.
To VisualEditor, Wikidata properties are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png but is not very user-friendly.
We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language).
Ok, the transclusion with {{#property}} is one point which perhaps isn't too hard to solve. However, most of the infoboxes etc. will perhaps be created by a lua module and then it isn't trivial any more to find the place some specific information comes from. This is the point I think will make the thing tricky.
Sure, but an infobox is just a nested version of VisualEditor (or, will be soon), with each field being its own edit surface. Doing infoboxen with Lua is profoundly anti-wiki and hopefully won't be done.
Longer-term I'd like to explore editing (rather than just re-using) values on Wikidata from straight within VisualEditor. However, I worry that that would need some exploration as to how we can avoid giving users a difficult set of explanations about differing community expectations of how they should work and what they should and should not do (quite apart from the different licence).
For example, a newbie-ish user of cswiktionary may not appreciate that Wikidata entries are not just magic but also done following some complicated conventions, and without a pan-wiki talk page they won't even notice that they've been bugged about making mistakes and violations until they eventually get blocked and complain that it stopped working.
Yes, this is a problem and the reason why I suggested to make the edit interface as intuitive and simple as possible. Concerning the Wikidata policies, we may need some sort of global talk page where users can be notified from any place.
I believe that that's called Flow. :-)
However, the better way would be of course to not even let the users make mistakes by explaining the expected format well enough.
Yes, but asking the community to come up with clean, simple, concise (<10 words total or don't bother), jargon-free, easily-translated, up-to-date instructions "explaining" the format is asking a lot.
Maybe the least-controversial thing to edit remotely would be language
links, as they are heavily constrained and relatively simple, so maybe that would be the best place to start[2] (replacing the existing too in the sidebar).
Patches welcome! :-)
Indeed, although the language links are also a very different thing as they are not transcluded in the article at all and do not need Visual Editor for being edited.
Indeed, but when you're creating an article we would want to encourage users to link them to the right concept in Wikidata as part of their creation edit (timing with Wikidata's requirements that the target article exists will of course be a little challenging, but we can overcome them).
J.
Hi,
On 13 August 2014 20:16, James Forrester wrote:
On 13 August 2014 20:08, Bene* <benestar.wikimedia@gmail.com mailto:benestar.wikimedia@gmail.com>wrote:
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData That's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case. To VisualEditor, Wikidata properties are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable <https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png> but is not very user-friendly. We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language).Ok, the transclusion with |{{#property}}| is one point which perhaps isn't too hard to solve. However, most of the infoboxes etc. will perhaps be created by a lua module and then it isn't trivial any more to find the place some specific information comes from. This is the point I think will make the thing tricky.Sure, but an infobox is just a nested version of VisualEditor (or, will be soon), with each field being its own edit surface. Doing infoboxen with Lua is profoundly anti-wiki and hopefully won't be done.
Afaik the infoboxes won't have any parameters once they use Wikidata and be fully constructed using Lua. If I'm not correct I have to apologize but that's the latest thing I know.
Longer-term I'd like to explore editing (rather than just re-using) values on Wikidata from straight within VisualEditor. However, I worry that that would need some exploration as to how we can avoid giving users a difficult set of explanations about differing community expectations of how they should work and what they should and should not do (quite apart from the different licence). For example, a newbie-ish user of cswiktionary may not appreciate that Wikidata entries are not just magic but also done following some complicated conventions, and without a pan-wiki talk page they won't even notice that they've been bugged about making mistakes and violations until they eventually get blocked and complain that it stopped working.Yes, this is a problem and the reason why I suggested to make the edit interface as intuitive and simple as possible. Concerning the Wikidata policies, we may need some sort of global talk page where users can be notified from any place.I believe that that's called Flow. :-)
Great \o/
However, the better way would be of course to not even let the users make mistakes by explaining the expected format well enough.Yes, but asking the community to come up with clean, simple, concise (<10 words total or don't bother), jargon-free, easily-translated, up-to-date instructions "explaining" the format is asking a lot.
Of course it's not easy but I believe the guidelines on Wikidata aren't very strict because the system already requires special formatting. However, this needs more investigation and we have to figure out what the user can possibly make "wrong".
Best regards, Bene
On 13 August 2014 20:27, Bene* benestar.wikimedia@gmail.com wrote:
Hi,
On 13 August 2014 20:16, James Forrester wrote:
On 13 August 2014 20:08, Bene* benestar.wikimedia@gmail.com wrote:
As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData
That's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case.
To VisualEditor, Wikidata properties are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png but is not very user-friendly.
We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language).
Ok, the transclusion with {{#property}} is one point which perhaps isn't too hard to solve. However, most of the infoboxes etc. will perhaps be created by a lua module and then it isn't trivial any more to find the place some specific information comes from. This is the point I think will make the thing tricky.
Sure, but an infobox is just a nested version of VisualEditor (or, will be soon), with each field being its own edit surface. Doing infoboxen with Lua is profoundly anti-wiki and hopefully won't be done.
Afaik the infoboxes won't have any parameters once they use Wikidata and be fully constructed using Lua. If I'm not correct I have to apologize but that's the latest thing I know.
If the infobox really has no options and just builds itself entirely automatically, why not just move it out of the wikitext/etc. content entirely and display it always? This makes pages much easier to edit in wikitext (no KiB of {{…}} at the top, no confusing stuff at all, nothing to break) and simplifies a lot of things…
J.
2014-08-13 22:52 GMT+03:00 James Forrester jforrester@wikimedia.org:
On 13 August 2014 20:27, Bene* benestar.wikimedia@gmail.com wrote:
Afaik the infoboxes won't have any parameters once they use Wikidata and be fully constructed using Lua. If I'm not correct I have to apologize but that's the latest thing I know.
If the infobox really has no options and just builds itself entirely automatically, why not just move it out of the wikitext/etc. content entirely and display it always? This makes pages much easier to edit in wikitext (no KiB of {{…}} at the top, no confusing stuff at all, nothing to break) and simplifies a lot of things…
http://lists.wikimedia.org/pipermail/design/2014-August/001918.html \o/
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Am 13.08.2014 21:52, schrieb James Forrester:
On 13 August 2014 20:27, Bene* <benestar.wikimedia@gmail.com mailto:benestar.wikimedia@gmail.com>wrote:
Hi, On 13 August 2014 20:16, James Forrester wrote:On 13 August 2014 20:08, Bene* <benestar.wikimedia@gmail.com <mailto:benestar.wikimedia@gmail.com>>wrote:As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData That's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case. To VisualEditor, Wikidata properties are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable <https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png> but is not very user-friendly. We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language).Ok, the transclusion with |{{#property}}| is one point which perhaps isn't too hard to solve. However, most of the infoboxes etc. will perhaps be created by a lua module and then it isn't trivial any more to find the place some specific information comes from. This is the point I think will make the thing tricky. Sure, but an infobox is just a nested version of VisualEditor (or, will be soon), with each field being its own edit surface. Doing infoboxen with Lua is profoundly anti-wiki and hopefully won't be done.Afaik the infoboxes won't have any parameters once they use Wikidata and be fully constructed using Lua. If I'm not correct I have to apologize but that's the latest thing I know.If the infobox really has no options and just builds itself entirely automatically, why not just move it out of the wikitext/etc. content entirely and display it always? This makes pages much easier to edit in wikitext (no KiB of {{…}} at the top, no confusing stuff at all, nothing to break) and simplifies a lot of things…
I think such a feature is planned in the new Winter design. There the infobox would be placed into the right column.
Best regards, Bene
On Wed, Aug 13, 2014 at 9:52 PM, James Forrester jforrester@wikimedia.org wrote:
If the infobox really has no options and just builds itself entirely automatically, why not just move it out of the wikitext/etc. content entirely and display it always? This makes pages much easier to edit in wikitext (no KiB of {{…}} at the top, no confusing stuff at all, nothing to break) and simplifies a lot of things…
I support moving the infobox out of wikitext and into "page settings", and allowing only one infobox per article. Sometimes there are more than one which makes things unnecesarly confusing. For instance: https://en.wikipedia.org/wiki/Bonnie_and_Clyde
it could use an infobox "group of humans" that displays data of each person in the group instead of using twice "infobox person".
However I'm saying this as a Wikidatan and a rational person, not as Wikipedian :)
Cheers, Micru