Wikidata talk:Requests for comment/Create items for property proposals

expertise

•  Comment Sure it's a tedious job, but IMO one of the reasons we have the property creator role is that these editors have quite a good expertise about how things work on property pages due to their regular involvement. We might be able to offload the work of pseudo-creating a property in main namespace to inexperienced users, but without the experience they either need lots of support or new properties based on such a process might be inferior to existing ones because the property pages are simply not set up correctly. For this reason I tend to  Oppose this, but let's hear other opinions first. —MisterSynergy (talk) 20:54, 5 November 2022 (UTC)

  I wouldn't consider creating something creating something in main namespace to be that hard given that there are thousands of property examples already out there and creating property proposal items will become commonplace as well meaning users will have lots of options to look at how they should propose a property.

  Another benefit is if they mess up or do something wrong, other users can easily add or fix statements which is a lot faster than editing the Property proposal template. Lectrician1 (talk) 21:08, 5 November 2022 (UTC)

  Agreed. If there is a problem with the initial proposal, other users (not just property creators) could help get it into the proper format. Any remaining issues could be pointed out by the property creators to be addressed before the property is created or they could simply fix it if is a fast/easy fix. The goal should be to let property creators focus on evaluating that a proposal has sufficient support, guiding the design of properties as-needed, and ensuring that the resulting properties are properly setup. Anything we can do to let the avoid tedious tasks would let them focus on those things more. — The Erinaceous One 🦔 09:57, 6 November 2022 (UTC)

transition from current system

 Comment Would the current property archive be backported? Arlo Barnes (talk) 23:54, 5 November 2022 (UTC)

If you wanted to... I wouldn't see a problem with it. That's not a requirement of this proposal though. @Arlo Barnes Lectrician1 (talk) 01:44, 6 November 2022 (UTC)

I think it definitely should be backported. It will be confusing searching for previous proposals in two locations, like when you want to see if one has been proposed already. -wd-Ryan (Talk/Edits) 03:42, 6 November 2022 (UTC)

We'd need another new script/bot for that, then. — The Erinaceous One 🦔 09:58, 6 November 2022 (UTC)

I see. I think it would be a good idea so that at least one system has a complete listing of what sorts of things have already been proposed, successfully or otherwise. Interesting RFC, thanks for posting it. Arlo Barnes (talk) 02:27, 6 November 2022 (UTC)

Linking to created property

 Comment How would the items for the proposals link to the newly created property? We shouldn't use Wikidata property (P1687), as it has an inverse constraint (Q21510855), which means the proposal will be on the property as Wikidata item of this property (P1629). -wd-Ryan (Talk/Edits) 03:49, 6 November 2022 (UTC)

@Wd-Ryan See #2 of #Creation:

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.

Lectrician1 (talk) 18:40, 6 November 2022 (UTC)

Oh yes, but not in reverse? -wd-Ryan (Talk/Edits) 19:00, 6 November 2022 (UTC)

We don't do reverse properties :) (though I'd like one too). Luckily, the property proposal will have "property proposal status: done" to mark it is done. I decided on making a property that links from the property to the proposal because that's what property proposal discussion (P3254) currently does. I could flip the direction of "property proposal" to be "property created", but you'd have to make a case for that. Lectrician1 (talk) 19:30, 6 November 2022 (UTC)

Maybe we can use property (P2306) as a qualifier to "property proposal status: done"? -wd-Ryan (Talk/Edits) 21:18, 6 November 2022 (UTC)

uhhh I wouldn't expand the scope of that property. It's meant for a specific use as a constraint. Lectrician1 (talk) 21:29, 6 November 2022 (UTC)

Wikidata property (P1687)? -wd-Ryan (Talk/Edits) 21:52, 6 November 2022 (UTC)

UHHHH NO WAY. That property is realllyyy bad. It has no semantics because it links anything that has any relation to a property without describing what that relationship is. I would put it up for deletion but I haven't come up with replacements yet. Lectrician1 (talk) 23:29, 6 November 2022 (UTC)

I see... the current property proposals link to the new property when done, though. Would be nice. -wd-Ryan (Talk/Edits) 00:20, 7 November 2022 (UTC)

Property Item Template

We should be careful to ensure that any new approach doesn't lead to a degradation in the quality of proposals by e.g., making it hard for users to know what information is required. Can we have a copyable template item for property proposals to help users add all the relevant fields? — The Erinaceous One 🦔 10:00, 6 November 2022 (UTC)

Yes, that will be created and part of the new documentation on how to create a property item. Lectrician1 (talk) 18:41, 6 November 2022 (UTC)

Concerns about separate pages, separate page histories and Wikidata property example (P1855) being unintuitive

•  Strong oppose: I oppose for three reasons:
  1. proposal details and discussion on separate pages: The details of the proposal and the discussion would be on separate pages, which is just more cumbersome for people participating in the discussion because you have to go back and forth between the pages to have an overview. This would be even worse for proposals to introduce multiple properties at once. See for example my proposal from language & to language. Note how the details for both proposed properties as well as their discussion are on a single page. If this RFC was implemented this would be split up across four pages (yes one discussion page could reference another one but that would still leave us with three pages).
  2. separate page histories: this is especially cumbersome because it makes tracking changes to the proposal a nightmare, because it's no longer one page history but suddenly 2-* page histories (depending on how many properties are involved in the proposal). Have a look at [1] and notice how nicely you can see a timeline of replies and modifications to the proposal. This would no longer be possible if this was split up across several page histories.
  3. Wikidata property example (P1855) is unintuitive: I do not like Wikidata property example (P1855) at all because I find it very confusing to look at because it puts the illustrated property on the same level as exemplary qualifiers ... which is just not at all how Wikidata is usually presented. I find Template:Statement to be much clearer. Nitpick: Wikidata property example (P1855) also does not number the examples so they would also not be as easy to refer to from the discussion.

