Wikidata:Property proposal/Sister projects


Property proposal: Generic Authority control Person Organization
Creative work Place Sports Sister projects
Transportation Natural science Lexeme Wikimedia Commons


See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.

  On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2021/03.

WikipediaEdit

Wikipedia infobox fieldEdit

   Under discussion
Descriptionname of a field in the infobox of the Wikipedia in the same language, e.g. use English for a field on English Wikipedia.
Data typeMonolingual text
Domaingenerally Wikimedia infobox template (Q19887878), maybe some other Wikimedia template (Q11266439)
Example 1Template:Infobox film (Q6171351) → "film name"@en
Example 2Template:Infobox film (Q6171351) → "director"@en
Example 3Template:Infobox film (Q6171351) → "producer"@en
Example 4Template:Infobox film (Q6171351) → "attori"@it
Example 5Template:Infobox film (Q6171351) → "truccatore"@it
Example 6Template:Infobox film (Q6171351) → "cortometraggio"@it
Planned use


MotivationEdit

Following a similar suggestion by @ElanHR: on project chat and describing_templates_and_their_fields. Allows to query infobox fields and map to properties. If there is interest, a similar property could be created for other projects (Add your motivation for this property here.) --- Jura 10:57, 29 January 2020 (UTC)

DiscussionEdit

  •   Weak support I think the datatype should be "string" instead of "monolingual text". The parameter identifier actually doesn't have to match any language, and could be any alphabetical sequence. --Tinker Bell 02:35, 2 February 2020 (UTC)   Oppose per VIGNERON: this should be discussed. --Tinker Bell 02:22, 17 September 2020 (UTC)
    • The idea is that the language matches the Wikipedia's. Otherwise, there is no way of knowing which WP this relates to. --- Jura 07:57, 3 February 2020 (UTC)
      • Then oppose as we have no language code for 'simple', for the various Wikisources, nor Wiktionaries, for Wikispecies, for Commons, nor, indeed, for Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:59, 8 February 2020 (UTC)
        • @Pigsonthewing: My understanding is that this property's scope is limited to Wikipedia (Wiktionaries, Wikispecies, etc. would use an equivalent property) and therefore the only ambiguity is between English Wikipedia and Simple Wikipedia. Fortunately (in my experience) templates from SimpleWiki tend to mirror those from EnWiki (e.g. Infobox:Person(en) and Infobox:Person(en)). Additionally I would not be too worried about this ambiguity as a problem only arise if one site used the same infobox key as another site but used it to represent different semantics. I have yet to see this case and I would imagine it occurs extremely infrequently. ElanHR (talk) 03:42, 21 February 2020 (UTC)
          • "Wiktionaries, Wikispecies, etc. would use an equivalent property" That I also oppose. And it does not address the case of simple.Wikipedia. Your supposition about the mirroring of parameter names between that project and en.Wikipedia is overly optimistic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 21 February 2020 (UTC)
  •   Comment I've been thinking about something similar, but I'm not sure this will work. Users will probably try to translate the entries, and not check what they actually are, users will not keep the entries updated, and the entries will diverge from actual entries in the templates. To keep the entries synchronized there must be some technical measure to do so, for example through TemplateData. A property should not be for an infobox, but for a template. That would also make it simpler to implement as part of the TD extension. Jeblad (talk) 15:58, 8 February 2020 (UTC)
    • When doing Wikidata:WikiProject Movies/Tools#Wikipedia infobox mapping, I was worried about that too, but finally they proved quite stable. I think they are still used to do imports from Wikipedia. Obviously, depending on the use, some additional checks and re-sync needs to be done. I think the maintainers of TemplateData had declined to host a field for corresponding properties. --- Jura 16:13, 8 February 2020 (UTC)
      • It is the same problem as maintaining sitelinks, they slowly disintegrate unless there are some way to automate the maintenance. (I wrote the original code for creating sitelinks, and the problem you try to solve is virtually the same.) Jeblad (talk) 16:54, 8 February 2020 (UTC)
        • I think the granularity of the information, impact of changes, purpose and update pattern(s) are very different when compared to sitelinks. --- Jura 17:02, 8 February 2020 (UTC)
        • @Jeblad: with TemplateData#API, we could check if the field list is current. Shall we move ahead with this proposal? --- Jura 10:59, 11 February 2020 (UTC)
          • I believe this belongs in the server, not in the browser, and if you would put it in the browser, then you must enforce it in all clients. You would probably not be able to enforce use of it in the clients anyhow. Thatis in all language editions of Wikipedia. Jeblad (talk) 13:26, 12 February 2020 (UTC)
            • @Jeblad: I think it depends on the purpose. To replace pages like the one of WikiProject Movies, it can easily live here. If a client wiki actually links an infobox to Wikidata, definitions could be moved there or more easily synced. As it hasn't happened in the last (decade), it might not happen soon though. --- Jura 17:07, 12 February 2020 (UTC)
              • Sorry, but I'm pretty sure this will not work. Jeblad (talk) 21:23, 12 February 2020 (UTC)
            • @Jeblad: Np. I know it works for the movies project. --- Jura 21:26, 12 February 2020 (UTC)
              • We can't even get the communities to maintain TemplateData, which has a clear local effect, how should we enforce maintenance of an off-site value that has nearly no local effect? I don't see how that will happen. Jeblad (talk) 21:34, 12 February 2020 (UTC)
                • Users regularly import data based on fields also listed on WikiProject Movies. Contrary to sitelinks, there is no point in adding all fields/all infoboxes if nothing is done with it here. --- Jura 21:41, 12 February 2020 (UTC)
  •   Weak support. Not only infoboxes need mapping between parameter names. Many other templates (and modules) need it, too. I have a vague recollection that Pigsonthewing tried to propose something similar once, although I might be wrong. The proper solution for this problem is Global templates. In the proposal I've written, I intentionally didn't specify how exactly will this be stored: maybe some kind of global TemplateData, maybe a different JSON structure, maybe something in Wikibase, and maybe something entirely different. However, this proposal here can be a step towards proper global templates. --Amir E. Aharoni {{🌎🌍🌏}} talk 18:20, 8 February 2020 (UTC)
  •   Support--Dispe (talk) 12:51, 1 May 2020 (UTC)
  •   Wait as, in the current state, this proposal need some serious rethinking and reworking. Why only infoboxes? why store this information in Wikidata? Not convinced at all so leaning to   Oppose for now. Cheers, VIGNERON (talk) 11:18, 11 May 2020 (UTC)
    Yes, this need's to be property for any template parameters! Carn (talk) 11:45, 20 November 2020 (UTC)
    • @Carn: could you provide a couple of usecases for non-infobox templates? If not, would you consider supporting the proposal in its present form? As mentioned below, we might add these later, but they might not have interesting fields to map. --- Jura 10:56, 21 November 2020 (UTC)
      en:Template:Cite web "title" = es:Plantilla:Cita web "título"
      fr:Modèle:Références "groupe" = ru:Шаблон:Примечания "group" Carn (talk) 15:04, 4 December 2020 (UTC)
      • @Carn: Indeed, I suppose this type of template could be added as well with the proposed property, even with the current label. I wonder what happened with the WMF development that was planning to integrate Wikipedia citation templates directly with Wikidata. --- Jura 12:47, 5 December 2020 (UTC)
  •   Comment seems we addressed most concerns. Oddly we still don't have an alternative. --- Jura 06:23, 30 August 2020 (UTC)
  •   Strong oppose No code for "simple", no way to map correctly every parameter for every infobox (e.g. "language" could be in some cases language of work or name (P407) or programming language (P277)) because many templates use "simple" words as parameter because there is a unique meaning in the context. You cannot generalize that for every templates in every language. I suggest you to wait and to find another possible way as this is an important and useful task --★ → Airon 90 16:21, 3 September 2020 (UTC)
    • @Airon90: Simple wiki would need a separate property if there is interest (frequently it's similar to enwiki though). The plan isn't to map every template in every language, but specific infoboxes linked from a given item, according to the field_names used there. Infoboxes can only have the same field_name once. The idea is to make it easier to gather fields that need to be mapped to Wikidata. --- Jura 16:33, 3 September 2020 (UTC)
(1) if there is no interest for simplewiki, there wont be a separate property. Besides, I don't really see the advantage of a single property when it leads to having to add a qualifier to every statement instead (twice as many triples).
(2) I added "predecessore"@it as samples. They can then be analyzed separately for each template. However, "predecessore" (and "successore") are probably the least interesting infobox fields, as they are fairly generic. The samples of Template:Infobox film (Q6171351) above are much more crucial, as it's unique to the infobox and it's the type of information that is useful to gather (I think) and map. @Airon90: --- Jura 17:23, 3 September 2020 (UTC)
  1. Please, explain why you don't see advantage(s) in using just one property instead of many. Contributors may not find some properties directly or may use the "main" one in a wrong way, causing errors or lack of information
  1. «They can then be analyzed separately for each template» how? You consider some simple cases, where the name of the parameter links directly to the property. This work will be useful if *every* parameter is correctly analyzed without struggling in finding the correct property. Moreover, some template *may* be implemented on Wikipedia using a wrong property (e.g. in some cases, values of P155 should be moved to P1365 and/or viceversa). On Wikidata you link a parameter to a property while on Wikipedia the value of that parameter is automatically scraped from another property.
I think that this work is necessary and useful but this isn't the correct way to implement this work. --★ → Airon 90 19:39, 3 September 2020 (UTC)
@Airon90: (1) It's clear that some contributors never find the correct property. The question here is not between one and many, but one and possibly a few others (but I haven't seen anybody interested yet). As said, it's easier to just use a property and a value than a property and value and a qualifier for each field. (2) The idea here is not to redo infoboxes of Wikipedia, the idea is merely to analyze its contents. Mappings can change and may need updating, but that shouldn't prevent one from doing mappings. This isn't much different from any other property (e.g. Wikidata:Property_proposal/booking_URL). Do you have any constructive suggestions for alternatives? (besides the one by ElanHR discussed earlier). --- Jura 19:52, 3 September 2020 (UTC)
@Airon90: does this answer your concerns? --- Jura 06:57, 19 September 2020 (UTC)
We would not map all of them, but we need and we can map the most important. Carn (talk) 11:46, 20 November 2020 (UTC)
  • @Tinker Bell: can you clarify what aspects you think need to be discussed? The discussion is still open. I think the primary focus should be infobox templates as there have fields that could potentially be properties. I don't think the applies to (for example) navigational templates. These would just have 1= or 2=. Obviously, if there are others we find useful, we could add them later. Which ones did you have in mind? --- Jura 06:32, 19 September 2020 (UTC)
    • This proposal is constrained to Wikipedia subprojects, but other non-Wikipedia projects also have infoboxes, like Wikisource. That's why we can't use monolingual string datatype for this property. I also think that having the same property repeated many times, one for each Wikimedia project is a nonsense.
    • I would like having a way to document templates of any kind on Wikidata, and on that direction, I think the ElanHR's proposal you have linked is a good start. It has some problems too, but we could discuss them. --Tinker Bell 09:06, 22 September 2020 (UTC)
