Talk:Wikisource reader app
Add topicLatest comment: 19 days ago by Bodhisattwa in topic Mandatory label in native language
Mini feedback
[edit]First of all, many thanks and congratulations on developing this app! I have just one little feedback: I am not sure about using Wikisource index page URL (P1957). Personally I never add that property to Wikidata editions, because it feels completely redundant, and there is no obvious way to search for it, so you need to find the index and copy/paste the URL... just too much work for non interesting information. Most Wikidata editors seem to agree with me, as document file on Wikimedia Commons (P996) seems to be used ten times as much (227 296) as P1957 (23 918).
Considering: there is a one-to-one correspondance between the document file on Wikimedia Commons (P996) and the Index name, and even in the case of multilingual books, each index in each language's Wikisource can be identified accurately via the sitelink, I think that's enough. Ignacio Rodríguez (talk) 12:51, 17 January 2025 (UTC)
- @Ignacio Rodríguez:, the reason to include Wikisource index page URL (P1957) instead of document file on Wikimedia Commons (P996) is because not all book editions have corresponding Wikimedia Commons file, some are uploaded locally on Wikisource projects instead of Wikimedia Commons based on local uploading policy. So, those items have Wikisource index page URL (P1957) but not document file on Wikimedia Commons (P996) property. -- Bodhisattwa (talk) 16:06, 17 January 2025 (UTC)
- I understand the reason, but I would still like that you consider the implications. Because of a true minority of works (not all projects have exceptions to Commons uploading policy, and even in those who do have it, only a handful of works are uploaded locally) you are leaving 90% of works that don't use P1957. Ignacio Rodríguez (talk) 21:58, 17 January 2025 (UTC)
- @Ignacio Rodríguez:, I totally understand what you are saying and I also realize that we might be missing a lot of books which are already there. But even it ideally should be exactly 1:1 correspondence between for P996 and index name, in reality, there are a lot of nuances. There are some Wikisource projects which has used this P996 property even for chapters along with entire books. For example, this is a list of items related to French Wikisource which uses P996 but not P1957; you can easily find out that many of them are just chapters instead of entire books and there is no simple way to filter them out. As we intend to get entire books instead of chapters for the app, this kind of modeling becomes problematic for the app and that's why we went for P1957 which is more suitable for entire books. If your language community has exact 1:1 correspondence as you said, I would humbly suggest to include P1957 into the items, which would be relatively easier to do for the sake of the uniformity of the workflow. -- Bodhisattwa (talk) 03:21, 18 January 2025 (UTC)
- @Bodhisattwa That's a whole different issue, but still I don't see the connection between and edition having P1957 and being a top level work. Nothing in the property description or logic restrict us to add it to chapters as well. It seems in French Wikisource they only (?) add it to top level and not chapters, but it's not necessarily the case. I can setup a bot that automatically adds the index URL to Wikidata on Spanish Wikisource items, but not all communities will have that capability. I would humbly suggest that if it is really needed and somehow the only way to differentiate, we come up with a global bot or another solution. Even in large communities such as the English Wikisource, we are missing 6199 works (most of them top level, not chapters) so we can include 1129. Ignacio Rodríguez (talk) 11:55, 18 January 2025 (UTC)
- @Ignacio Rodríguez:, I honestly want all completed books come to the app. Its never my intention to exclude anything behind. But, we had no other option to follow a common query for all languages. Every language community follows a different way to model their books and chapters and we had to find a common ground which would accommodate all of them. For example, from your above query for English, we have 4890 biographical articles (like chapter entries) within the 6199 items, thats around 80%. I am always ok to add the missing P1957 for any communities, if that is a issue for them and include as many completed books as possible. Its a continuous process to include books into the app and the app will update daily, so even if some books are absent today can be visible tomorrow. -- Bodhisattwa (talk) 15:08, 18 January 2025 (UTC)
- So, 1309 missing to include 1129. It's still missing most works. In your last query you used instance of (P31) with biographical article (Q19389637) to differentiate between biographical articles and editions... why don't we use that same property? According to the FRBR model, every edition should have instance of (P31) with version, edition or translation (Q3331189) or one of its subclasses. Ignacio Rodríguez (talk) 19:37, 18 January 2025 (UTC)
- We could not use instance of (P31) with version, edition or translation (Q3331189) because it is being used for individual poems, chapters, etc. published in a book, we hence required P1957 to differentiate. Also, there are some items, which have erroneously used instance of (P31) with literary work (Q7725634) for Wikisource editions like A Specimen of the Botany of New Holland (Q4659751), which needs fixing. Anyway, yesterday, I had added P1957 to almost 600 English books, which are now included in the app. -- Bodhisattwa (talk) 16:01, 19 January 2025 (UTC)
- So, 1309 missing to include 1129. It's still missing most works. In your last query you used instance of (P31) with biographical article (Q19389637) to differentiate between biographical articles and editions... why don't we use that same property? According to the FRBR model, every edition should have instance of (P31) with version, edition or translation (Q3331189) or one of its subclasses. Ignacio Rodríguez (talk) 19:37, 18 January 2025 (UTC)
- @Ignacio Rodríguez:, I honestly want all completed books come to the app. Its never my intention to exclude anything behind. But, we had no other option to follow a common query for all languages. Every language community follows a different way to model their books and chapters and we had to find a common ground which would accommodate all of them. For example, from your above query for English, we have 4890 biographical articles (like chapter entries) within the 6199 items, thats around 80%. I am always ok to add the missing P1957 for any communities, if that is a issue for them and include as many completed books as possible. Its a continuous process to include books into the app and the app will update daily, so even if some books are absent today can be visible tomorrow. -- Bodhisattwa (talk) 15:08, 18 January 2025 (UTC)
- @Bodhisattwa That's a whole different issue, but still I don't see the connection between and edition having P1957 and being a top level work. Nothing in the property description or logic restrict us to add it to chapters as well. It seems in French Wikisource they only (?) add it to top level and not chapters, but it's not necessarily the case. I can setup a bot that automatically adds the index URL to Wikidata on Spanish Wikisource items, but not all communities will have that capability. I would humbly suggest that if it is really needed and somehow the only way to differentiate, we come up with a global bot or another solution. Even in large communities such as the English Wikisource, we are missing 6199 works (most of them top level, not chapters) so we can include 1129. Ignacio Rodríguez (talk) 11:55, 18 January 2025 (UTC)
- @Ignacio Rodríguez:, I totally understand what you are saying and I also realize that we might be missing a lot of books which are already there. But even it ideally should be exactly 1:1 correspondence between for P996 and index name, in reality, there are a lot of nuances. There are some Wikisource projects which has used this P996 property even for chapters along with entire books. For example, this is a list of items related to French Wikisource which uses P996 but not P1957; you can easily find out that many of them are just chapters instead of entire books and there is no simple way to filter them out. As we intend to get entire books instead of chapters for the app, this kind of modeling becomes problematic for the app and that's why we went for P1957 which is more suitable for entire books. If your language community has exact 1:1 correspondence as you said, I would humbly suggest to include P1957 into the items, which would be relatively easier to do for the sake of the uniformity of the workflow. -- Bodhisattwa (talk) 03:21, 18 January 2025 (UTC)
- I understand the reason, but I would still like that you consider the implications. Because of a true minority of works (not all projects have exceptions to Commons uploading policy, and even in those who do have it, only a handful of works are uploaded locally) you are leaving 90% of works that don't use P1957. Ignacio Rodríguez (talk) 21:58, 17 January 2025 (UTC)
Mandatory label in native language
[edit]Native-language labels should not be required; Wikidata is moving to using mul language labels (and aliases) where practical. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 19 January 2025 (UTC)
- Doesn't "native-language labels" mean the "native label" property? That allows mul. — Alien 3
3 3 17:41, 21 January 2025 (UTC)- How is "label in native language", the first item in the list, different from the second item on the list, "title in native language"? Note also the table, captioned "Data that can be fetched from the metadata API", which lists both "title" ("Title in English") and "title_native_language" ("Title in the native language" as sourced from "Wikidata label". And that "mul" is not mentioned anywhere on the page. More clarity is needed, all around. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:28, 21 January 2025 (UTC)
- Here's the code that actually does the query. From it, I think that:
- it actually does not use properties "native label" (or "title" for that matter)
title_native_language(in the API response) is the label in the language this function was called with (for now one of ['en', 'bn', 'hi', 'fr', 'te']. Ought to work just the same for mul possibly later, as s:mul: links to oldwikisource.)title(in the API response) is the label in english- it actually does not use separate titles and labels, as far as I can see
- Documentation probably needs an overhaul, indeed. — Alien 3
3 3 20:45, 21 January 2025 (UTC)- "s:mul: links to oldwikisource" - I'm not sure I understand you correctly; but an item with a "mul" label of "Foobar" in Wikidata might have links in any one or more Wikisource projects, whose titles in that project may or may not be "Foobar". That item may or may not have labels in the individual languages also; and they may or may not be "Foobar". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:24, 21 January 2025 (UTC)
- Here's the code that actually does the query. From it, I think that:
- @Pigsonthewing and Alien333:, we are removing native language labels as mandatory criteria. During the next release, the app will look for title title (P1476) in native language. If it is not there, it will look for label in native language and if it is not there, it will look for label in
mul. -- Bodhisattwa (talk) 13:03, 23 January 2025 (UTC)
- How is "label in native language", the first item in the list, different from the second item on the list, "title in native language"? Note also the table, captioned "Data that can be fetched from the metadata API", which lists both "title" ("Title in English") and "title_native_language" ("Title in the native language" as sourced from "Wikidata label". And that "mul" is not mentioned anywhere on the page. More clarity is needed, all around. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:28, 21 January 2025 (UTC)