I strongly agree that the creation of properties should not be a hassle for property creators (it really shouldn't take more than two clicks) but I am certain that the creation can be automated just as well using templates ... templates can be powered by Lua, which should be more than powerful enough to achieve that. If some MediaWiki (template) expertise is needed to implement that I am happy to help with that.

Sidenote: I also strongly agree that the lack of autocompletion for data items/properties within wikitext is a major pain when proposing/discussing properties, but I feel like that has to be addressed via a MediaWiki gadget, which would also benefit the discussion of properties, not just their proposal ... as far as I can tell this doesn't exist yet ... I could probably implement that, though I am currently quite busy.

--Push-f (talk) 15:52, 8 November 2022 (UTC)

@Push-f

The details of the proposal and the discussion would be on separate pages, which is just more cumbersome for people participating in the discussion because you have to go back and forth between the pages to have an overview

Agreed that it's more cumbersome, but there is such a thing as opening 2 windows. The structure of Mediawiki having the discussion page and content page on 2 different pages isn't good to begin with for most use cases. I could make a script for you to show and be able to edit the discussion page from the content page if you would like.

This would be even worse for proposals to introduce multiple properties at once. See for example my proposal from language & to language. Note how the details for both proposed properties as well as their discussion are on a single page. If this RFC was implemented this would be split up across four pages (yes one discussion page could reference another one but that would still leave us with three pages).

I see 2 possible solutions for this:

• We could allow for dedicated discussion pages to be created for proposals that propose multiple properties. For example you could create a page at Wikidata:Property proposal/example and it could act as the proposal page and discussion page for the multiple properties proposed. That page could then be linked on the list of proposals page at Wikidata:Property proposal/Generic. Only downside to this is that the properties proposed would also be included in the Listeria list of proposals below.
• Second solution is allowing for a "group property proposal" item to be created. It would then has part(s) (P527) the proposals part of the group proposal. That group proposal item's discussion page is what would be used for the entire proposal. Listeria could then be configured to only show the group proposal and not its parts on the proposal list page.

separate page histories: this is especially cumbersome because it makes tracking changes to the proposal a nightmare, because it's no longer one page history but suddenly 2-* page histories (depending on how many properties are involved in the proposal). Have a look at [1] and notice how nicely you can see a timeline of replies and modifications to the proposal. This would no longer be possible if this was split up across several page histories.

I don't personally check page histories much when looking at proposals. If a proposal changes, then I can see that change reflected on the proposal template/item since I last saw it and then I know it's changed. Also, because people will be able to add any property to a proposal item now, community editing of proposals will likely be much higher and thus proposals will change much more than the changes that are discussed. Therefore, somewhat polluting the history of the proposal and making it less-useful.

Wikidata property example (P1855) is unintuitive: I do not like Wikidata property example (P1855) at all because I find it very confusing to look at because it puts the illustrated property on the same level as exemplary qualifiers ... which is just not at all how Wikidata is usually presented. I find Template:Statement to be much clearer.

Well there's not much I can do about that. I could make a script to indent qualifiers so that it's more understandable...

If some MediaWiki (template) expertise is needed to implement that I am happy to help with that.

Please do, but like I've stated above, if properties are what we're proposing, it definitely makes sense to mimic their final structure as close as possible, and doing that with items at the moment is the closest solution we can get. I don't believe templates should be the long-term solution when the structure of Wikidata properties could change at any time. Lectrician1 (talk) 16:26, 8 November 2022 (UTC)

Currently, most people don't visit the page where the proposal is actually defined when they read about the proposal to discuss it. We have a template system that allows information to be imported from pages into other pages that's what can be done via Lua. We have currently a template on the property talk pages and will likely have a similar template on the property proposal talk page, so that people don't need to visit the item in question to understand the proposal.

Examples don't just exist to be useful during the discussion of the proposed property. They are important when it comes to people learning about how to use the When trying to understand how a property works, most people don't look at the property proposal but at Wikidata property example (P1855). For most properties with decent usage, most of the people reading property examples will do it on the item of the property and not on the property proposal page. When it comes to how the data is displayed on the property proposal page we can create a template that presents them the way template-statement does based on the information in the item.

The way you formated the proposal in https://www.wikidata.org/wiki/Wikidata:Property_proposal/from_language_%26_to_language adds extra work to the property creator because you didn't provide the examples in a way that can easily be copied into Wikidata property example (P1855). When I was a property creator, I would have simply thought: "Your proposal currently doesn't have valid property examples, so it's not ready for me to create it."

Having separate edit histories for item/property pages and talk pages as an universal feature all over Wikidata (and in Wikipedia you have the same with articles and talk pages), to the extend that it's good to see that history together, having an option in the MediaWiki software to show both would be the better path. ChristianKl ❪✉❫ 16:37, 8 November 2022 (UTC)

Thanks, you do make very good points. I'll try to implement such a Lua-based template that displays the information from an Wikidata property proposal (Q114746893) instance to see how that could look like. --Push-f (talk) 16:43, 8 November 2022 (UTC)

I have updated my stance on this proposal to  Conditional support (see the RFC page). Embedding the data item info via a template addresses most of my concerns. Even the unintuitive representation of Wikidata property example (P1855) and lack of example numbering could quite easily be addressed.

The separate page histories are still bothering me, but you make a very good point that this really is something that should be supported by MediaWiki in general.

Cheers, --Push-f (talk) 19:40, 8 November 2022 (UTC)