supported metadata (P8203)
  honorific (Q1326966)
<LOCALE_SPECIFIC_KEY> honorific_prefix (en)
honorífico (es)
0 references
add reference
  name (Q82799)
<LOCALE_SPECIFIC_KEY> native_name (en)
nombre_nativo (es)
0 references
add reference
  position (Q4164871)
<LOCALE_SPECIFIC_KEY> office (en)
oficina (es)
0 references
add reference
  position (Q4164871)
applies to part (P518) start time (Q24575110)
<LOCALE_SPECIFIC_KEY> term_start (en)
período_inicio (es)
0 references
add reference


add value
  •   Comment added another planned use. --- Jura 06:59, 19 September 2020 (UTC)
  •   Comment @Tinker Bell: thanks for your detailed feedback. I like the idea of using supported metadata (P8203) for this. While eventually we would create properties (if they are missing), this would allow to described them before they are created. Once available, merely adding P1687 will do. I think it's an improvement over using a property-datatype property. I hand't thought of that.
    Given that many qualifiers are hard to handle on a single statement, I'd rather make P8203 a qualifier for the proposed property. What do you think? --- Jura 08:46, 5 October 2020 (UTC)
    • @Jura1: I think 'supported metadata' describes an aspect of the template, not of a parameter, so the principal property should be P8203. --Tinker Bell 06:33, 15 October 2020 (UTC)
      • @Tinker Bell: I suppose there are two ways of seeing it. If "supported metadata" is the main property, it needs a restrictive qualifier. If "infobox field" is the main property, it can do with a non-restrictive qualifier: that means that the field if present, always supports the metadata. My POV is that non-restrictive qualifiers are generally preferred.
        The approach with using this as qualifier could lead to many qualifiers on the same value. I don't see that working on other properties. Do you? --- Jura 05:24, 16 October 2020 (UTC)
        • @Jura1: I think using "infobox field" as main property could make difficult modelling qualifiers, e.g. <item> supported metadata (P8203) position (Q4164871) / applies to part (P518) start time (Q24575110): we can't do <item> <LOCALE_SPECIFIC_KEY> "term_start"@en / supported metadata (P8203) position (Q4164871) / applies to part (P518) start time (Q24575110) because P518 will lose its meaning here. I also think that a <LOCALE_SPECIFIC_KEY> property without a P8204 qualifier is as useless as a P8204 property without a <LOCALE_SPECIFIC_KEY> qualifier. --Tinker Bell 08:20, 23 October 2020 (UTC)
          I do not know what you are talking about, but this property should be TemplateData compatible (with aliases, data type: number/text, etc). Templates are already an items, then it's parametres could be listed either as properties of this item with some qualifiers, either (for popular parametres like "title" in cite templates which can be standartized through different languages wikis) as links to another items maybe? Carn (talk) 17:15, 4 December 2020 (UTC)
      • @Tinker Bell: Admittedly, this is a somewhat weak point of the approach, possibly of any approach. It's clear that it's hard to map the full details of the statement. The question is if it's really worth doing it to find that there is a start and end date for the position. If it's thought to be desirable, I suppose one could either create an item <start date of position> and use that as P8203 value or qualify <start date> in some way to indicate it applies to the position. Even in the sample you gave above, I think using <position> as metadata available for "term_start" isn't really optimal either. In any case, I think we are probably mostly interested in getting all infoboxes that have metadata about positions (whatever the level of detail). --- Jura 09:11, 31 October 2020 (UTC)
      • @Tinker Bell: would you consider support the proposal in its present form? --- Jura 10:56, 21 November 2020 (UTC)
        • @Jura1: Yes, I'll   Support it. --Tinker Bell 23:53, 21 November 2020 (UTC)
        • I don't know the perfect way to do it yet. I would consider storing table data on commons. @Tinker Bell proposal is that each big template will have many supported metadata (P8203) properties. And we see links for concepts, that are stored in these parameters on the pages of wikis. I see the good use for this for templates translation. So in order to translate some parameters, we will need to get all the list of all parameters of this template in this language, then find ones in this many lists of parameter names we need to translate and substitute names from other languages if described. I imagine how it is possible to set by the bot from the template code (or module code) to find whether all parameter names are described in template data, or not). In fact, if some kind of solution for centralized storage of template data is supposed — this will duplicate them.

          This raises the question of what is the subject of the corresponding item in general. If a template performs the same functions as other templates but has completely different, incompatible parameters — is this a different template? Perhaps the parameters can be a measure of the similarity of templates, and if different templates have very different parameters, then they are not the same entity at all. Carn (talk) 09:49, 6 December 2020 (UTC)
          • initially I was going to write about your suggestion for the inclusion of citation templates, that this may not be needed as WMF staff is already implementing a solution for these, but, after checking, it seems that the steps taken in 2019 didn't lead to a running solution (yet), so, if you are interested in checking these, why not. The citation thing might also have been on a wishlist some years back, but we still have to work with currently available tools and features. I agree with the point you made earlier: it's better to focus on some templates than try to map all of them. Once the data is struructured here, it can be reused and/or converted further. --- Jura 17:03, 6 December 2020 (UTC)

