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:
- 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(a)gmail.com>wrote;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 <dacuetu(a)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(a)wikimedia.de>wrote;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 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(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
> >
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
_______________________________________________
Wikisource-l mailing list
Wikisource-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l