Requests for Comment/Miraheze Data - a common structured data repository for Miraheze

From a conversation with an idea came out about providing Miraheze with a common repository of structured data. Much like Wikidata provides data to all the sites of the Wikimedia universe, Miraheze users could take advantage of having a commonly available place to share structured data. The reason supporting this proposal are similar to the ones behind the creation of Miraheze Commons. --Lucamauri (talk) 11:48, 24 January 2022 (UTC)

Disclaimer: What exactly are we averse to?
Although these proposals are made in good faith and for the betterment of the Miraheze universe, there are some things we don't plan of doing as these proposals are being made. We don't plan to; These proposals are solely for the betterment of the Miraheze universe.
 * Overcomplicate our systems
 * Leave users out of the decision-making process
 * Add any more vandalism avenues

Previous discussions
A preliminary discussion was already started at T8630, where I was originally invited to open a RfC.

Quick SWOT Analysis
needs to be customized both in the Repo and Client instances when a wiki needs to use the system

External Opportunities:
 * Administration of the site might prove complicated (for instance handling properties definition and creation)
 * Specific demands from vastly different wikis might lead to proliferation of properties and data useful only in specific cases
 * Attract more users providing a ready-to-use Wikibase installation
 * As Wikidata is not accessible outside Wikimedia farm, public Wikibase instance on Miraheze could be interesting for the general public
 * Organisation of wiki-text pages from all wikis that subscribe to it, allowing us to create machine-readable and machine-relatable pages for Internetbots like Googlebot and Bingbot to read
 * It will allow; Users to link content across Miraheze wikis, readers to delve deeper into our knowledge ecosystem, and contributors to spread information across wikis and beyond in a structured manner.

Threats:
 * Federation might never work in a proper way
 * Wikidata might one day be opened to the general public, possibly rendering this repository useless

Proposal 1: Miraheze Data
The proposal calls for the installation of a Wikibase Repository that should be named, either  or. Meta Administrators as well as other volunteers (users) who are well knowledgeable in Wikibase should be administrators on the wiki, they should also take responsibilities of creating Properties, while, of course, Items should be editable by all the registered users, unless they're protected. Administrators should also be in charge of adding new sites and enable SiteLinks to allow Direct Access feature.


 * Note: This proposal is simply asking if you would want to see the Data wiki in existence, if you support/oppose/abstain the idea of having a structured data wiki. --Lucamauri (talk) 11:48, 24 January 2022 (UTC)

Support 1

 * 1)  as proposer --Lucamauri (talk) 11:48, 24 January 2022 (UTC)

Comments 1

 * 1) I would only vote if they move this page to the main namespace. --YellowFrogger  ( talk ) ( ✔ ) 16:55, 24 January 2022 (UTC)
 * Sorry. I also saw that you can't vote now. This one was a note. Thanks. --YellowFrogger ( talk ) ( ✔ ) 17:00, 24 January 2022 (UTC)
 * Yeah, it isn't open for voting as more information needs to be added and that would be done any moment. --  Joseph  TB  CT  CA   21:17, 24 January 2022 (UTC)
 * 1) This seems like an intriguing proposal, but sort of structured data would Miraheze Data host? — Arcversin (talk) 17:11, 24 January 2022 (UTC)
 * Maybe I misunderstood the "would Miraheze Data host?" part, but it has nothing to do with that. One of the advantages of having a structured data repository is that we'll be able to organize wiki-text pages from all of the wikis that subscribe to it, allowing us to create machine-readable and machine-relatable pages for Internetbots like Googlebot and Bingbot to read. However, there are numerous more advantages. --  Joseph  TB  CT  CA   21:17, 24 January 2022 (UTC)
 * 1) Right off the bat I have a few concerns with this tbh; they range a few sectors. One is the fact that Commons for what it is, has very muted effectiveness. Not the best example. The second, the sheer variety of Miraheze data. Only certain niches of wikis would really benefit from this approach, and others might be better suited to developing their own Base. The third, the ambiguous and frankly problematic nature of ancillary wikis for Miraheze as it is; each one of them operates below where they should be in extension of the first point, and I would be uncomfortable in adding another before resolving the existing lineup in making a suitable baseline for the idea. Unfortunately I'm not sure there's much that a drafting stage for this proposal could do to remedy my thinking on this. --Raidarr (talk) 21:29, 24 January 2022 (UTC)
 * Your second concern is definitely gonna be addressed, maybe twas because users have refused to understand that this is still a draft and many areas haven't been addressed yet, so that is the reason you are raising the second concern. But let me throw a little light in that direction; It will be designed or organised in a way that no niche of wiki would be left behind, and for "and others might be better suited to developing their own Base." - This project would not by any chance be a must for wikis to subscribe to it, I mean, following our Wiki Statistics, approximately 97% of our over 5200 wikis do not have a Wikibase Repository, so you can see there are many wikis out there that might just be interested. Third concern; "Each one of them operatess operates below where they should be in extension of the first point" - I so much doubt if that is the case here, unless something has been tried out, I wonder how we'd be so sure that it's going to "operates below where" it "should be in extension of the first point". First concern; No matter how our Shared image repository looks like right now, it still function in a great way. This project is also going to enhance Miraheze Commons in such a way that we might have a way Images are also structured. For now, I think this would do. --   Joseph  TB  CT  CA   21:52, 24 January 2022 (UTC)

Proposal 1.1: Users' access and permissions
This proposal calls our attention to how users can access the content of the site. Using the same processes already in place in Meta (Nomination of RfP candidates, Requests for permission), A new group of such users should be elected.
 * Administrators and Property creators should be able to create and delete Properties
 * All the users with wiki connected to Miraheze Data as client wikis should be able to create Items;
 * All registered users on Miraheze should be able to add Statements to an item;
 * Any anonymous user should be able to browse.

Proposal 2: Electing users and creating non-default usergroups
Assuming Proposal 1 passes in the first place, This proposal calls for the election of users to be  on the Data wiki and also the creation of user groups that are not installed by default (including but not limited to Property creators and Translation sysops). Please share you view in the sub-sections of the proposal, below.

Proposal 2.1: Creation of user group
This proposal is based off the fact that we would be needing translation administrators on the wiki, because it is going to be a multi-language wiki just as Meta-Wiki is, hence we would need to use the Translation extension on the wiki. Wikibase itself is multilingual, although it doesn't require the translation extension, but we're talking about Wiki-text pages here, like pages in the Project, Template, MediaWiki namespaces can be translated using the Translation extension.

Proposal 2.2: Creation of user group
Because we'll be dealing with wikibase, we understand that not all users have a feasible understanding of handling wikibase properties and, by so doing, might not understand what is takes to create, so creating a special group for users who aren't sysops but can handle property creation would be necessary. This would help in a good administration of properties creation. This group should be called.