WiktionaryEdit

WikiquoteEdit

WikisourceEdit

Wikisource indexEdit

Wikisource index pageEdit

   Under discussion
Descriptionitem for page in Wikisource containing digital and paper pagination of the source
RepresentsHelp:Index pages (Q15628590)
Data typeItem
Example 1Use here on Wikidata: The Kiss and Other Stories by Anton Tchekhoff (Q15839163)Index:The Kiss and Other Stories by Anton Tchekhoff, 1908.pdf (Q89675998)
Example 2Use at Wikimedia Commons: File:The Kiss and Other Stories by Anton Tchekhoff, 1908.pdfIndex:The Kiss and Other Stories by Anton Tchekhoff, 1908.pdf (Q89675998)
Example 3MISSING
See alsoWikisource index page (P1957)

Wikisource pagination stringEdit

   Under discussion
Descriptionpagination of a file in the pagelist format used by Wikisource index pages. See property talk page for formatting details.
RepresentsHelp:Index pages (Q15628590)
Data typeString
Allowed valuessee s:Help:Index_pages#pagelist
Example 1Index:The Kiss and Other Stories by Anton Tchekhoff, 1908.pdf (Q89675998)<pagelist 1to5=- 6=1 37=33 58=55 69=67 70=69 80=81 107=109 120=123 133=137 172=177 181=187 188=195 189=197 212=221 221=231 222=233 233=245 252=265 253=267 />
Example 2MISSING
Example 3MISSING
See alsofile page (P7668), title page number (P4714)

