Hey everyone,
The next sister project to get language links via Wikidata is Wikisource. We're currently planning this for January 13. The coordination is happening at https://www.wikidata.org/wiki/Wikidata:Wikisource On this page we're also looking for ambassadors to help spread the messages to the different language editions of Wikisource. Please help if you can.
Cheers Lydia
Hoi, It is very similar in content as the Commons Creator and Institution namespaces .... Thanks, Gerard
On 2 November 2013 16:30, Lydia Pintscher lydia.pintscher@wikimedia.dewrote:
Hey everyone,
The next sister project to get language links via Wikidata is Wikisource. We're currently planning this for January 13. The coordination is happening at https://www.wikidata.org/wiki/Wikidata:Wikisource On this page we're also looking for ambassadors to help spread the messages to the different language editions of Wikisource. Please help if you can.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Excellent news! :)
For the author pages it is quite straight-forward. For the bibliographic metadata the easiest would be to connect wikidata items with the "Book:" page generated by the (planned) Book Manager extension. The "Book:" page is supposed to provide the book structure and act as a metadata hub for both books with scans (those with Index: page) and books without scans (there was no solution for those yet) Project page: https://meta.wikimedia.org/wiki/Book_management Bugzilla page: https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 Example: http://tools.wmflabs.org/bookmanagerv2/mediawiki/index.php?title=Book:The_In...
Problem, the extension is not finished yet and neither Molly nor Raylton have time to keep working on it. Some bugs are still open and the fields in the template would need to be maped to Wikidata properties. All this is not relevant for phase 1 (if it is done only for books), but it will become relevant for phase 2.
Is there anyone that could volunteer as an OPW mentor to help a potential student to finish this project?
Cheers, Micru
On Sat, Nov 2, 2013 at 4:30 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
Hey everyone,
The next sister project to get language links via Wikidata is Wikisource. We're currently planning this for January 13. The coordination is happening at https://www.wikidata.org/wiki/Wikidata:Wikisource On this page we're also looking for ambassadors to help spread the messages to the different language editions of Wikisource. Please help if you can.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Two questions: *Why don't you add Wikiquote?, It's pretty look like Wikipedia in concept (you don't have to make so many new items when you add Wikiquote as client of Wikidata) *Wikisource has a big difference in interwiki mapping. you can map an item in wikisource to several item in another language (we have an open bug in bugzilla for Pywikibot about it: https://bugzilla.wikimedia.org/show_bug.cgi?id=55090) Are you going to let people to add several links with the same site in an item of Wikidata or vice verse, adding one link to several items, both of them are technically seems impossible to me because your output is dictionary (when you call API) and diciotnaries can't have several values for a key, what are you going to do about it?
Best
On 11/2/13, David Cuenca dacuetu@gmail.com wrote:
Excellent news! :)
For the author pages it is quite straight-forward. For the bibliographic metadata the easiest would be to connect wikidata items with the "Book:" page generated by the (planned) Book Manager extension. The "Book:" page is supposed to provide the book structure and act as a metadata hub for both books with scans (those with Index: page) and books without scans (there was no solution for those yet) Project page: https://meta.wikimedia.org/wiki/Book_management Bugzilla page: https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 Example: http://tools.wmflabs.org/bookmanagerv2/mediawiki/index.php?title=Book:The_In...
Problem, the extension is not finished yet and neither Molly nor Raylton have time to keep working on it. Some bugs are still open and the fields in the template would need to be maped to Wikidata properties. All this is not relevant for phase 1 (if it is done only for books), but it will become relevant for phase 2.
Is there anyone that could volunteer as an OPW mentor to help a potential student to finish this project?
Cheers, Micru
On Sat, Nov 2, 2013 at 4:30 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
Hey everyone,
The next sister project to get language links via Wikidata is Wikisource. We're currently planning this for January 13. The coordination is happening at https://www.wikidata.org/wiki/Wikidata:Wikisource On this page we're also looking for ambassadors to help spread the messages to the different language editions of Wikisource. Please help if you can.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Etiamsi omnes, ego non
Amir Ladsgroup, 03/11/2013 18:36:
Two questions: *Why don't you add Wikiquote?, It's pretty look like Wikipedia in concept (you don't have to make so many new items when you add Wikiquote as client of Wikidata)
Very true! Perhaps the proposal needs more supporters, it should be very trivial to do. https://www.wikidata.org/wiki/Wikidata:Wikiquote
*Wikisource has a big difference in interwiki mapping. you can map an item in wikisource to several item in another language (we have an open bug in bugzilla for Pywikibot about it: https://bugzilla.wikimedia.org/show_bug.cgi?id=55090) Are you going to let people to add several links with the same site in an item of Wikidata or vice verse, adding one link to several items, both of them are technically seems impossible to me because your output is dictionary (when you call API) and diciotnaries can't have several values for a key, what are you going to do about it?
There's a bug report about this in wikidata too but no time now to find the number.
Nemo
On Sun, Nov 3, 2013 at 7:59 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Amir Ladsgroup, 03/11/2013 18:36:
Two questions: *Why don't you add Wikiquote?, It's pretty look like Wikipedia in concept (you don't have to make so many new items when you add Wikiquote as client of Wikidata)
Very true! Perhaps the proposal needs more supporters, it should be very trivial to do. https://www.wikidata.org/wiki/Wikidata:Wikiquote
No need for supporters in this case :) Wikiquote is on my radar as one of the easier ones to go for after Wikisource. However what would be very helpful for me is having people sign up on the page you linked as ambassadors so we have those ready when the time comes. The same goes for all the other projects still in line. To clarify: an ambassador is knowledgeable about the project in question and Wikidata. They're willing to help with announcements and can answer questions (with my help as needed). Having that hopefully makes things go a lot smoother for everyone.
Cheers Lydia
Am 03.11.2013 19:59, schrieb Federico Leva (Nemo):
*Wikisource has a big difference in interwiki mapping. you can map an item in wikisource to several item in another language (we have an open bug in bugzilla for Pywikibot about it: https://bugzilla.wikimedia.org/show_bug.cgi?id=55090) Are you going to let people to add several links with the same site in an item of Wikidata or vice verse, adding one link to several items, both of them are technically seems impossible to me because your output is dictionary (when you call API) and diciotnaries can't have several values for a key, what are you going to do about it?
There's a bug report about this in wikidata too but no time now to find the number.
From a technical perspective, "sitelinks" have to be unique (per project),
otherwise they wouldn't function as "sitelinks" as defined by the data model (changing the data model would have in that regard would have aquite a few annoying consequences). It's entirely possible to link multiple pages on another wiki using properties/statements, though.
-- daniel
On Sun, Nov 3, 2013 at 11:32 PM, Daniel Kinzler <daniel.kinzler@wikimedia.de
wrote:
Am 03.11.2013 19:59, schrieb Federico Leva (Nemo):
*Wikisource has a big difference in interwiki mapping. you can map an item in wikisource to several item in another language (we have an open bug in bugzilla for Pywikibot about it: https://bugzilla.wikimedia.org/show_bug.cgi?id=55090) Are you going to let people to add several links with the same site in an item of Wikidata or vice verse, adding one link to several items, both of them are technically seems impossible to me because your output is dictionary (when you call API) and diciotnaries can't have several values for a key, what are you going to do about it?
There's a bug report about this in wikidata too but no time now to find
the number.
From a technical perspective, "sitelinks" have to be unique (per project), otherwise they wouldn't function as "sitelinks" as defined by the data model (changing the data model would have in that regard would have aquite a few annoying consequences). It's entirely possible to link multiple pages on another wiki using properties/statements, though.
If you're using statement instead of site link who we can trace item from
article of wikisource to wikidata and how can show the interwikis in article of wikisource? about the first one I mean "wgWikibaseItemId" and about the second one I mean the sidebar, is there a way to control sidebar through statements instead of sitelinks?
-- daniel
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Am 04.11.2013 16:10, schrieb Amir Ladsgroup:
If you're using statement instead of site link who we can trace item from article of wikisource to wikidata
This will very soon be possible with queries.
and how can show the interwikis in article of wikisource?
You can't control the sidebar directly, but you could use Lua to generate wikitext containing the appropriate links based on the wikidata item.
From a technical perspective, "sitelinks" have to be unique (per project),
Thinking about this again, I'm not sure we absolutely need there to only be one sitelink per target side on each item - we absolutely DO need it the other way around: only one data item per target page.
But even so, we would be breaking an assumption and guarantee that we have been making from early in the project, and would have to carefully investigate what we would break, and what opportunities it would spoil for the future.
-- daniel
On Mon, Nov 4, 2013 at 4:43 PM, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
Am 04.11.2013 16:10, schrieb Amir Ladsgroup:
If you're using statement instead of site link who we can trace item from article of wikisource to wikidata
This will very soon be possible with queries.
Actually a query or Lua would be much better solution for Wikisource instead of sitelinks (well, author pages can have sitelinks that is no problem).
According to the data model that we have been defining for Wikisource [1] there should be a top-level item (work item) representing all the editions that a text has, then there should be sub-items for each edition (example of a book with several translations [2]). Each one of those sub-items is the one that should be connected with a "sitelink", although there will be only of them per item.
Ideally, the script or the query should examine which items are connected with the property pair "edition/edition of", collect the sitelink of each language and list them all for each one of them.
Is that factible?
Cheers, Micru
[1] https://www.wikidata.org/wiki/Wikidata:Books_task_force [2] https://www.wikidata.org/wiki/Q6911
This sounds feasible, yes.
If I understand correctly, you want one item for each work (or work expression?), and one for each edition of that work. The editions would link back to the work with a is-edition-of property (or the other way around: the work item would have an "editions" statement for each edition; I prefer the former in principle, but must advise you to go with the latter initially - that way it will work without queries).
On wikisource, there would be a page about the work, which the work-item would have a sitelink to. On that wiki page, you would use lua to list all the editions. Each edition-item may in turn have a sitelink to a wikisource page about that edition (right?) and you want to use these to automatically generate a navigation bar.
Yes, that should work with what we have available in Lua already.
-- daniel
Am 04.11.2013 16:59, schrieb David Cuenca:
Actually a query or Lua would be much better solution for Wikisource instead of sitelinks (well, author pages can have sitelinks that is no problem).
According to the data model that we have been defining for Wikisource [1] there should be a top-level item (work item) representing all the editions that a text has, then there should be sub-items for each edition (example of a book with several translations [2]). Each one of those sub-items is the one that should be connected with a "sitelink", although there will be only of them per item.
Ideally, the script or the query should examine which items are connected with the property pair "edition/edition of", collect the sitelink of each language and list them all for each one of them.
Is that factible?
Cheers, Micru
[1] https://www.wikidata.org/wiki/Wikidata:Books_task_force [2] https://www.wikidata.org/wiki/Q6911
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Yes, that would be it: one work-item (acting as hub), x edition items connected to the work-item, each edition-item connected to its corresponding Wikisource page with a sitelink and, on Wikisource, an auto-generated nav bar that lists all sitelinks from all edition-items on the left (equivalent to the current interwiki link list). If there is more than one edition per language "author citation (P835)" or "author (P50)" value can be shown next to the language name. For connecting works with editions we already have "edition (P747)" and "edition of (P629)".
On Wikisource I don't think it is necessary to have always a "work page", this only happens when there is more than one edition for any given language. The most important part is to automate the creation of a work-item on Wikidata whenever is needed to link one edition to another (same or different languages) and, of course, show the generated nav bar on all edition pages .
Wikipedia(s) will be connected to the work-items as usual. "Template:Infobox book" needs some work to be able to show work- and edition-item data. I have started a proposal for this task as a possible Code-In, but maybe the second part needs arbitrary item access. https://www.mediawiki.org/wiki/Google_Code-In#Lua_templates
--Micru
On Mon, Nov 4, 2013 at 5:15 PM, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
This sounds feasible, yes.
If I understand correctly, you want one item for each work (or work expression?), and one for each edition of that work. The editions would link back to the work with a is-edition-of property (or the other way around: the work item would have an "editions" statement for each edition; I prefer the former in principle, but must advise you to go with the latter initially - that way it will work without queries).
On wikisource, there would be a page about the work, which the work-item would have a sitelink to. On that wiki page, you would use lua to list all the editions. Each edition-item may in turn have a sitelink to a wikisource page about that edition (right?) and you want to use these to automatically generate a navigation bar.
Yes, that should work with what we have available in Lua already.
-- daniel
Am 04.11.2013 16:59, schrieb David Cuenca:
Actually a query or Lua would be much better solution for Wikisource
instead of
sitelinks (well, author pages can have sitelinks that is no problem).
According to the data model that we have been defining for Wikisource
[1] there
should be a top-level item (work item) representing all the editions
that a text
has, then there should be sub-items for each edition (example of a book
with
several translations [2]). Each one of those sub-items is the one that
should be
connected with a "sitelink", although there will be only of them per
item.
Ideally, the script or the query should examine which items are
connected with
the property pair "edition/edition of", collect the sitelink of each
language
and list them all for each one of them.
Is that factible?
Cheers, Micru
[1] https://www.wikidata.org/wiki/Wikidata:Books_task_force [2] https://www.wikidata.org/wiki/Q6911
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
As a side issue, as any transcluded work will have an index page, and a file page at Commons, hopefully with any available data there will be some available tricks.
* having a means to import the {{book}} data from Commons to Wikidata would be really useful, whether the work is at Wikisource or not, and if it is at Wikisource, there should be the obvious connections, or exception reports if they are not.
Similarly, * for new works I see that it would be easier to 1) enter the metadata from a [book} form at WD which could then lead the way to loading the work at Commons with a {{book}} template that calls the properties, and can populate the Index namespace pages at the Wikisource. This has the value of being able to hopefully import book metadata from other sources at whatever point of time.
enWS would normally have a work at a base name, and if there was a requirement to {{disambiguate}} or {{versions}} or {{translations}} that name becomes disambiguation (or whatever), the following preference occurs Base page {{disambiguate}} >> Author differentiation {{version}} >> Author/Translator differentiation {{translations}} >> Author (Translations && || Versions)
Question. How would you think that we will handle translations of a work?
A base work will be in a language and have that reference to the language of the work
So that work may have a translation, and the it may be from a known or unknown edition of a work. Are we having "a translation of ..." and that may be on the base name, or maybe against an edition of the base? Or do you see that a translation (or each translation) of a work is a new base work as it has a new author, and they would have a link like "is a translation of" and we could capture the edition information capture there. (knowing that both the original work and the translation can go to editions)
As another note, there are times where the translation of a work is done by Wikisource volunteers, so we will know the edition, however, the translator is not an individual so how will we have a property that manages collective translation.
Regards, Billinghurst
On Tue, 5 Nov 2013 01:12:07 +0100, David Cuenca dacuetu@gmail.com wrote:
Yes, that would be it: one work-item (acting as hub), x edition items connected to the work-item, each edition-item connected to its corresponding Wikisource page with a sitelink and, on Wikisource, an auto-generated nav bar that lists all sitelinks from all edition-items
on
the left (equivalent to the current interwiki link list). If there is
more
than one edition per language "author citation (P835)" or "author (P50)" value can be shown next to the language name. For connecting works with editions we already have "edition (P747)" and "edition of (P629)".
On Wikisource I don't think it is necessary to have always a "work
page",
this only happens when there is more than one edition for any given language. The most important part is to automate the creation of a work-item on Wikidata whenever is needed to link one edition to another (same or different languages) and, of course, show the generated nav bar
on
all edition pages .
Wikipedia(s) will be connected to the work-items as usual. "Template:Infobox book" needs some work to be able to show work- and edition-item data. I have started a proposal for this task as a possible Code-In, but maybe the second part needs arbitrary item access. https://www.mediawiki.org/wiki/Google_Code-In#Lua_templates
--Micru
On Mon, Nov 4, 2013 at 5:15 PM, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
This sounds feasible, yes.
If I understand correctly, you want one item for each work (or work expression?), and one for each edition of that work. The editions would link back to the work with a is-edition-of property (or the other way
around:
the work item would have an "editions" statement for each edition; I prefer the former in principle, but must advise you to go with the latter
initially
that way it will work without queries).
On wikisource, there would be a page about the work, which the
work-item
would have a sitelink to. On that wiki page, you would use lua to list all
the
editions. Each edition-item may in turn have a sitelink to a wikisource page about that edition (right?) and you want to use these to automatically generate a navigation bar.
Yes, that should work with what we have available in Lua already.
-- daniel
Am 04.11.2013 16:59, schrieb David Cuenca:
Actually a query or Lua would be much better solution for Wikisource
instead of
sitelinks (well, author pages can have sitelinks that is no
problem).
According to the data model that we have been defining for Wikisource
[1] there
should be a top-level item (work item) representing all the editions
that a text
has, then there should be sub-items for each edition (example of a
book
with
several translations [2]). Each one of those sub-items is the one
that
should be
connected with a "sitelink", although there will be only of them per
item.
Ideally, the script or the query should examine which items are
connected with
the property pair "edition/edition of", collect the sitelink of each
language
and list them all for each one of them.
Is that factible?
Cheers, Micru
[1] https://www.wikidata.org/wiki/Wikidata:Books_task_force [2] https://www.wikidata.org/wiki/Q6911
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Thank you for mentioning all this, it is not related to phase 1, but it is good to plan ahead.
- Import book data from Commons: yes, that is possible with bots. And it is also possible to have bots to generate lists that don't comply with certain conditions (like: has "scan file (P996)" but doesn't have sitelink to wikisource). When it is ready, with queries it should be possible to generate such lists too.
- Connecting templates to Wikidata: there is the need to have a way to map template fields with Wikidata properties. This requires a broad discussion since it affects many projects, if not all. In fact, some days ago I asked James F. to open a RFC concerning this subject. I think this might be one of the reasons why Wikidata contents are not very used in Wikipedia. It is possible to do it with Lua, but still too hard for the average user.
- Connecting new uploaded books with Wikidata: again this is very related to the above. As a first preparatory step, one GsoC of this year worked on using templates (like "commons:Template:Book") directly with the UploadWizard. It generates the form according to a template, which in turn could create both a Wikidata item and a Wikisource page when the uploaded file is a book. However this has been stalled due to this RFC on Commons: https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/How_Commons_...
- Naming conventions: that is up to each project to decide and Wikidata doesn't change anything in that regard (i.e. the name of the sitelink doesn't matter).
- Translations of specific editions: to indicate from which edition a translation was made, the easiest will be to have a property in Wikidata. It could be a "translation of", "derived from", or maybe even "based on (P144)" could be extended to represent that. This doesn't affect interwiki linking, since it is a metadata property similar to "author", "date", etc.
- User translations: In Wikidata we already have "translator (P655)" which can be used with "Wikisource (Q263)" or another item can be created to represent this, like "Wikisource community".
Summing up, there are a lot of pieces coming together but for now we should focus on phase 1, getting interwikis to work right with the proposed structure, and allowing time for the users to familiarize with Wikidata.
Cheers, Micru
On Tue, Nov 5, 2013 at 10:26 AM, billinghurst billinghurst@gmail.comwrote:
As a side issue, as any transcluded work will have an index page, and a file page at Commons, hopefully with any available data there will be some available tricks.
- having a means to import the {{book}} data from Commons to Wikidata
would be really useful, whether the work is at Wikisource or not, and if it is at Wikisource, there should be the obvious connections, or exception reports if they are not.
Similarly,
- for new works I see that it would be easier to 1) enter the metadata
from a [book} form at WD which could then lead the way to loading the work at Commons with a {{book}} template that calls the properties, and can populate the Index namespace pages at the Wikisource. This has the value of being able to hopefully import book metadata from other sources at whatever point of time.
enWS would normally have a work at a base name, and if there was a requirement to {{disambiguate}} or {{versions}} or {{translations}} that name becomes disambiguation (or whatever), the following preference occurs Base page {{disambiguate}} >> Author differentiation {{version}} >> Author/Translator differentiation {{translations}} >> Author (Translations && || Versions)
Question. How would you think that we will handle translations of a work?
A base work will be in a language and have that reference to the language of the work
So that work may have a translation, and the it may be from a known or unknown edition of a work. Are we having "a translation of ..." and that may be on the base name, or maybe against an edition of the base? Or do you see that a translation (or each translation) of a work is a new base work as it has a new author, and they would have a link like "is a translation of" and we could capture the edition information capture there. (knowing that both the original work and the translation can go to editions)
As another note, there are times where the translation of a work is done by Wikisource volunteers, so we will know the edition, however, the translator is not an individual so how will we have a property that manages collective translation.
Regards, Billinghurst
On Tue, 5 Nov 2013 01:12:07 +0100, David Cuenca dacuetu@gmail.com wrote:
Yes, that would be it: one work-item (acting as hub), x edition items connected to the work-item, each edition-item connected to its corresponding Wikisource page with a sitelink and, on Wikisource, an auto-generated nav bar that lists all sitelinks from all edition-items
on
the left (equivalent to the current interwiki link list). If there is
more
than one edition per language "author citation (P835)" or "author (P50)" value can be shown next to the language name. For connecting works with editions we already have "edition (P747)" and "edition of (P629)".
On Wikisource I don't think it is necessary to have always a "work
page",
this only happens when there is more than one edition for any given language. The most important part is to automate the creation of a work-item on Wikidata whenever is needed to link one edition to another (same or different languages) and, of course, show the generated nav bar
on
all edition pages .
Wikipedia(s) will be connected to the work-items as usual. "Template:Infobox book" needs some work to be able to show work- and edition-item data. I have started a proposal for this task as a possible Code-In, but maybe the second part needs arbitrary item access. https://www.mediawiki.org/wiki/Google_Code-In#Lua_templates
--Micru
On Mon, Nov 4, 2013 at 5:15 PM, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
This sounds feasible, yes.
If I understand correctly, you want one item for each work (or work expression?), and one for each edition of that work. The editions would link back to the work with a is-edition-of property (or the other way
around:
the work item would have an "editions" statement for each edition; I prefer the former in principle, but must advise you to go with the latter
initially
that way it will work without queries).
On wikisource, there would be a page about the work, which the
work-item
would have a sitelink to. On that wiki page, you would use lua to list all
the
editions. Each edition-item may in turn have a sitelink to a wikisource page about that edition (right?) and you want to use these to automatically generate a navigation bar.
Yes, that should work with what we have available in Lua already.
-- daniel
Am 04.11.2013 16:59, schrieb David Cuenca:
Actually a query or Lua would be much better solution for Wikisource
instead of
sitelinks (well, author pages can have sitelinks that is no
problem).
According to the data model that we have been defining for Wikisource
[1] there
should be a top-level item (work item) representing all the editions
that a text
has, then there should be sub-items for each edition (example of a
book
with
several translations [2]). Each one of those sub-items is the one
that
should be
connected with a "sitelink", although there will be only of them per
item.
Ideally, the script or the query should examine which items are
connected with
the property pair "edition/edition of", collect the sitelink of each
language
and list them all for each one of them.
Is that factible?
Cheers, Micru
[1] https://www.wikidata.org/wiki/Wikidata:Books_task_force [2] https://www.wikidata.org/wiki/Q6911
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
About this:
On Tue, Nov 5, 2013 at 2:13 PM, David Cuenca dacuetu@gmail.com wrote:
Connecting new uploaded books with Wikidata: again this is very related to the above. As a first preparatory step, one GsoC of this year worked on using templates (like "commons:Template:Book") directly with the UploadWizard. It generates the form according to a template, which in turn could create both a Wikidata item and a Wikisource page when the uploaded file is a book. However this has been stalled due to this RFC on Commons:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/How_Commons_...
how this concerns us?
Sorry, but I don't really understand this TemplateData issue. Uploading books directly from Wikisource (entering all the important metadata, that would go to Commons, Wikisource and Wikidata) is a crucial *feature* that we absolutely need. What is the problem, here, specifically?
Thanks!
Aubrey
On Tue, 5 Nov 2013 17:27:02 +0100, Andrea Zanni zanni.andrea84@gmail.com wrote:
About this:
On Tue, Nov 5, 2013 at 2:13 PM, David Cuenca dacuetu@gmail.com wrote:
Connecting new uploaded books with Wikidata: again this is very related to the above. As a first preparatory step, one GsoC of this year worked on using templates (like "commons:Template:Book") directly with the UploadWizard. It generates the form according to a template, which in turn could create both a Wikidata item and a Wikisource page when the
uploaded
file is a book. However this has been stalled due to this RFC on
Commons:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/How_Commons_...
how this concerns us?
Sorry, but I don't really understand this TemplateData issue. Uploading books directly from Wikisource (entering all the important metadata, that would go to Commons, Wikisource and Wikidata) is a
crucial
*feature* that we absolutely need. What is the problem, here, specifically?
Thanks!
Aubrey
From my point of view, an upload form should be focused at Wikidata more
than at Commons, anything else is back-to-front.
If we are talking about a published work that it is published is its own "notability" and transcends whether it is at Wikisource, Commons, or Wikipedia, such that it is published makes it Wikidata-able (to coin a word). We can easily support this statement as copyright alone will prevent a work from appearing at Wikisource or WikiCommons, and similarly some published works may not be individually notable for Wikipedia, but may be so for other reference, thinking here of things that have a DOI.
*Then* comes the issue of which site wishes to utilise the data. So having Wikidata as the primary entry point to enter "book" data, and then call it from other places as required seems the logical place to start for any new work at any of the places.
Regards Billinghurst
Hoi, This makes perfect sense because Wikidata WANTS to use this information as the source for statements. Thanks, GerardM
On 6 November 2013 02:12, billinghurst billinghurst@gmail.com wrote:
On Tue, 5 Nov 2013 17:27:02 +0100, Andrea Zanni zanni.andrea84@gmail.com wrote:
About this:
On Tue, Nov 5, 2013 at 2:13 PM, David Cuenca dacuetu@gmail.com wrote:
Connecting new uploaded books with Wikidata: again this is very related to the above. As a first preparatory step, one GsoC of this year worked on using templates (like "commons:Template:Book") directly with the UploadWizard. It generates the form according to a template, which in turn could create both a Wikidata item and a Wikisource page when the
uploaded
file is a book. However this has been stalled due to this RFC on
Commons:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/How_Commons_...
how this concerns us?
Sorry, but I don't really understand this TemplateData issue. Uploading books directly from Wikisource (entering all the important metadata, that would go to Commons, Wikisource and Wikidata) is a
crucial
*feature* that we absolutely need. What is the problem, here, specifically?
Thanks!
Aubrey
From my point of view, an upload form should be focused at Wikidata more than at Commons, anything else is back-to-front.
If we are talking about a published work that it is published is its own "notability" and transcends whether it is at Wikisource, Commons, or Wikipedia, such that it is published makes it Wikidata-able (to coin a word). We can easily support this statement as copyright alone will prevent a work from appearing at Wikisource or WikiCommons, and similarly some published works may not be individually notable for Wikipedia, but may be so for other reference, thinking here of things that have a DOI.
*Then* comes the issue of which site wishes to utilise the data. So having Wikidata as the primary entry point to enter "book" data, and then call it from other places as required seems the logical place to start for any new work at any of the places.
Regards Billinghurst
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Wed, Nov 6, 2013 at 2:12 AM, billinghurst billinghurst@gmail.com wrote:
From my point of view, an upload form should be focused at Wikidata more than at Commons, anything else is back-to-front.
If we are talking about a published work that it is published is its own "notability" and transcends whether it is at Wikisource, Commons, or Wikipedia, such that it is published makes it Wikidata-able (to coin a word). We can easily support this statement as copyright alone will prevent a work from appearing at Wikisource or WikiCommons, and similarly some published works may not be individually notable for Wikipedia, but may be so for other reference, thinking here of things that have a DOI.
*Then* comes the issue of which site wishes to utilise the data. So having Wikidata as the primary entry point to enter "book" data, and then call it from other places as required seems the logical place to start for any new work at any of the places.
I'm not sure if I understand correctly, but the Book Upload Form should be primarly on Wikisource, listing Wikidata properties, and uploading the image on Commons. All the metadata would be the same, stored on Wikidata, and transcluded in COmmons and Wikisource.
On Wikidata, you can *already* go, insert a new item or modifying and existing one, adding all the book properties you want. Books properties can be found here: https://www.wikidata.org/wiki/Wikidata:Books_task_force Now, of course we would very much like a tool like this ( https://www.wikidata.org/wiki/User:Magnus_Manske/missing_props.js), which suggests all the missing properties when the item is a book. We would need it also for journals, and journal articles.
But where the Upload form, right now, is needed the most is on Wikisource (and Commons), IMHO.
Aubrey
Am 05.11.2013 01:12, schrieb David Cuenca:
Yes, that would be it: one work-item (acting as hub), x edition items connected to the work-item, each edition-item connected to its corresponding Wikisource page with a sitelink and, on Wikisource, an auto-generated nav bar that lists all sitelinks from all edition-items on the left (equivalent to the current interwiki link list). If there is more than one edition per language "author citation (P835)" or "author (P50)" value can be shown next to the language name. For connecting works with editions we already have "edition (P747)" and "edition of (P629)".
OK, I think I understand now: the issue is that Wikisource wants language links on edition pages not from that edition's data item (since an edition can generally only exist in one language anyway), but wants to use the items of different editions of the same work in different languages to generate language links.
A long as there is only one edition per language, this would work: Lua could generate the corresponding language links (we may have to tweak the lua binding a bit, but that should not be a problem).
However, MediaWiki only supports one link per target site in the sidebar.
Maybe an on-page navigation box could be used instead of "proper" language links?
With the help of JavaScript, the contents of that nav box could then be moved into the sidebar. That's a bit hackish, but would work ok, I think.
On Wikisource I don't think it is necessary to have always a "work page", this only happens when there is more than one edition for any given language.
I think it would be a good idea to always have that, for consistency and structural integrity.
The most important part is to automate the creation of a work-item on Wikidata whenever is needed to link one edition to another (same or different languages) and, of course, show the generated nav bar on all edition pages .
That should be done by a bot.
Wikipedia(s) will be connected to the work-items as usual. "Template:Infobox book" needs some work to be able to show work- and edition-item data. I have started a proposal for this task as a possible Code-In, but maybe the second part needs arbitrary item access. https://www.mediawiki.org/wiki/Google_Code-In#Lua_templates
nice!
-- daniel
On Tue, Nov 5, 2013 at 5:35 PM, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
However, MediaWiki only supports one link per target site in the sidebar.
Maybe an on-page navigation box could be used instead of "proper" language links?
With the help of JavaScript, the contents of that nav box could then be moved into the sidebar. That's a bit hackish, but would work ok, I think.
On English Wikisource they were using this template to allow more than one link per language: https://en.wikisource.org/wiki/Template:Interwiki-info
However it seems that is not working now on this page (the interwiki list should be much larger according to the wikitext): https://en.wikisource.org/wiki/The_Raven_%28Poe%29
I think it would be a good idea to always have that, for consistency and structural integrity.
It makes sense to create "work pages" for works with several editions in a given language (5-10% depending on language) since it is the equivalent of having a desambiguation page, but having a big number of "work pages" on Wikisource for works that only have one edition might be detrimental for the user experience, unless they are redirects. How far is the development of using redirect pages as sitelinks?
--Micru
Am 06.11.2013 13:43, schrieb David Cuenca:
On English Wikisource they were using this template to allow more than one link per language: https://en.wikisource.org/wiki/Template:Interwiki-info
However it seems that is not working now on this page (the interwiki list should be much larger according to the wikitext): https://en.wikisource.org/wiki/The_Raven_%28Poe%29
MediaWiki used to handle this inconsistently: multiple links for the same language where shown in the sidebar, but not recorded in the database. This inconsistency was fixed a few months ago - now, only one link per page can exist. I suppose that's why the template no longer works.
language (5-10% depending on language) since it is the equivalent of having a desambiguation page, but having a big number of "work pages" on Wikisource for works that only have one edition might be detrimental for the user experience, unless they are redirects. How far is the development of using redirect pages as sitelinks?
I'm not suggesting to always great a work *page* on wikisource, even if there is only one edition in that language. I'm saying that there should always be an *item* for the work on wikidata, even if there is only an item for one edition.
-- daniel
On Wed, Nov 6, 2013 at 4:22 PM, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
MediaWiki used to handle this inconsistently: multiple links for the same language where shown in the sidebar, but not recorded in the database. This inconsistency was fixed a few months ago - now, only one link per page can exist. I suppose that's why the template no longer works.
Someone's bug is someone else's feature... Anyhow, on fr-ws they already have a custom menu on the left to link with other wikimedia projects ("Compléments") which is loaded by: https://fr.wikisource.org/wiki/MediaWiki:Common.js Example: https://fr.wikisource.org/wiki/Victor_Hugo If you want to add a similar menu for editions then it should be compatible with: https://www.mediawiki.org/wiki/Extension:DoubleWiki
I'm not suggesting to always great a work *page* on wikisource, even if
there is only one edition in that language. I'm saying that there should always be an *item* for the work on wikidata, even if there is only an item for one edition.
Sorry, I misunderstood you. Yes, I agree it makes sense to create an item for the work on wikidata.
Micru
On Sun, Nov 3, 2013 at 6:36 PM, Amir Ladsgroup ladsgroup@gmail.com wrote:
Two questions: *Why don't you add Wikiquote?, It's pretty look like Wikipedia in concept (you don't have to make so many new items when you add Wikiquote as client of Wikidata)
One project after the other :) They'll all be added in due time. But for the benefit of the community I am taking this slowly to give everyone time to sort things out and adjust. I understand everyone is eager to have their favorite project added to Wikidata but if we take this too quickly it'll just make us all miserable.
*Wikisource has a big difference in interwiki mapping. you can map an item in wikisource to several item in another language (we have an open bug in bugzilla for Pywikibot about it: https://bugzilla.wikimedia.org/show_bug.cgi?id=55090) Are you going to let people to add several links with the same site in an item of Wikidata or vice verse, adding one link to several items, both of them are technically seems impossible to me because your output is dictionary (when you call API) and diciotnaries can't have several values for a key, what are you going to do about it?
It will be handled like the other projects we have so far. Which is why I am giving so much time to sort this all out and come to decisions at https://www.wikidata.org/wiki/Wikidata:Wikisource
Cheers Lydia
For the author pages it is quite straight-forward. For the bibliographic metadata the easiest would be to connect wikidata items with the "Book:" page generated by the (planned) Book Manager extension. The "Book:" page is supposed to provide the book structure and act as a metadata hub for both books with scans (those with Index: page) and books without scans (there was no solution for those yet) Project page: https://meta.wikimedia.org/wiki/Book_management Bugzilla page: https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 Example: http://tools.wmflabs.org/bookmanagerv2/mediawiki/index.php?title=Book:The_In...
Problem, the extension is not finished yet and neither Molly nor Raylton
have time to keep working on it. Some bugs are still open and the fields in the template would need to be maped to Wikidata properties. All this is not relevant for phase 1 (if it is done only for books), but it will Excellent news! :) become relevant for phase 2.
Is there anyone that could volunteer as an OPW mentor to help a potential student to finish this project?
The page looks nice. It's a pity it's incomplete.
I can volunteer for the metadata/librarian part (the metadata structure should be Dublin Core compliant, and as DC every field should be optional and repeatable). Moreover, we would desperately need to import and export metadata. Tpt made the Index page OAI-PMH compliant, is this too? Of course, these fields should be integrated with WD properties :-)
We still have this draft mapping: https://docs.google.com/spreadsheet/ccc?key=0AlPNcNlN2oqvdFQyR2F5YmhrMWpXaUF...
Aubrey
On Sat, Nov 2, 2013 at 4:30 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
Hey everyone,
The next sister project to get language links via Wikidata is Wikisource. We're currently planning this for January 13. The coordination is happening at https://www.wikidata.org/wiki/Wikidata:Wikisource On this page we're also looking for ambassadors to help spread the messages to the different language editions of Wikisource. Please help if you can.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Etiamsi omnes, ego non
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l