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, volunteers should be selected by most active users showing real interest in creating quality items. All administrators and property creators should take responsibilities of creating Properties, while, of course, Items should be editable by all the registered users, unless they're protected. Finally Administrators (This comprises of interested Meta admins and volunteers who becomes Sysop) should be in charge of adding new sites and enable SiteLinks to allow Direct Access feature. A clear process should be defined on how a wiki request access to the Data instance, so the administrator can add the site to the configuration. Documentation should be produced to explain wiki owners how to configure the Wikibase Client extension to access the Repository.


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

Discussions/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)
 * 1) .Do you plan to open this today, ? --YellowFrogger  ( talk ) ( ✔ ) 01:58, 5 February 2022 (UTC)
 * Probably by Monday or before. --  Joseph  TB  CT  CA   02:03, 5 February 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: Creating non-default usergroups
Assuming Proposal 1 passes in the first place, This proposal calls for the creation of user groups that are not installed by default (including but not limited to Property creators and Translation sysops user groups). Please share your view in the sub-sections of the proposal, below.

Proposal 2.1: Creation of user group
This proposal is based on the fact that we will need translation administrators on the wiki because it will be a multi-language wiki, similar to Meta-Wiki, and thus we will need to use the Translation extension on the wiki. Wikibase is multilingual, though it does not require the translation extension, but we're talking about Wiki-text pages here, which can be translated using the Translation extension, such as pages in the Project, Template, and MediaWiki namespaces.

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.

Proposal 2.3: Creation of user group
Translation administrators user group would be needed since we'd be dealing with a multilingual wiki, the creation of this group would help specific users to translate wikitext pages into different languages. This would help welcome users of different languages to the wiki, especially users who doesn't understand English language.

Proposal 3: Election of core group members
This proposal calls for the election of users to be  on the Data wiki. Please share your view in the sub-sections of the proposal, below.

Proposal 3.1: Electing Administrators
Administrators are more like house keepers, they handle tons of tasks on a particular community. This proposal calls for the election of system operators (administrators) who will keep the community; this includes the Wikibase aspect and the Community aspect of the wiki, just like every other wiki needs administration. As proposed above, Sysops should be able to create properties ( right) and of course, performs other house keeping and cleaning. Meta sysops are already exempted, it now depends on if they're interested (Note: This exemption is for the meantime, that is, after the creation of the wiki, after the project begins proper, they (Meta admins) will no longer be exempted.) The proposers (Ugochimobi and Lucamauri) aren't exempted from this election. The same processes used in Local Meta Elections should be used to elect the admins (i.e. Nominations and Requests for permissions).

Proposal 3.2: Electing Property Creators
Assuming Proposal 2.2 passes; Property creators are users who aren't system operators but are well knowledgeable in wikibase, these knowledge has to be demonstrated either on the Datawiki or a Miraheze wiki that uses Wikibase or even Wikidata. A simplier process can be used to elect Property creators. Proposed criteria are; Proven knowledgeability in wikibase, added a reasonable amount of statements to a particular item or property. Any Mirahezian can request for it or be nominated.

Proposal 3.3: Electing Translation Administrators
Assuming proposal 2.3 passes, this proposal calls for the election of translationadmins; User who will be able to translate wikitext pages. Per original creation proposal, This will help users who doesn't understand English language perfectly well to be able to interact with the wiki.