MotivationEdit

This was initially done with URL datatype (P1957), but, as for other sitelinks to sister sites, using actually item datatype seems preferable. I don't think these pages are currently linked from Wikidata. Accordingly, we don't really now if P1957 values are complete/how incomplete they are. Eventually P1957 could be replaced by this. Except for the pagination, I think all other information is included in Wikidata. Please help complete the proposal. (Add your motivation for this property here.) --- Jura 15:06, 7 April 2020 (UTC)

BTW, this could also be used on Commons (see 2nd sample above). --- Jura 17:13, 7 April 2020 (UTC)


@Mike Peel, Beleg Tâl, Samwilson: --- Jura 15:06, 7 April 2020 (UTC)

DiscussionEdit

  • I don't think it is a really correct way to do so, given there's an one to one mapping of index pages and files.--GZWDer (talk) 17:00, 7 April 2020 (UTC)
    • What is the "correct way" according to you? --- Jura 17:13, 7 April 2020 (UTC)
  • If the Index page property was of type Item, we'd have to create separate items for each Index page, but Wikisource index page (P1957) is already meant to be used on items describing editions. I don't know there's much to be gained from having to have separate items for e.g. each volume in a multi-volume edition, let alone a separate item for every single edition (there's already enough confusion with creating edition and work items). My understanding is that Wikisource index page (P1957) is of type URL because there is no other type that's suitable. Really, it'd be good to have something like Commons media but for any wiki; that's a whole other thing though, and it's not possible at the moment. —Sam Wilson 00:23, 8 April 2020 (UTC)
    • I don't really have a good explanation for why P1957 is using URL datatype, but it seems to date back to the time when Wikisource was just rolled out and it wasn't clear how sitelinks were done in general. We gradually started changing properties for Commons from odd datatypes to the usual item ones. I don't really see a potential for confusing items like Index:The Kiss and Other Stories by Anton Tchekhoff, 1908.pdf (Q89675998) with others (note the "Index:" prefix), at least if we define them adequately. --- Jura 06:11, 8 April 2020 (UTC)
      • @Jura1: I don't think we should have sitelinks to Index pages. That would mean we'd have to have separate items for every Index page. The reason Wikisource index page (P1957) is of type URL is that there's no general 'wiki page' data type (only the special purpose Commons media type one, which is why Commons properties get special treatment). —Sam Wilson 23:09, 8 April 2020 (UTC)
        • It's actually an advantage to have items for index pages. It would allow to determine for which editions ones we currently lack links (compare e.g. only s:Category:Index Validated has 3500 pages, with 2900 uses of Wikisource index page (P1957)). Clearly there is a lot of content at Wikisource that isn't discoverable from Wikidata. BTW we also started changing the property for Commons to item properties (e.g. Property:P3722 was replaced by Property:P7867 recently). @Mike Peel: what are your thoughts on this? --- Jura 09:08, 9 April 2020 (UTC)
        • While the new property involves some work (I'd be doing), I don't really see any downside for existing users of the current property. Are there some uses that wouldn't be possible? --- Jura 09:08, 9 April 2020 (UTC)
          • @Jura1: I'm somewhat neutral here. On one hand, sitelinks and links between QIDs are way better than strings for keeping track of interwiki links, on the other hand you would have to create a lot of new items and I'm not sure they would have many other links. I think the case for sitelinks would become a lot stronger if Wikidata information was being used on the pages being sitelinked to - then the information can easily be accessed without messing around with QIDs locally. This is what I consider the key use case to be for Commons and why I wanted the new category for maps (P7867) (each one of those items is used to display an infobox in the sitelinked Commons categories). I'm not sure what the current Wikidata situation is on Wikisource, @Billinghurst: would know more. Thanks. Mike Peel (talk) 09:26, 9 April 2020 (UTC)
            • @Mike Peel: Thanks for your feedback. I think the Russian Wikisource is fairly well integrated with Wikidata. Information there can be found through Wikidata (with items for Wikisource articles and "described by" statements). Its community seems to be fairly proficient in Wikidata tools. A lot of work is also being done for French Wikisource. I don't think this is necessarily the case for other languages, e.g. poems by Emily Dickinson were mostly malformed entries. So some of the wealth of information on Wikisource is lost to the wider Wikimedia community. I'm trying to support the integration of an encyclopedia with more than 25,000 entries. I'm not sure how much use the Russian or French Wikisource editions make of Wikidata. Maybe storage of some of the metadata. It might also be helpful for some checks. In general, the advantage for them is probably rather the accessibility of the items about the sources through queries. --- Jura 09:52, 9 April 2020 (UTC)
  • For the Wikisource pagination string proposal: I think this has merit, but this data belongs in Commons where the scans are kept. The items here are for editions, and do not correspond to particular scans of particular books. I'm not familiar yet with the process of proposing a new property for Commons; is this that process? If so, then great. —Sam Wilson 00:23, 8 April 2020 (UTC)
    • It would need to be proposed here as well, but they seem to be reluctant to support string properties on Commons. So the only option seems to be to host this here. The main property can link the item here from Commons (see 2nd sample above). --- Jura 06:11, 8 April 2020 (UTC)

  Comment Wikisource Index: pages are not content pages at the WSes, they are simply constructs/carriers to manage a transclusion and they link a file to a transclusion providing page numbers on the way, so they have no particular importance outside of the WS. The thing about Index: and File: pages are they may not be complete edition, so for a work at a Wikisource there may be multiple Index: or you may find that an Index:/File: contains multiple works, depending on the scanner [So an edition may have multiple Index:, or an Index may have editions of multiple works]. To also note that an Index: / File: may not be unique to just one WS, where a WS allows for the Index: / Page: nss to be able to be utilised for a crowd-sourced translation of the published work you could find the same file used at two places, and have two connected Index:.

I don't think that Wikisource index page (P1957) is used much, and I haven't particularly used it for a while. [If a field isn't in WEF framework tool for "FRBR Edition", I don't add it.] Please don't make it harder, or more work for the WSers, especially without the deliver of a greater benefit. There is already need for better tools to make the additions, and there has been little effort to undertake that, so we are stuck with brute force edits. We still cannot make easy good WORKS from ITEMS, and ITEMS from WORKS. You cannot easily load a work to Commons, and get the resulting componentry elsewhere without a lot of work. [My epistles on this three way linking of editions to Commons/WS/WD, then linking to works for WP are around. Now the suggestion is for another item for the Index:. I hope that one day the thinking will focus on giving better tools to WSes and that will give better data and compliance.] At this time there are just too many hurdles in getting good data from WSes into WD.  — billinghurst sDrewth 10:33, 9 April 2020 (UTC)

  • It might be easier to automated it with this proposal. I will make a detailed suggestion on Wikidata:Bot requests once this is created. --- Jura 18:09, 12 April 2020 (UTC)

  Comment I am not seeing the point of the proposal and what it achieves. The data in the Property Proposal is locally created, and should be considered as dynamic, rather than static, and pagination and numerous means of presentation, so why would you inhale the <pagelist> data and how would you continually check it for accuracy? The Index namespace at the Wikisources is our work zone, not a content namespace, and only truly has relevance to a WS working edition, not to anything external to wikimedia wikis. I just see a time pit; not a proposal of clear value to Wikisource.  — billinghurst sDrewth 00:38, 13 April 2020 (UTC)

  • It all depends on your needs. It could simplify creating the edition items you mention. If the index page is complete, it could include the equivalent information included. I'd assume it remains static once the work is proofread and validated. I can understand that, for Wikisource contributors who have the index page, there is no need for any item(s) at Wikidata as the Index page already holds all information. However, users of Commons/Wikidata can't access that information easily nor know it's there. --- Jura 11:38, 13 April 2020 (UTC)
I am also kind of   Neutral. I agree with billinghurst that index page is something relevant wot Wikisource and not that relevant to anybody else. I do not understand how we would use it. I do think we should link to index page, but I would rather skip the step of creating wikidata item for it and just store URLs, as I can not imagine what other metadata we would add to that item. --Jarekt (talk) 16:02, 21 July 2020 (UTC)
@Jarekt: I think the pagination of the PDF is important (the main feature of these pages IMO). This is true independently of a transcription at Wikisource.
There are obviously several ways to store the pagniation. I don't think having it at an unconnected Wikisource page is one of them. --- Jura 16:21, 21 July 2020 (UTC)
I agree that it is important, but we do need some idea about how to use it before we decide what we need to store and how. I would not want to be donating my time curating metadata nobody will ever use, and I think others might feel the same. If we do come up with some realistic use-cases for it than I agree that we should store it. --Jarekt (talk) 17:10, 21 July 2020 (UTC)
@Jon Harald Søby, Tpt: I found you through https://fr.wikisource.org/wiki/Discussion_MediaWiki:Proofreadpage_index_template . Is it possible to display the pagination on file description pages if we add a statement on Commons? I couldn't really figure ou from the French module ( https://fr.wikisource.org/wiki/Module:Index_template ) how it does that. Obviously, the interested would be for the many files on Commons without any Wikisource using them. --- Jura 17:29, 21 July 2020 (UTC)
  Comment @Jarekt, Jura1: Note about pagination. It is part of the summer coding project and new pagination processes are coming through. I will also note that the pagination style is very arbitary and changing, so having it statically recorded in WD is the wrong way to go about it. Just like our transcriptions can update through time, so can our jottings on page numbering, and I certainly do not want another task of transferring that data when it would be better stored in a json file on the WS as part of the Index  – The preceding unsigned comment was added by [[User:|?]] ([[User talk:|talk]] • contribs).
  • I’d like to see bilingual texts mentioned here (e.g. Q72743941):
    – Switching to an item for the index might help navigation between index pages once setup (assuming the two indexes be sitelinks of the same items, not sure the two indexes can be considered the same concept, though?).
    – What would pagination be if shared by two index pages? Q72743941 is maybe not the best example here, because the polish version could be used as a common one: What about unshareable conventions, like pages named “Titre” (= “Title”), “illust”, “tdm” (= “toc”), etc. on the French Wikisource? (or would pagination-on-Wikidata be a third version completely independent from Wikisource?)
    Jura1, could you clarify what you expect here?
    — Ltrlg (talk), 15:28, 13 September 2020 (UTC)
    • @Ltrlg: if it couldn't be shared, I suppose one would have two add to statements with the property to differentiate the two. Oddly I'm more concerned about the many Commons files that wont ever get an index page on Wikisource. --- Jura 15:19, 22 September 2020 (UTC)
  •   Support, an important property for Wikisource.--Arbnos (talk) 17:05, 19 February 2021 (UTC)

WikivoyageEdit

WikinewsEdit

WikiversityEdit

WikibooksEdit

WikispeciesEdit

See Wikidata:WikiProject Taxonomy; Wikidata:Wikispecies; wikispecies:Wikispecies:Project Wikidata

Wikimedia IncubatorEdit

Wikimedia CommonsEdit

See Wikidata:Property proposal/Commons

GeneralEdit