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 2020/06.

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
Planned useadd from Wikidata:WikiProject_Movies/Tools#Wikipedia_infobox_mapping

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)
    • 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)

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)

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