Wikidata site for Brickimedia

[georgebarnick]

A Wikidata-like website on the Brickimedia network could be something that would make various things easier across our projects. Here are some examples of uses for a Wikidata-like project on Brickimedia:

• Global LEGO set data on projects as we open them in more languages (set number, prices, piece count, etc)
• Global statistics for CUUSOO projects and users (Automatically get number votes for a LEGO Ideas project #223)
• Would allow for language links to be more-easily added in a central location

Further uses could be integrated. Having a Wikidata-like project on the Brickimedia network would serve useful especially when we open Brickipedia projects in non-English languages.

[Ajraddatz]

I'm Adrian and I approve this message.

[adamrobcarter]

How would this tie in with our projects? Would the data be transcluded onto normal pages?

[SirComputer1]

Brickidata. Perfect. I think it would work.

[georgebarnick]

@UltrasonicNXT: I don't know. However WikiData does it for the Wikimedia projects it serves.

@SirComputer1:
[1:43:39 AM] George Barnick: I guess Brickidata since that's basically our creative capacity
[1:43:42 AM] Adrian: brickidata, like the unoriginal hacks we are

[adamrobcarter]

Er, you don't know?! All I can see WikiData doing is language links, so I can't see this being worth the effort right now... Maybe if we had lots of language wikis, but seeing as we don't right now, I don't see much of the point personally

[georgebarnick]

• WikiData phase 1
• WikiData phase 2
• WikiData phase 3

Phase 2 of WikiData would be most useful. If we had Brickipedia projects in multiple languages, they'd all have the same infobox/set information. Set numbers, prices, piece count, recommended age, parent theme, number of minifigures and all those other data values don't change between languages, so it'd be a waste of effort to keep those data values up to date across all projects. It's exactly the same reason why WikiData even exists. Ajr and I have talked about this a lot. It's worthwhile and would make everything easier in the long run.

"Maybe if we had lots of language wikis, but seeing as we don't right now, I don't see much of the point personally"
So we'd choose to start a WikiData project late instead of sooner? So basically, we'll have more work and be farther behind when we do already have language wikis? Having a WikiData project before we open language wikis would make things a hell of a lot easier to keep up to date. Opening up a WikiData project after we have several other language wikis would mean that our WikiData project would be behind on its needed work. We already have enough wikis that are behind in their subject area. We should try doing things sooner than later for a change.

[adamrobcarter]

Ok, yeah, I take your points. Would this mean replacing Semantic MW then?

[georgebarnick]

I don't think it would be needed. We only use SMW on en.brickimedia really, and we'd still use it for things like Theme Tables and stuff. I don't think WikiData would have any bad effects on SMW, and if it does we can work it out when that time comes. First we have to get a working data.brickimedia site before integrating it with the current projects.

[adamrobcarter]

Wouldn't this make it a lot harder for newcomers to add piece counts or whatever? They'd have to find a link to data.bm, then find the set they're after, and then finally edit it. Seems a lot harder than just adding it to the template and SMW doing the rest...

[georgebarnick]

I don't really think so, but honestly Brickipedia is lacking in help pages for many things. A basic help page for that would be more useful.

It could even make adding piece counts even easier, because, for example if someone from de.brickimedia (hypothetical site) added the set data to data.brickimedia, all that someone at en.brickimedia would have to do to get the set information is just make sure that the en.brickimedia page is associated with the same data.brickimedia property as the de.brickimedia page is associated with.

[NovaFlare]

hmm... I think it would be several years before this wiki actually became useful, but I guess we may as well start now. @NXT- agreed, adding piececounts does make this seem way overcomplicated. What I'd suggest for the infoboxes is having for the piece field (as well as most of the others):

{{#if:{{{Pieces|}}}|{{{Pieces}}}|{{#property:Pieces|{{PAGENAME}}}}}}

That way people can just add the part number in as normal, because realistically the casual editor would not go to great lengths just to add in a three digit number (it seems like a huge pain even to me, but I can understand how it could be useful). I definitely think we should keep SMW though, some things won't need SMW as much with this, but it would still have benefits in other areas that this site won't provide for.

Actually, as I'm trying this, I realise this wiki could solve another problem I've been meaning to raise on en: part pages and inventories. Would there be a way to set something up on this site so inventories can be automatically generated based upon an appearances section on a part page? At the moment, we're doing both part and inventory pages, which is double the work we should be doing.

[georgebarnick]

@NovaFlare: Such a thing could probably be engineered. Most likely it would involve a bot that would scan for changes to parts pages' appearances sections, and when something new was added/removed, it would adjust the property on data.brickimedia. This could make generating inventories much faster, and we could introduce inventories in other languages, since on the English Brickipedia currently does inventories.

[kingcjc95]

I'm not Adrian, but still support this message.

[Edward-Nigma]

This definitely sounds ideal. Sounds a bit hard to make, but doesn't seem that hard to use.

[adamrobcarter]

@georgebarnick how would you write such a bot? I don't think I could...

[georgebarnick]

@UltrasonicNXT: I'm not sure right now. I'd have to be able to work with a live installation to test it. I'm also sure there would be people who could help engineer something for that if I can't. I can already think of how it would function in my head, but I'd need to have data.brickimedia working so I could figure out how it would be programmed.

[georgebarnick]

Brickidata is running experimentally at http://data.brickimedia.org right now. For it to operate properly, we'll need to be running MediaWiki 1.23 (we're currently on 1.22.3). We'll likely be upgrading to either snapshot 1.23wmf16 or 1.23wmf17 tomorrow, in which the site should operate properly. From there, we'll see what else needs to be installed. I've been installing each thing manually, but to make things easier it may be best to uninstall what I've already done and to just let composer install it.

This site still won't be launched for several months approximately. What can be done now though is templates for users such as welcomes, warnings, and others, as well as pages like help pages. Brickidata will need a lot of help pages since this is new to most of our editors, and they'd need guides on how to use Brickidata. I know @NovaFlare has done a good job with templates on other wikis; maybe he wants to/could do some for Brickidata. Not many people know too much about how Wikidata works, so maybe @Ajraddatz and I could work on help pages. Others who want to help could look at Wikidata's help pages and write similar pages for Brickidata. We're also going to need a main page design. @NovaFlare did the other projects' main pages (most of them), so maybe he'd want to do Brickidata's too? I might take a swing at designing the main page too. I'll probably outline some important details of the main page on its talk page at Brickidata later this evening.

[georgebarnick]

Brickidata is now running on both a stable extension version and stable MediaWiki version with no bugs yet (which is great that nothing has to be modified to support Refreshed). I'll work on touching up some Wikimedia-specific things if I can.

Something we're going to need is a bot to add all of enbricki's stuff to Brickidata, like what was done when Wikidata was launched. @Ajraddatz, can you maybe find who was responsible for that bot and see if they'd be able to help us get stuff in a place where such a bot could be run on Brickimedia? I don't know many people at Wikidata so I'm not sure who to go to.

[adamrobcarter]

Before we worry about importing en's data, we need to have some test data up, so we can see if we actually like the way it works or not, and what we want to use it for. There's no point bothering about importing en's data if we find it makes it so hard to edit infoboxes that we won't use it. We need to test first.

[georgebarnick]

Do you want me to set up testdata.brickimedia.org?

[adamrobcarter]

Wait, a project just for testing?! No, I'm just saying before we import en's data, we need to just put a little bit of data up, so we can test how it works.

[georgebarnick]

You act as if a testing site is an outrageous idea........ Explain dev.brickimedia.org and test.wikidata.org. We have at least one page on Brickidata right now. That's as much as we need to test how it works. It works fine on the repository. Before we start using the clients though, we need all of the clients' content imported to the repository....

[adamrobcarter]

I'm not saying testing is an outrageous idea, I'm advocating it. I'm saying we need to test how data can be transcluded from data. to en. (and other places). One page will do fine, if you can show me a page on en. showing how the data is transcluded (or how ever else you're getting the data to en).

[georgebarnick]

Setting up the wikibase client on enbricki is something that has to come after the repository is set up. If you're not familiar, Wikibase is two things:

• Repository - Where the data is
• Client - Where the data is used

Setting up Wikibase Client on enbricki is something that we can't do yet since the repository isn't ready to serve content (and an import has to take place before it can).

[adamrobcarter]

Why don't we have a repository with just a little bit of test data in it? The Brikipedia comminuty needs to be able to see how the infobox data is transcluded from data.bm (or how ever it works) before it decides whether or not it wants to host in the infobox data on data.bm instead of en.

[neoncitylights]

Superseded by https://phabricator.wikimedia.org/T151431