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
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
wikisource-l@lists.wikimedia.org