On Wed, Jun 12, 2013 at 4:47 PM, Aarti K. Dwivedi wrote:
> If I am not wrong, as of today, most books that were born digital, are
> still under copyright. Of course, they are available freely on the
> internet. But we can't use the pirated copies. How would we go about the
> procurement of these
When we tried to convert into wiki code (a needed step to add links and to
convert files into a "wiki hypertext") a pdf file, that's a opaque, closed
format, such a work turned off in a nightmare. If we simply load free pdf
books "as they are", I don't see any advantage, but "feed wikisource
number
Nobody is saying anything about using copyrighted works, there are many
books that have an open license that would allow to include them in
Wikisource.
For instance in ca-ws we have this translation from 2009:
http://ca.wikisource.org/wiki/Llibre:El_secret_de_l%E2%80%99or_que_creix_%282009%29.djvu
If I am not wrong, as of today, most books that were born digital, are
still under copyright. Of course, they are available freely on the
internet. But we can't use the pirated copies. How would we go about the
procurement of these books?
If we procure these copyrighted books, then the only we woul
On 06/12/2013 02:48 PM, Andrea Zanni wrote:
We could define some tasks as
* corrected the page
* OPTIONAL added optional templates/links/annotations
*...
Geotagged all the photos, ...
The list doesn't end. You need a generic mechanism
for any new feature you can invent. But aren't our
existing
I think everything is doable, the problem is how to do it without
cluttering the interface and keeping things simple.
Some levels might be redundant and we could take the chance to think if
they are really necessary.
Some proposed changes:
- Proofread page levels: "Unused", "Proofread", "Proofrea
On Wed, Jun 12, 2013 at 2:32 PM, Thibaut Horel wrote:
> 3. The current system with 4 quality levels to represent the proofreading
> state of a page is not sufficient to represent the diversity of
> proofreading scenarios. Indeed, there is a distinction to make between the
> *correctness* of the te
Hi everybody,
Here is my attempt at giving my point of view while trying to summarize
the discussion:
1. I think the role of Index: pages should be to present the *source* of
a work. This is true whether the source is a scanned edition (as is most
often the case at the moment), or a digital PDF (
On Wed, Jun 12, 2013 at 1:32 PM, billinghurst wrote:
> If you are talking about how we represent digitally prepared text with the
> validation process. I would have no issue with the text being ripped and
> having a bot run through and taking it straight to level 4 (green), and
> then redefining g
You need to be cautious talking about "PDF" documents, as it is not the
document presentation format, it is the source of the text. So I like to
talk as the source being digitally prepared (and not requiring validation,
though may require formatting), or OCR'd (requiring validation, and
probably fo
@Billinghurst, I think Aubrey was referring mainly to pdf files, which
sometimes have text and format but they are not that easy to represent in
Wikisource. The main problem is that our current workflow always assume
that we are going to proofread a text and have it stored as a web page.
@others:
On Tue, 11 Jun 2013 12:16:54 +0530, "Aarti K. Dwivedi"
wrote:
> A slighly off-topic question: Even if we modify the extension to
proofread
> books which do not have scans( I am assuming books that were born
digital
> ), against what
> will these books be proofread?
>
I am not sure why we are loo
I apologyze
" The server too can't solve *some* apostrophes concatenation"
Alex
2013/6/11 Alex Brollo
> You're right Aubrey nevertheless while promoving a user friendly interface
> the result is that data and wiki code is extremely difficult to use as a
> clean "data base". Think only to
You're right Aubrey nevertheless while promoving a user friendly interface
the result is that data and wiki code is extremely difficult to use as a
clean "data base". Think only to wiki markup and the "simple" trick to mark
bold and italic text with apostophes very user friendly, but something
On Tue, Jun 11, 2013 at 8:41 AM, Thomas PT wrote:
> Sorry if my answer is off-topic but if metadata are stored in WIkidata, is
> it really needed to create index pages to store the same data as Wikidata?
> As I see the things, we'll have bibliographical metadata on Wikidata
> (title, author, date
n from the index page
>> TOC (but it allows also to override data).
>>
>> Tpt
>>
>> --------------
>> Date: Tue, 11 Jun 2013 01:33:39 +0200
>> From: alex.bro...@gmail.com
>> To: wikisource-l@lists.wikimedia.org
>> Subject: Re: [Wik
e This
> template outputs automatically metadata and navigation from the index page
> TOC (but it allows also to override data).
>
> Tpt
>
> --
> Date: Tue, 11 Jun 2013 01:33:39 +0200
> From: alex.bro...@gmail.com
> To: wikisource-l@lists.wikim
s template outputs automatically metadata and navigation from the index page
TOC (but it allows also to override data).
Tpt
Date: Tue, 11 Jun 2013 01:33:39 +0200
From: alex.bro...@gmail.com
To: wikisource-l@lists.wikimedia.org
Subject: Re: [Wikisource-l] About texts without supporting files and
&quo
I'm going to test what you are telling in a real Lua script; as you know,
Lua can read the code of any page with one "expensive" server function
only, so that a simple {{header|index name}} ns0 template call could read
all the wiki code from index page, parse it, extract all its data content,
and u
No, it won't be stored in Wikisource, but still there is the need to
present the information in a consistent manner.
If you want to display the information on ns0, you will end up needing the
same fields that the "Index:" page is using now.
So why not to have the same solution for both?
It could a
Simply there is no need to store data twice or more, if they are
dinamically imported from wikidata. Such data would be simply generated by
a normal template. Something similar to Commons media sharing: most
wikipedians but beginners know that when you want to edit a shared media
file, you must do
@Alex: but what do you think of storing the source information in "Index:"
pages for all works stored in Wikisource, even if they don't have a
supporting scan?
That was the original question :)
About your proposed library, it would be more useful if it could modify
data in Wikidata, not only impo
I don't see the need to change deeply Index/ns0 relationship, while I
appreciate the idea "promote coherence reducing redundance" (many years ago
I painfully used dBase III - dBase IV and I learned that principle by "try
and learn").
Here: http://www.mediawiki.org/wiki/Extension_talk:Scribunto/Bra
Hi,
There was a thread some time ago where there were talks of having books
which were born digital. These pages wouldn't have scans.
What the 'Index' page would have in these cases is something I am not very
sure about.
Cheers,
Rtdwivedi
On Mon, Jun 10, 2013 at 10:47 PM, David Cuenca wrot
With the deployment of Wikidata it is a good moment to re-examine what
"Index" pages are and what should be their function.
The most direct transition to a Wikidata-supported Wikisource could be
something like this:
https://sites.google.com/site/dacuetu/BookData.pdf
That would allow:
- to share da
25 matches
Mail list logo
