Wikidata:Requests for comment/Create items for property proposals

From Wikidata
Jump to navigation Jump to search
An editor has requested the community to provide input on "Create items for property proposals" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!

The ready property proposal backlog has become increasingly long (6 ready proposals). Property creators like me don't want to take the extensive time (8+ minutes) it requires to make a property.

This proposal proposes using Items for property proposals so that proposals, and properties when they are ready, can be easily created from them.

How it works[edit]

Proposing[edit]

  1. User creates a proposal by copying a proposal template item that has:
    1. Label, description, aliases as the property name, description, and aliases
    2. instance of (P31)Wikidata property proposal (Q114746893)
    3. Proposed property data type expressed using new property we will create called "proposed property data type"
    4. Domain, range, allowed entity types, and allowed units expressed with property constraint (P2302)s
    5. Category of property proposal expressed using main subject (P921) with values that are currently used for categorizing proposals:
      1. General (don't add main subject)
      2. authority file (Q36524)
      3. human (Q5)
      4. organization (Q43229)
      5. sport (Q349)
      6. creative work (Q17537576)
      7. place (Q98929991)
      8. sibling project (Q115096159)
      9. transport (Q7590)
      10. natural science (Q7991)
      11. lexeme (Q111352)
    6. Property examples expressed with Wikidata property example (P1855). Because the property hasn't been created yet, they will use a new qualifier we will create called "proposed property example value" that will document the value of the proposed property on an item.
  2. User adds other optional statements the resulting property should have such as related property (P1659) or on focus list of Wikimedia project (P5008)
  3. The copying of the proposal template item will also come with a per-formatted Discussion page.
  4. User adds motivation, planned use, etc. to the Discussion page of the item.

Group proposal[edit]

  1. User creates a proposal item for each of the properties that they are proposing as a group proposal (one discussion for all of the proposals). If the properties are similar, they can speed this up by up by using User:So9q/duplicate item.js to duplicate proposals.
  2. User creates a "group property proposal" item and adds has part(s) (P527) with values of each of the proposals to the group proposal.

Listing of proposal[edit]

Wikidata:Listeria will be used to generate a list of proposals of each category at the Wikidata:Property proposal subpages.

Discussion of proposal[edit]

Discussion will happen on the Discussion page of the property proposal item.

Group proposal[edit]

Discussion will happen only on the Discussion page of the group proposal item. Any discussions that start on the individual property proposal items should be moved to the group proposal Discussion page.

Changing of status[edit]

Property proposal maintainers will add a "property proposal status" statement with values of:

  • not done
  • withdrawn
  • on hold
  • ready
  • done

These items will be created.

Creation[edit]

  1. User will use a modified version of User:So9q/duplicate item.js that will create a property from the proposal item.
  2. The script will add a new property we will create called "property proposal" to the new property that will link it with its proposal item.
  3. The script will change the "property proposal status" value to "done".
  4. The script will change the description of the proposal item to begin with "property proposal for" to distinguish the proposal from its property in search results. It will support changing the description in multiple languages.

Group proposal[edit]

  1. User will use modified version of User:So9q/duplicate item.js which will also support creating all of the properties of a group proposal at once.
  2. The script will add part of (P361) to each of the individual proposals to help users find the group proposal.

Delisting of proposal[edit]

Listeria will only include properties whose "property proposal status" is not "done", "not done", or "withdrawn" so this will be done automatically.

Reuse of a proposal[edit]

If users would like to restart a proposal that was not done or withdrawn, they can do so by:

  1. Duplicating the old proposal with User:So9q/duplicate item.js.
  2. Adding replaces (P1365) to the new proposal item and replaced by (P1366) to the old proposal item
  3. Removing the "property proposal status" statement from the new item.

Benefits[edit]

  • Property proposing is easier because users can just model their proposal off of other properties that already exist and examples are extremely easy to create since you have autofill.
  • Property creation is ~100x faster.
  • Updating the property proposal lists is automatic without requiring a bot.
  • You can query property proposals.
  • Property proposals are going to be explicitely contain more information about the future property because constraints that currently can't be modeled in our property proposal template can easily be added.
  • Constraints can be used to enforce that all required information is filled for property proposals and easily alert users about information that's missing.

Implementation tasks[edit]

To implement this proposal, the following tasks need to be completed.

I, the proposer, can do all of these things. But, if you can help, please express so and which tasks on the Discussion page.

Future tasks[edit]

These are optional tasks that could be done to further improve the process but are not part of this proposal.

  • Make a bot that automatically protects property proposals who are linked to a property that has a "property proposal" property so that they cannot be further edited.
  • Make a script to easily create a proposal item.
  • Make a fork of User:So9q/duplicate item.js that automatically does all of the steps of #Reuse of a proposal with one click.
  • Make items for all proposals previous to this proposal system so that they can be queried for and reused.
  • Make a template that transcludes all the information that's currently available in the property proposal template to the new property proposal talk pages based on the information in the proposal item.

Voting[edit]

If you're okay or not okay with everything in this proposal being implemented (including properties created), please place your  Support or  Oppose below. If you have  Comments, leave them on the Discussion page. If you would like me to change something about the proposal and then you would be in support of it, please let me know on the Discussion page. Lectrician1 (talk) 20:43, 5 November 2022 (UTC)[reply]

 Oppose; we should make use of property creators' expertise to set up propery pages; a mere gatekeeper role would not be necessary —MisterSynergy (talk) 00:00, 6 November 2022 (UTC) my previous comment was moved here by someone else[reply]
Property creation is bad, I'll  Support literally any improvement. -wd-Ryan (Talk/Edits) 21:42, 5 November 2022 (UTC)[reply]
 Support I really like this proposal. Duplicating items is the way to go forward. Large wiki templates are an ugly hack and we can do much better thanks to the tools we have built together. —-So9q (talk) 21:50, 5 November 2022 (UTC)[reply]
 Support agree with So9q - Salgo60 (talk) 22:40, 5 November 2022 (UTC)[reply]
I agree making new properties is a slog. I've only done it a few times because of this. I'm on the fence about this proposal What if we deleted the property proposal item once done with it and kept the discussion on the Wikidata namespace? BrokenSegue (talk) 00:53, 6 November 2022 (UTC)[reply]
@BrokenSegue Why would you delete the item? Then you lose the ability to see the original name of the property, its examples, etc. if the property ever changes. Lectrician1 (talk) 01:46, 6 November 2022 (UTC)[reply]
because I'm not sure these items meet the notability standards of wikidata BrokenSegue (talk) 01:47, 6 November 2022 (UTC)[reply]
Items that are critical to the structure sustainability of Wikidata itself should be allowed as items regardless of notability standards. Items on Wikidata wouldn't even exist without Wikidata and the structure of properties in the first place. In the future, we can move these proposals to a separate entity namespace as I have proposed before as a solution. Lectrician1 (talk) 02:56, 6 November 2022 (UTC)[reply]
These would be extremely structural items, so they pass WD:Notability. -wd-Ryan (Talk/Edits) 03:45, 6 November 2022 (UTC)[reply]
"The items allow us to see the intent of what for the property at the time it was created" seems to me like a pretty straightforward structural need under (3) of our notability policy. ChristianKl ❪✉❫ 13:14, 7 November 2022 (UTC)[reply]
@BrokenSegue I was convinced by the arguments by @Wd-Ryan and @ChristianKl. They would be notable IMO. So9q (talk) 10:15, 11 November 2022 (UTC)[reply]
ok I'm convinced to  Support. anything to make this easier. BrokenSegue (talk) 20:35, 14 November 2022 (UTC)[reply]
 Support This seems like a fine solution. Before we commit to this approach, though, we should make write and test the script to generate a property from the property proposal item. (Perhaps its feasibility is obvious to anybody with experience scripting for WikiData, but it it's not obvious to me.) — The Erinaceous One 🦔 07:57, 6 November 2022 (UTC)[reply]
  •  Support. I agree with So9q too. --Tinker Bell ★ ♥ 03:17, 7 November 2022 (UTC)[reply]
  •  Oppose, I don’t think these items would be notable. Instead, all information should be available in the {{Property proposal}} template, and a script should be written that imports them from there (I think of a mixed Lua/JavaScript solution). —Tacsipacsi (talk) 08:19, 7 November 2022 (UTC)[reply]
    Given that they would be linked from the new property, they would be notable because they fulfill a structural need.
    Currently, we are very far from all information being available in the property proposals. You can't specificy all the constrains we have in the current template and even for those you can specify, it's not obvious to new people how to do so because it requires understanding terms like "domain". ChristianKl ❪✉❫ 13:11, 7 November 2022 (UTC)[reply]
    +1 the current template solutions leaves a lot to desire. With properties on an item we could add better usage examples, etc. So9q (talk) 10:16, 11 November 2022 (UTC)[reply]
    User:Tacsipacsi Please go write that script then if you find it is an easy solution. Lectrician1 (talk) 13:43, 7 November 2022 (UTC)[reply]
  •  Oppose per Tacsipacsi; if I remember correctly, User:DannyS712/PropertyCreator.js was capable of creating a property in a quite complete way on the basis of the template (@DannyS712: for more info). --Epìdosis 11:24, 7 November 2022 (UTC)[reply]
    @Emu @Epì This solution doesn't work for every proposal. Sometimes proposals use {{Statement}}, {{Statement+}}, show multiple values under one item, etc. in the examples section and the script can therefore not process it. You also still have to manually add other statements. The proposed solution outlines the format of the property exactly so it works for any proposal and the property can be created immediately with no further work. Lectrician1 (talk) 13:45, 7 November 2022 (UTC)[reply]
    I don’t think that we should overhaul this process because of some edge cases. --Emu (talk) 14:42, 7 November 2022 (UTC)[reply]
    @Epìdosis @Emu I just tried the script right now to create JioSaavn artist ID (P11168) and it is good. I assumed wrongly how it works. It's a form where you copy-paste details of the proposal.
    It still took me 4:29 to create the property. It also only supports external identifiers.
    This proposal would be able to create properties instantly with any type of proposal supported.
    I would still consider this proposal to be worth the cost of changing of the process. Having proposals being represented as entities should be our end-goal given that they themselves are structured data and are intended to mirror the final property. We don't have a draft entity namespace as I have proposed yet, but the main namespace makes for a good substitute for the time-being. Therefore, I believe it is worth it to take the time to implement this first step in moving proposals to entities.
    Not only will proposals be faster to create and create properties from, but they will also bring more transparency to the proposal as people will be able to show all property constraints the property will have. Also, as properties develop into the future, new constraints and properties we add to properties will be able to be immediately supported as part of the proposal process without requiring us to change the Property proposal template and Lua script. An example of this just occuring was the addition of the implied notability parameter to the template. Lectrician1 (talk) 20:22, 7 November 2022 (UTC)[reply]
    Even with that 4:29 spend, JioSaavn artist ID (P11168) is still quite messy. It has six constraint violations for two different reasons. It also has a description that doesn't match what the item is about. It lacks a type constraint. Lectrician1 could have spent more time to make the item better, but if we require that we get even less work done on creating new properties. In the proposed new system it would be easy to say: "Hey, this property still has constraint violations so it doesn't get created. If someone wants the property they should put in the work to fix the constraint violations."
    The new system would lead to properties created at a higher quality because we could much easier enforce that the people who are actually interested in the property put in the work to clear constraint violations. ChristianKl ❪✉❫ 14:57, 8 November 2022 (UTC)[reply]
    +1 thanks for highligting this @ChristianKl So9q (talk) 10:19, 11 November 2022 (UTC)[reply]
  •  Oppose per Tacsipacsi and Epìdosis --Emu (talk) 11:46, 7 November 2022 (UTC)[reply]
 Support Wikidata is about solving problems with structured data. Solving our own processes with structured data is great. This will make it easier for new people to create property proposals as they don't need to understand all the terms like domain etc in the current proposal. I really like that this allow specifying the constraints of the new property before creating the property. I like to have a consensus around the constraints before the property gets created and this would allow it. That said I do believe that you should create property proposals for the proposed new properties so that we have a draft of how they should look like.
One other useful effect of this proposal is that it means that example items that it's straightforward for an admin who looks at example items that were created for a property proposal to see that they have that structural need. It would make the deletion tool warn of the usage which currently doesn't happen. ChristianKl ❪✉❫ 13:08, 7 November 2022 (UTC)[reply]
 Support Easy use, and already structured. JAn Dudík (talk) 11:04, 8 November 2022 (UTC)[reply]
  •  Conditional support I support this proposal under the following conditions:
    1. The discussion and voting of proposals does NOT take place in the Main MediaWiki namespace. So instead either the Wikidata: namespace where proposals currently live, or perhaps even a new Proposal:* namespace. This is to ensure that Special:RecentChanges can be used to subscribe to property proposal discussions specifically via an Atom feed (without having to filter through all the other talk that happens in Talk:).
    2. On the same page where discussion/voting takes place a MediaWiki template MUST be included that embeds all the relevant information of the proposed property directly into the page. I just created Module:EmbedItem as a proof of concept, see User:Push-f/embed demo for how that could look like.
    3. It MUST be allowed to have one discussion/voting page for the proposal of several properties (that could just work by embedding the aforementioned template multiple times with different IDs).
--Push-f (talk) 19:33, 8 November 2022 (UTC)[reply]
@Push-f
  1. I'm not going to do this. I can write a Atom feed service that aggregates the Atom feeds of pages that are the results of a SPARQL query and host it on Toolforge.
  2. Why?
  3. I think this is dependent on #1 being met which I'm not doing so will the "group proposal item and talk page" suffice?
Lectrician1 (talk) 14:28, 9 November 2022 (UTC)[reply]
  1. I can understand that you want the discussions to take place on the talk pages of items (which does make sense). Couldn't we establish a new data item namespace? So Proposal:Foobar would be a data item and Proposal talk:Foobar would be the corresponding talk page? Note that Special:RecentChanges has many features and you certainly don't want to reimplement them all.
  2. Because I really think all the information should be displayed on the same page. I strongly oppose to requiring people to switch back and forth between item page/discussion page, or requiring people to open two windows ... it just makes browsing proposals a pain.
  3. That could work. I guess it makes sense to have "group proposal items" to make that aspect queryable.
--Push-f (talk) 04:32, 10 November 2022 (UTC)[reply]
@Push-f
Couldn't we establish a new data item namespace?
Establishing a new entity namespace is exactly what I proposed to solve this issue at the last Community Wishlist Survey! I also created a Phabricator task for it.
However, given the complexity of the Wikidata software, the requirements of making sure the new entity namespace correctly interfaces with the other namespaces and is included as part of Wikidata Query Service, and the Wikidata team working on other tasks at the moment - I would not be able to complete such a momentus task on my own time.
So, when I saw the ready properties were getting out of control as of recently, I decided to propose this much simpler solution to implement which should help alleviate property creation work for the time-being. The ultimate goal of course is to eventually move the proposals to their own namespace when it eventually is created.
Note that Special:RecentChanges has many features and you certainly don't want to reimplement them all.
I thought about it and it's actually not that hard. All you need to do retrieve the Atom feeds from each of the entities selected every minute, combine them by timestamp, and then provide an Atom endpoint for all of those feeds. It is very basic to do.
Because I really think all the information should be displayed on the same page.
A userscript to show the Discussion page on the Main page is possible. I can have it done this weekend. Are you okay with that? Lectrician1 (talk) 15:09, 10 November 2022 (UTC)[reply]
The Wikidata team has not responded on the Phabricator task or triaged it, so just settling with the second best option seems like jumping the gun, especially because I assume that Wikibase doesn't support the moving of data items between namespaces, so the proposal items created in the main namespace couldn't be migrated to the new namespace without breaking all links.
I thought about it and it's actually not that hard.
I meant that Special:RecentChanges lets you apply many additional filters as well.
A userscript to show the Discussion page on the Main page is possible. [..] Are you okay with that?
No, I don't want a userscript. All the information should actually be part of the discussion page (so that you can view it on any device without needing to log in or install any script). This can be easily achieved with a template and should be done with a template. --Push-f (talk) 15:56, 10 November 2022 (UTC)[reply]
The Wikidata team has not responded on the Phabricator task or triaged it, so just settling with the second best option seems like jumping the gun
The Wikidata team will not take the time to respond to this, triage it, or work on it. This task is one of 2653 other tasks that have not been triaged yet. It is also not in their Development plan for this year so they will not be working on it. If you would like to ask them anyways their opinions on it, the best place would be the Wikidata Telegram. They monitor that Telegram and I've posted frequently there both about the Entity Draft Namespace and this proposal. So if the staff haven't responded to those proposals yet, I don't think they consider it a high priority are going to take the time to change their development plan to accommodate it.
especially because I assume that Wikibase doesn't support the moving of data items between namespaces, so the proposal items created in the main namespace couldn't be migrated to the new namespace without breaking all links.
In the case of property proposals in a draft entity namespace, they would not be moved to the main namespace but instead copied so that they can be preserved for reference.
I meant that Special:RecentChanges lets you apply many additional filters as well.
Well what the service I'm proposing would be doing is aggregating together the Atom feeds of the talk pages (Q1's talk page Atom feed) - not the Atom feed of Special:RecentChanges. Individual talk pages do not have filters so I do not have to worry about this.
No, I don't want a userscript. All the information should actually be part of the discussion page (so that you can view it on any device without needing to log in or install any script). This can be easily achieved with a template and should be done with a template.
Well, I guess this comes down to personal preference then.
@Wd-Ryan @So9q @The-erinaceous-one @Tinker Bell @ChristianKl @JAn Dudík
Do you think a template duplicating the statements on the item page like User:Push-f/embed_demo does should be required at the top of the Discussion page every property proposal? Lectrician1 (talk) 21:02, 10 November 2022 (UTC)[reply]
Yes, I think the current templates are nice for reading, but not nice for proposing or editing. I'd like if it put the data into Template:Property proposal, just for viewing. -wd-Ryan (Talk/Edits) 21:08, 10 November 2022 (UTC)[reply]
@Lydia Pintscher (WMDE): do you have an opinion about whether or not there should be a new namespace for draft items? ChristianKl ❪✉❫ 21:47, 10 November 2022 (UTC)[reply]
I agree with 2). The kind of information that's currently displayed in the template should also be displayed in the new system. To the extend that there's more information in the new proposal I wouldn't want to require all that information to be immediately displayed on the talk page but allow for anyone interested to improve the template/module to do that.
How do you currently use your atom script? Would it be enough to have new properties proposals that get created in your changefeed and then subscribe to those that interest you or do you really want all comments on property proposals? ChristianKl ❪✉❫ 11:47, 12 November 2022 (UTC)[reply]
  •  Oppose The proposer of a property shall have a good understanding of Wikidata anyway. If we have 100x faster property creation, will we have 99x more property deletions? Failed property proposals also don't meet any structural needs, and they could be simply vandalism. --Midleading (talk) 01:58, 9 November 2022 (UTC)[reply]
    @Midleading
    The proposer of a property shall have a good understanding of Wikidata anyway.
    You would need a pretty good understanding of Wikidata to propose a property with this system...
    If we have 100x faster property creation, will we have 99x more property deletions?
    That's some pretty flawed logic. It's up to the creator of the property, not the system by which they create it, whether they should create it or not. If you are concerned about properties being wrongly made, then the standard for property creators or the number of supports required should be raised.
    Failed property proposals also don't meet any structural needs, and they could be simply vandalism.
    They 100% have structural needs. Do you know how many times people have proposed a property multiple times? As a proposer of a number of properties myself, doing research on prior proposals, some of which have failed, is essential before you ever create one. If they are vandalism, then they will show up on the property proposal list and then be deleted. Lectrician1 (talk) 02:20, 9 November 2022 (UTC)[reply]
    A realistic example of property proposer without enough experience with Wikidata can be seen at Wikidata:Wikidata for Education and Wikidata:Property proposal/Generic. It looks like the user want to create properties on Wikidata when any of their spreadsheet column is not found. Instead they need to understand that Wikidata is not a spreadsheet.
    Adding properties and labels on an Wikidata property proposal (Q114746893) also would cause property scope violations and pollutes MediaWiki search. They shouldn't be linked to other items, but with labels and descriptions confusingly look like actual items it is hard to tell them apart. Some development work on Wikibase needs to be done, not just a property creation Javascript. Midleading (talk) 02:50, 9 November 2022 (UTC)[reply]
    A realistic example of property proposer without enough experience with Wikidata can be seen at Wikidata:Wikidata for Education and Wikidata:Property proposal/Generic. It looks like the user want to create properties on Wikidata when any of their spreadsheet column is not found. Instead they need to understand that Wikidata is not a spreadsheet.
    I agree that this person did not have good understanding when they proposed their properties. But, that doesn't mean that their proposals are simply invalid or bad. The user has been responsive in the proposal process and worked with the community to refine some of their proposals. This proposal system would still allow for the same communication and even better access to editing proposals than the current system - meaning that community members could easily improve a proposal or still give feedback that it is not needed in the same capacity that they are able to with the current proposal system.
    Adding properties and labels on an Wikidata property proposal (Q114746893) also would cause property scope violations
    Changing the property constraints to allow them to be used on items and specifically only Wikidata property proposal (Q114746893) items so that there are no property scope violations is part of this proposal. See the first item of #Implementation tasks.
    pollutes MediaWiki search. They shouldn't be linked to other items, but with labels and descriptions confusingly look like actual items it is hard to tell them apart.
    This is a good point. As part of the duplication script, I will makes it so that the original proposal item's description is changed to start with "property proposal" to indicate that it is a proposal, not the property, in the search results. Lectrician1 (talk) 14:07, 9 November 2022 (UTC)[reply]
    This proposal system would still allow for the same communication and even better access to editing proposals than the current system - meaning that community members could easily improve a proposal or still give feedback that it is not needed in the same capacity that they are able to with the current proposal system.
    Often the most needed improvement of a low quality property proposal is its intended usage and data model. And this is not improved with access to an Wikidata item (in fact it degrades the experience of discussion on a property's usage by separating examples from the discussion page, see Talk page). If the intended usage is defined clearly, is valid and is not a duplicate, no problem creating the actual property, even without stability of property value (P2668), equivalent property (P1628) etc. I agree that the property creator should use their expertise to help setting up the new property, but even if they don't and instead run a scipt, the property proposer or somebody else will do it after the new property is created. So time is not an excuse of the property proposal backlog. Discussion and writing the documentation/definition is. And the new system could not help very much here. Midleading (talk) 09:05, 10 November 2022 (UTC)[reply]
    @Midleading
    And this is not improved with access to an Wikidata item
    I understand your view that because Wikidata items are easier to create than property proposals right now, people will be producing lower-quality proposals that don't specify as many parameters. Some solutions to this I see are guiding the user to make a copy of the example property proposal item and then re-filling in all of the the values with the ones they propose. Constraints could be added to make sure the items with instance of (P31)Wikidata property proposal (Q114746893) always have the other statements that should be part of a property proposal including "property constraint", "source website", etc.
    in fact it degrades the experience of discussion on a property's usage by separating examples from the discussion page, see Talk page
    They're separated by one click. It's not going to have a impact on the quality of proposals. People still have to reference the item if they ever want to discuss anything about the proposal.
    but even if they don't and instead run a scipt, the property proposer or somebody else will do it after the new property is created.
    Then it should be a requirement that property creators add any statements that were missing from the proposal to the final property after the script is run. Lectrician1 (talk) 15:28, 10 November 2022 (UTC)[reply]
    I'm not particularly concerned with people create a property proposal without necessary information. Instead I'm concerned that people focus too much on filling in information on the item. A good property proposal can have as little as three examples and without constraints. They can be added during discussion and after creation. A low quality property proposal always has something inherently blocks its adoption, usually because it lacks serious sources, is too broad to be clear, or duplicates existing properties. Adding more statements without addressing the core problem doesn't help, just like adding any number of non-serious sources doesn't make an item notable. I don't think these low quality proposals meet notability requirements for the same reason they are failed. High quality ones? No problem, they deserve it, in the property namespace, not fully protected items in the main namespace with content largely duplicate the property. Main namespace is not supposed to be used as an archive. Wikidata only has 4 fully protected items after all.
    If users find an item useful while creating a property proposal, I  Support that they can create one and link the item to the property proposal page with sitelink to Wikidata namespace. We even have items for tracking specific Wikipedia:Long-term abuse (Q10854626), so why not? But when the property proposal is closed, the item should be deleted because it is either not notable, or duplicates a created property (Content is accessible through the page history tab at any time later). It will not pollute MediaWiki search as well if all pending property proposals are not duplicates. Midleading (talk) 10:36, 11 November 2022 (UTC)[reply]
    Failed property proposals do fulfill structural needs as they provide documentations why certain properties don't exist in Wikidata. By custom the people who participated in a previous discussion on a given property should also be notified if a similar property gets proposed again and for that it's also important to have the data.
    The new system requires the person who proposes to specify the constraints for the property while the old one doesn't. At least it does, if we say that won't create any properties if there are constraint violations in the property proposal item. That means it's easy to add a bunch of constraint that easily communicate when certain information is missing.
    I don't think our current system handled the case with the education properties well. In the case of the eduction property, it started out with proposals that didn't have valid property examples. In the new system the user would more easily understand that his proposal doesn't have valid property examples.
    Property creators still have the responsibility to only create properties that actually make sense. If a property creator would have a majority of their properties getting delete I expect that we would remove their ability to create properties quite soon.
    As far as the new items polluting the search, if someone searches for a property and finds that there's no property but an open property proposal for that property, that's a desireable outcome. If it's a closed property proposal, that person can read why we didn't create the property which is also useful. These items are not going to have many inbound links or Wikilinks so they are not going to rank highly. If they rank too high, we can also ask to derank them in a similar way as academic papers currently rank lower than other items. ChristianKl ❪✉❫ 11:37, 12 November 2022 (UTC)[reply]
    But I still fail to see how these property proposal items contain notable and structured data. Don't tell me you're gonna attach Wikimedia username (P4174) on these items. There isn't structured representation of what the property is, how is it succeeded/failed, and who participated in it. Even the required fields may be missing as well. If they are structured enough, why isn't there already a new property? There's nothing they can be linked from. Instead what they contain are hot keywords in the labels and descriptions, just like what websites do to promote their search ranking without actually have content to offer. They will also appear whenever anyone creates a statement (item suggestion is a form of MediaWiki search), and a percentage of users will be confused by that.
    I work in an area where most of the items start with very few statements. I accept the fact that one needs to clean up Wikidata before doing the actual query. Have to query from a list of unstructured fully-protected items? No way! The best way of finding a previous property proposal, including its all participants, is to go to Wikidata:Property_proposal/Archive, hit "search". Midleading (talk) 00:09, 13 November 2022 (UTC)[reply]
    @Midleading: Regarding notability, see my comment below and let me know what, if anything is unclear:
    There's a long-standing precedence to create WikiData items that are purely for internal use by Wikidata. As stated in Wikidata:Notability, "An item is acceptable [if] it fulfills a structural need." See orderable Wikidata property (Q18668171), Wikidata property related to creative works (Q18618644), Wikidata qualifier (Q15720608), Template:Wikidata list (Q19860885), Wikidata Sandbox (Q4115189). The proposed use of items to model proposed properties clearly serves a structural need and therefore is notable.
    Regarding your other objections:
    There isn't structured representation of what the property is...
    A structured representation of the proposed property is exactly what the property proposal item would be. It would have labels, descriptions, and alias (in one or more languages), and would have WikiData statements to specify constraints, examples, etc. There might be missing information, but that also happens (pretty often) with existing property proposals.
    There isn't structured representation of [why] it succeeded/failed, and who participated in it.
    The information about who participated in the discussions for property proposals would be recorded in the discussion page for each property proposal item. I don't see any value in providing that data as structured data, but if there is, then we could easily make properties for that purpose.
    If they are structured enough, why isn't there already a new property? There's nothing they can be linked from. Instead what they contain are hot keywords in the labels and descriptions, just like what websites do to promote their search ranking without actually have content to offer.
    Not sure what point you are trying to make here. There are several reasons a well-structured property proposal might not be made into a property. There could be other reasons against creating it (e.g., lack of notability, poor modeling), or perhaps no property creators has yet had time to make it.
    They will also appear whenever anyone creates a statement (item suggestion is a form of MediaWiki search), and a percentage of users will be confused by that.
    This is a good point. It might be confusing for a user to see a property proposal item pop up as a suggestion. I think it would be fairly rare, in the big scheme of things, but still worth considering. What are some ways we could mitigate this? Maybe we could adopt a standardized naming schema so that every property proposal is clearly labeled? — The Erinaceous One 🦔 08:20, 13 November 2022 (UTC)[reply]
    Not sure what point you are trying to make here. There are several reasons a well-structured property proposal might not be made into a property. There could be other reasons against creating it (e.g., lack of notability, poor modeling), or perhaps no property creators has yet had time to make it.
    I know some instances of that, for example, Wikidata:Property proposal/Baidu Baike ID (2). But apart from these instances, I don't think most other property proposals have enough structured information to be useful (I mean, more useful than merely a property proposal page in wikitext). As you said, these items will contain labels, descriptions, aliases, examples, property constraints, and "instance of" statements. The information can already be found at Wikidata:Property proposal/Archive. There's a limitation that other tools like Wikidata Query Service (Q20950365) isn't available to produce aggregated overview (one of the benefits). But that will be difficult as well after property proposal items are allowed, you have to go through every item and search in reasonably different ways (including in the talk archive) to be certain you've found what you want (not as simple as a list of all open requests that's already available at Wikidata:Property proposal).
    I know these items can be "Reuse of a proposal", but I think a better starting point would be established properties. Data for them are already available from the property namespace, cover nearly every aspect of Wikidata and are of high quality. No point directing users with little/no experience on Wikidata properties to repeat prior failure. It also encourages users to first search for an existing property. Property for new external identifier could be copied from existing external identifier, after a few modifications it is ready for review.
    As I suggested, MediaWiki search will be free from closed property proposals, if these items are deleted when the proposal is closed. The structured data in these items either go to the talk archive (It is as easy as prepending template calls with "subst:"), or go to the created property. --Midleading (talk) 10:15, 13 November 2022 (UTC)[reply]
    @Midleading:
    I don't think most other property proposals have enough structured information to be useful
    In WikiData, a property is structured data, so a property proposal should also be structured data. The problem with the current system is that property proposals is that they are not structured. The current property proposal template allows users to put information in the proposal using any format they like, which means that property creators have to translate everything into structured data when they create each property. The proposed change, where users would propose properties as structured data would make it faster and easier for property creators to generate properties once proposals are ready.
    Searching for old property proposals would also be easier if they are stored as structured data, because you could filter based on the values of specific properties on the proposals rather than needing to sift through unstructured data as is currently the case.
    But that will be difficult as well after property proposal items are allowed, you have to go through every item and search in reasonably different ways (including in the talk archive) to be certain you've found what you want (not as simple as a list of all open requests that's already available at Wikidata:Property proposal).
    Currently, you need to check three places before creating a proposal: (1) if the property already exists, (2) if the property was previously proposed, or (3) if it is is on the pending list. With the new approach, you could look in only one place: the list of property property proposals (assuming we transcribe all previous property proposals to the new system). There wouldn't be any need to look at talk pages to determine if there was already a property proposal. — The Erinaceous One 🦔 05:09, 14 November 2022 (UTC)[reply]
    As I stressed, it is not easier to look up for a property proposal item than just search with MediaWiki search in the talk archive. Imagine you are the one with zero knowledge in SPARQL and have to find a previous property proposal item for properties listed on Wikidata:Wikidata for Education, you most likely end up arriving at Wikidata:Property proposal/Archive and search from there. I'm experienced in SPARQL and I have to say it requires more time than just a MediaWiki search for experienced people as well (it is difficult to figure out how a previous property proposal links to the concept "ISCED").
    Also as I already said, property proposals should continue under "Wikidata:Property proposal/" prefix. If they take place in main namespace instead, MediaWiki search with prefix would become impossible, so it is not possible to add the search button on Wikidata:Property proposal/Archive without also searching in talk pages for other items.
    I should repeat that I  Support users can create the property proposal item and link it with the property proposal page with sitelink to Wikidata, if they find it useful. They can also decide not to create such an item, or to create multiple items for a list of related properties. They can even copy from an existing property to start with. But I  Oppose using the main namespace as a permanent archive for property proposals, since its usefulness (compared to plain wikitext archive page) and notability (not all property proposals demonstrate that it is a clearly identifiable conceptual or material entity, especially failed ones. Also a failed property proposal doesn't have any existing property to be linked from, so there is no structural need to keep it) is doubtful. Midleading (talk) 03:26, 19 November 2022 (UTC)[reply]
    Note: an example Q114039810 and Wikidata:Property proposal/Sogou Baike ID Midleading (talk) 10:13, 19 November 2022 (UTC)[reply]
    You can also prefix the labels with "Wikidata:Property proposal/". I don't like property proposal discussions on Talk namespace. They should remain under prefix Wikidata:Property proposal/. A sitelink can be used to link the item to its discussion, as I suggested before. The sitelink may be required actually because templates on the discussion page need to read the structured data. Midleading (talk) 10:53, 13 November 2022 (UTC)[reply]
* Oppose, since I can't see to what extent it could be notable enough. Nomen ad hoc (talk) 10:20, 10 November 2022 (UTC).[reply]
@Robertgarrigos You should check out this proposal since you wanted some properties to be created recently... Lectrician1 (talk) 22:24, 15 November 2022 (UTC)[reply]
 Support It makes sense to use items itself for property proposals. I just made my first property proposals and got them approved within a few weeks. I didn't find the process specially difficult, but it annoyed me that I had to wait the whole process to begin using them. If I understood well, with this new process a new property proposal will be ready to be used straight away, which will also serve as a good example of its use. Thus, I see this as a nice improvement. Thanks, @Lectrician1, for letting me know. Robertgarrigos (talk) 02:03, 16 November 2022 (UTC)[reply]
There will still be a delay between when you create a property proposal and when the property is created so that you can actually start using it. The difference will be that the creation will happen faster once the discussion about property proposal is finished. — The Erinaceous One 🦔 03:09, 16 November 2022 (UTC)[reply]
 Oppose I prefer entity draft namespace.--GZWDer (talk) 10:30, 19 November 2022 (UTC)[reply]
@GZWDer That doesn't exist yet though... What are we going to do in the meantime? Lectrician1 (talk) 18:13, 19 November 2022 (UTC)[reply]
@Lectrician1: How hard is it to make a new namespace? It would be awesome if we could have a sandbox property namespace where (1) anybody could create a new (dummy) property for the sake of proposals, (2) each dummy property could have any property statements that "real" properties, and (3) to create a new property, a property creator would simply copy a dummy property from the sandbox namespace into the Property namespace. — The Erinaceous One 🦔 09:35, 20 November 2022 (UTC)[reply]
@The-erinaceous-one It's really hard to do anything with Mediawiki. Go bother the Wikidata dev team and they'll tell you the same thing. Lectrician1 (talk) 16:35, 20 November 2022 (UTC)[reply]
@Lectrician1: Ah, okay. So it would need to be done by the dev team? I think the proposed approach is OK as a stop-gap measure, but I think we should have a plan for a long-term solution before we move forward, just so that we know that our stop-gap isn't going to prevent a better solution. — The Erinaceous One 🦔 08:46, 21 November 2022 (UTC)[reply]
Waterfall is a bad framework for making progress. It's not necessary to have a long-term solution in mind beforehand. Agile development where on moves one step at a time is useful. ChristianKl ❪✉❫ 15:32, 21 November 2022 (UTC)[reply]
I'm pretty sure that considering possible consequences is not waterfall. We can dynamically update our plans while also thinking long-term.
That being said, if we make the proposed change and properly label all of the property proposals, then I expect that it would be fairly easy to move all of them to a new namespace down the line. — The Erinaceous One 🦔 20:24, 22 November 2022 (UTC)[reply]
 Strong oppose I am extremely sceptical that making people use Wikidata items to propose properties will be easier for the majority of people, or that it improve their proposals. Most people do not edit properties, and they should not need to be familiar with editing properties in order to propose a new one. I also don't think we should completely replace the existing system without first trying to improve the existing system via less extreme changes.
Making items for proposals will not actually solve the issues I have when creating properties. Some of the biggest problems I have with creating properties:
  • Adding constraints is really tedious because I have to look up all the correct items, qualifiers and qualifier values. It is also really tedious when editing existing properties, so an improvement would be to make a constraint editor tool which knows which constraints are possible, what their values should be, and can show which ones are still missing. Creating items for proposals will not fix that problem.
  • The fields in the proposal template do not map nicely to statements on the property. The proposal template dates back many years and is also not compatible with the template editor in the visual editor, so an improvement would be to make a new template (perhaps more than one, e.g. external IDs have a number of extra fields which don't apply to other datatypes) designed around which information we actually want (rather than which information we thought we should ask for years ago), which people understand how to fill out.
  • It's hard to keep track of which properties I want to add and I usually miss something. I have to compare properties with other properties to see if there's something I missed. I have exactly the same problem when creating items, so creating items isn't the solution to that either.
  • The proposals are incomplete or unclear, examples are missing or broken, there are unanswered questions, etc. When I go through proposals marked as ready, I usually end up removing the ready status from at least a few. The only solution to this is for people to improve proposals. People can already do that but don't, so I don't think creating items will solve that. One thing I've suggested a couple of times is to have sessions similar to the bug triage hours, where some of the more experienced editors would get together, e.g. on Jitsi, from time to time and spend e.g. an hour going through a few proposals together in order to improve them.
  • It's hard to tell whether people are supporting a proposal because they want to use it (regardless of how good the proposal is) or because the proposal looks good (even if they don't want to use it). I only want to create properties if people actually plan to use them and if the proposal is complete and looks good. Making items for proposals will not tell me that. An improvement would be for proposals to have a section for people to add their names if they plan to use it, a section for people to say they think the proposal looks good, and then leave the discussion section for actual discussion. This would also offer a solution to the debate about whether you can support your own proposals, by saying that people can add their names to the list of people who plan to use it, but not to the list of people who have checked the proposal and think it looks good.
- Nikki (talk) 16:27, 28 November 2022 (UTC)[reply]
@Nikki
I am extremely sceptical that making people use Wikidata items to propose properties will be easier for the majority of people, or that it improve their proposals. Most people do not edit properties, and they should not need to be familiar with editing properties in order to propose a new one.
If you don't know how to edit properties, I don't think you should be proposing one. If you're not familiar but you'd still like to create a proposal, this should still be easy as properties have statements just like items do and the proposal template item will help the author propose the property they want.
Adding constraints is really tedious because I have to look up all the correct items, qualifiers and qualifier values. It is also really tedious when editing existing properties, so an improvement would be to make a constraint editor tool which knows which constraints are possible, what their values should be, and can show which ones are still missing. Creating items for proposals will not fix that problem.
Yes it will because you will be able to specify the constraints on the proposal item and then those constraints could be immediately copied to the new property.
It's hard to keep track of which properties I want to add and I usually miss something. I have to compare properties with other properties to see if there's something I missed. I have exactly the same problem when creating items, so creating items isn't the solution to that either.
That's why there's going to be a template proposal item people can copy and then edit.
The proposals are incomplete or unclear, examples are missing or broken, there are unanswered questions, etc. When I go through proposals marked as ready, I usually end up removing the ready status from at least a few. The only solution to this is for people to improve proposals. People can already do that but don't, so I don't think creating items will solve that. One thing I've suggested a couple of times is to have sessions similar to the bug triage hours, where some of the more experienced editors would get together, e.g. on Jitsi, from time to time and spend e.g. an hour going through a few proposals together in order to improve them.
This point is interrelated to this proposal, but your thoughts are agreeable.
It's hard to tell whether people are supporting a proposal because they want to use it (regardless of how good the proposal is) or because the proposal looks good (even if they don't want to use it). I only want to create properties if people actually plan to use them and if the proposal is complete and looks good. Making items for proposals will not tell me that.
How so? There will be a discussion page just like a normal that the author will express their motivation.
An improvement would be for proposals to have a section for people to add their names if they plan to use it, a section for people to say they think the proposal looks good, and then leave the discussion section for actual discussion. This would also offer a solution to the debate about whether you can support your own proposals, by saying that people can add their names to the list of people who plan to use it, but not to the list of people who have checked the proposal and think it looks good.
I agree that such sections would be helpful. We can include such sections as part of the property proposal discussion page template if you would like. Lectrician1 (talk) 16:55, 28 November 2022 (UTC)[reply]
"Adding constraints is really tedious because I have to look up all the correct items, qualifiers and qualifier values" the question here is whether that tedious work should be done by those who want the property or by property creators. I think it makes more sense to let the people who want the property do it. Given that users can look at existing items, while the work is tedious it's also easy to do for people who are new to property creation. Understanding what we mean with domain and allowed values is harder.
Additionally, I do think that finding consensus about what constraints there should be matters when it comes to property creation. ChristianKl ❪✉❫ 17:17, 28 November 2022 (UTC)[reply]
Understanding what we mean with domain and allowed values is harder.
So true. Lectrician1 (talk) 19:31, 28 November 2022 (UTC)[reply]

 Oppose I've only created and commented on a few properties, but I didn't find the procedure hard. What was frustrating was trying to find a place to advertise them, and getting enough people's opinions to validate them. I don't see how this change can help with that side of things, so I see no reason to alter the creation side. Vicarage (talk) 23:21, 29 November 2022 (UTC)[reply]

@Vicarage: from what I saw you don't have the property creator right, so while you might have proposed properties you didn't create any.
I do think that the new system would make it easier to get people's opinions to validate properties because it's easier to create more autogenerated lists. It would for example get easier to create lists for all new property propsoals for a given Wikiproject.
A lot of the problem of getting opinions to validate properties is that there are many purely thought out properties that aren't really ready to be created. This system will make it easier to automate the process of communicating the needed improvements. ChristianKl ❪✉❫ 01:09, 30 November 2022 (UTC)[reply]
@Vicarage: Currently, there are a lot of "ready" property proposals. This is largely a result of how laborious it is to create a property from the property proposal. Property creators can't keep up with property proposers. By switching to an item-based system of property proposals, each proposal will stand out more and, hopefully, get more attention because there will be fewer proposals for users to sift through. — The Erinaceous One 🦔 02:19, 30 November 2022 (UTC)[reply]

 Weak support I feel like there might be some use for prefilling a property template based on an existing property. Certain sites can have multiple identifiers, and you can often reuse the property for one identifier when making the other, RPI2026F1 (talk) 02:14, 30 November 2022 (UTC)[reply]

 Oppose: I change my opinion because instead of doing this, the community should make another tool like User:DannyS712/PropertyCreator.js. The "prefilled form" approach saves a lot of time and allows a lot of customizability. RPI2026F1 (talk) 02:11, 31 December 2022 (UTC)[reply]

 Oppose It will just lead to a lot of confusion between the Property and Item namespace for less-experienced editors. --LydiaPintscher (talk) 11:41, 26 December 2022 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Create_items_for_property_proposals&oldid=2047892409"