There is still to implement output of forms statements when the RDF representation of a lexeme is requested (i.e. Special:EntityData/L42.ttl) and the schema:inLanguage relation for lexemes.

Great! Thanks!

Merging the current namespace fix in the next SWAT looks like a sensible thing to do to have the namespaces properly working.

@Urbanecm Hey, it would be much better to not allocate custom namespace ids for the Page: and Index: namespaces but just let ProofreadPage setup the two namespaces with the proper names with the standard namespaces 250 and 252. I just did a change to ProofreadPage for that: https://gerrit.wikimedia.org/r/440010

Do you think it's okay to change the keys for ores responses from "1" to "one".

An example:

Thank you for the reminder!

I have updated the draft of RDF implementation change: https://gerrit.wikimedia.org/r/c/433953
It uses the existing namespace for Lexemes specific terms but provides a new ontology file which URI is http://wikiba.se/lexeme/ontology# (but it could be easily changed)

Not sure if you are proposing prefix as http://wikiba.se/lexeme/ontology/ or as http://wikiba.se/lexeme/ontology#.

Thank you for your feedbacks!

@Kaganer Thank you for your input.

Ok, so it seems to not be fully fixed :-(.

The full list of terms we have to define is:

@Dick_Bos @Peteforsyth @Vladis13 @Bodhisattwa A change that should fix this problem has just been deployed on Wikisource. Could you confirm that this bug is not happening anymore after having purge your browser cache [1]?

why not just http://wikiba.se/ontology# ?

Ok for the file. For the canonical namespace URI should we use something like "http://wikiba.se/ontology-lexeme#" to have something similar to "http://wikiba.se/ontology-beta#"? Or maybe "http://wikiba.se/lexeme/ontology#"? Should we also use the beta tag (that looks a lot like the FOAF version trap)?

@daniel Do you think that the ontology terms specific to lexemes should live in the same namespace and ontology definition file as the other Wikibase terms or should we create a new namespace?

I have made some prototypes here:

• GlobeCoordinate: https://test2.wikipedia.org/wiki/Module:GlobeCoordinate
• Time: https://test2.wikipedia.org/wiki/Module:Time

@Billinghurst Yes, the change that have been done in ProofreadPage only allows to change the ProofreadPage behavior, it does not change anything by itself. The change to zhwikisource should be done using a site request after a consensus on zhwikisource.

I have started a draft of mapping of the Lexeme DataModel to RDF: https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/RDF_mapping

The change have been deployed and seems to work.

I changed the title of T192199. The bug affects both page creation and edition. I merge this task as duplicate.

Thank you for the report. This seems to be the same problem as T192199. A possible fix is going to be deploy next week (this is a concurrency bug so it's hard to know if it'll be fix for everyone or not)

The index https://fr.wikisource.org/wiki/Livre:Nouveau_Larousse_illustr%C3%A9,_1898,_IV_test.djvu is not ok because the local parsing of the file is not ok too: https://fr.wikisource.org/wiki/Fichier:Nouveau_Larousse_illustr%C3%A9,_1898,_IV_test.djvu

@Yann The file parsing is still failing on frwikisource: https://fr.wikisource.org/wiki/Fichier:Nouveau_Larousse_illustr%C3%A9,_1898,_IV_test.djvu
So, it still seems to be a problem related to the file parsing. ProofreadPage returns the "Numeric value expected" error if the file has "null" pages: https://github.com/wikimedia/mediawiki-extensions-ProofreadPage/blob/master/includes/Parser/PagelistTagParser.php#L64

Thank you for the bug report. It seems that MediaWiki have troubles parsing the DjVu files. For example: https://commons.wikimedia.org/wiki/File:Nouveau_Larousse_illustr%C3%A9,_1898,_III.djvu
reports that the file images have a size of 0 x 0 pixels and 0 pages. It's why the parsing of the <pagelist/> tag fails.

A relevant related W3C specification draft: https://www.w3.org/TR/wpub/ and https://www.w3.org/TR/pwp/
It's an aim to make ePub and web work together.
A possibility is to have an ePub/webPublication output system and then use converters targeting multiple formats (PDF, mobi...). It's the approach used by wexport.

It's probably related to change that changes slightly the loading order: https://phabricator.wikimedia.org/rEPRP3fb0fc8cb5da4778332dbf2aac7caec518e79d0b