Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
On Wed, Nov 6, 2013 at 2:12 AM, billinghurst 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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
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 wrote: > On Tue, 5 Nov 2013 17:27:02 +0100, Andrea Zanni > wrote: > > About this: > > > > On Tue, Nov 5, 2013 at 2:13 PM, David Cuenca 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_should_deal_with_TemplateData > >> > > > > 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 > ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
On Tue, 5 Nov 2013 17:27:02 +0100, Andrea Zanni wrote: > About this: > > On Tue, Nov 5, 2013 at 2:13 PM, David Cuenca 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_should_deal_with_TemplateData >> > > 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
Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
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 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
> wrote:
>
>> 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 translatio
Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
About this: On Tue, Nov 5, 2013 at 2:13 PM, David Cuenca 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_should_deal_with_TemplateData > 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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
> > 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_Interpretation_of_Dreams&action=edit > > 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=0AlPNcNlN2oqvdFQyR2F5YmhrMWpXaUFkWndQWUZyemc#gid=0 Aubrey > On Sat, Nov 2, 2013 at 4:30 PM, Lydia Pintscher < > lydia.pintsc...@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 > wikisourc...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikisource-l > > ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] next sister project: Wikisource
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_should_deal_with_TemplateData
- 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 wrote:
> 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 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
