Forum:Semantic MediaWiki

From the RuneScape Wiki, the wiki for all things RuneScape
Jump to: navigation, search
Forums: Yew Grove > Semantic MediaWiki
Archive
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 18 August 2011 by Cook Me Plox.

After talking it over with some friends and Wikia staff, I am proposing that we install the Semantic MediaWiki extension. This is a fairly radical change to our information system, and one that needs to be met with a great amount of commitment for it to succeed. However, if we manage to integrate Semantic MediaWiki onto our site, the benefits are astounding and unlimited.

Because this is a slightly complicated extension with new syntax, I am asking everyone who comments on this thread to read the manual. If that’s not an option, at the very least take a look at the introduction. Nothing pisses me off more than people making comments or asking questions that could have been answered by reading the simplest documentation.

I should also add that Wikia will install this extension on request, as can be seen on [[w:c:naruto]], [[w:c:familypedia]] and [[w:c:psychology]]. It is normally installed on [[w:c:yugioh]] but there were some technical problems in the last week there. DaNASCAT works for Wikia and specializes in Semantic MediaWiki.

Overview[edit source]

To put it plainly, Semantic MediaWiki (abbreviated SMW) helps to convert information that people can read into information that templates and applications can read. On the Iron platebody page, it says:

Level 33 Smithing is required to forge it from 5 iron bars, using a hammer on an anvil, which grants 125 Smithing experience.

Any person can easily discern the values given in that sentence, but the numbers on it can’t be used anywhere else because it doesn’t define them as anything. What’s at the core of SMW is that it can define values on articles and use them elsewhere in a meaningful manner.

Which format to use?[edit source]

There are two ways to define values using SMW: in-text and using templates. Note that both can be used at the same time.

In-text properties are written…inside the text. Looking at that earlier sentence about the iron platebody, the way to define the values there would be:

Level [[smithing level::33]] [[Smithing]] is required to forge it from [[bars needed::5]] [[iron bars]], using a hammer on an anvil, which grants [[smithing experience::125]] Smithing [[experience]].

As you can see, this is a bit messy, gets in the way of regular editing and can easily be removed on accident. That’s why I prefer option 2, templates. At the bottom of the page, we can put what I like to call a ghost template. It doesn’t do anything or show up on the page, but it defines the values.

{{SMW template|smithing level=33|bars needed=5|smithing experience=125}}

I find that this is a lot cleaner than the in-text properties. Note also that infoboxes use this same feature, which is why their parameters can easily be made into properties and used in SMW queries.

#ask and #show[edit source]

Please take a look at this as you read this section.

#ask is how you show multiple results in SMW. It can give tables or lists. You can define what pages you want it to show and what values it will return for each result. We can use this for making tables and databases.

#show is how you display a single result. This is what we’ll use for calculators, guides, and most other applications of SMW on our wiki.

To be clear, for the most part this will not be used from one article to another; we will still define lots of things statically from page to page, and this is mostly for use in non-article pages (guides, calculators, tables, lists).

This is all just a primer for those of you too lazy to read the manual, for which this is no substitute. If you are at all interested in helping out with this colossal project (assuming this passes), please read the user manual in full. There’s lots of cool stuff I didn’t mention.

What changes here[edit source]

  • Templates – Lots of new information at the bottom of the page, used inside templates. These should not cause any problems for anybody, and will not be on all or even most pages. They will only show up when the infoboxes do not suffice in displaying information SMW can read.
  • Namespaces – There will be two new namespaces added with SMW: Property and Concept. Property is used to define the properties (read: parameters) that are used across the SMW. Concept is similar to categories except more complex. Read the manual if you care.
  • Special pages – There will be a few assorted new special pages related to SMW and the properties. These can be ignored if you want.

I have been told that SMW has very little, if any, effect on the load time of pages. Should be a non-issue. Vandalism of SMW pages and templates should be very easy to deal with; very few of the users will even know about the different templates and namespaces. We can also set up AbuseFilters for when the ghost templates at the bottom of pages get changed.

Semantic Forms[edit source]

Note that this entire section is optional. Another thing we can use is the Semantic Forms extension, to make calculators. It’s actually sort of similar to User:Quarenon/Scripts/Calc, but in my opinion much better as it doesn’t make use of #switches (which makes it load faster and time out less) and can use semantic tables. This extension creates a new namespace called “Form”, which is similar in use to what you’d find on a calculator page for Calculators/Servant cost or any other JavaScript calculator.

The downside is that all of the calculators have to be on a subpage of Special:RunQuery, and we can’t make very good use of redirects or transclusions of special pages. Do you think that’s worth it?

Another possible application of Semantic Forms would be to make pages with infoboxes editable through forms: see this for an example. There are a lot of cool things that can be done using the forms; it's similar to RTE but it's completely bug-less. Keep in mind that it's not at all necessary to use the form editing if we don't want to.

Some possible uses[edit source]

  • Super-dynamic alchemy calculator – Replacing the cumbersome DPL + category setup we use to generate a list of profitable high-alchemy items. We can filter the list to members or free-to-play, and let people define a maximum loss or minimum profit.
  • Use XP values, levels and costs to make calculator creation easier – If we define the skill levels, experience granted, and items required to perform a certain task (Smithing an iron platebody), we can make calculator creation a breeze so that all that information doesn’t have to be found over again. It can be completely dynamic and based on categories.
  • Create actual databases of items or characters or NPCs by pulling infobox data – This would be an interesting task – to create databases based on the names, levels, membership, et cetera…we could make them searchable using the calculator script and maybe put them in their own namespace. It’s all possible, but it’s a project for another day. This can also replace Bestiary, which right now is unconnected to anything else and freakishly out of date.
  • Create lists of monsters, armour, quests based on superlatives or user input – This is what SMW was built for. We can make lists from already-existing templates of the best or highest-leveled things, or just about anything from the parameters on infoboxes (including {{Infobox Bonuses}}). We could also let the user decide what parameters they want to see in the list.
  • Make training guides dynamic and efficient based on what is written on the relevant article – From the information on the articles (experience, location, level) we can make creation and rewriting of training guides much easier, using dynamic parameters.
  • Use Grand Exchange prices and number-per-hour parameters from articles to create self-updating money making guides with better information – Similar to the previous example, we can use the dynamic Grand Exchange prices and number-per-hour information on the articles themselves so that the guides are more accurate and more useful. We can also automatically hide methods that make less than a certain amount of money per hour or are marked as obsolete elsewhere.
  • Quest map based on quest and skill requirements, user input to show lists of possible quests – This will be a complicated task. Using parameters at the bottom of quest pages, we can automate a bunch of things, from the “Required for Completing” section to Quest experience rewards and the list of the highest skill requirements. A more ambitious goal would be to create a map of the available quests based on users’ levels and completed quests. That might be beyond our ability. We’ll see.
  • Use in other applications with RDF and CSV exporting – Not too sure about this one. Apparently it makes it possible for people to export the information for use in programs outside the wiki.
  • Better file-to-page meshing through names (similar to Inventory license) – I guess this one’s mostly for me. With the licensing I’ve been doing that links up file pages and their respective articles, this can make a table of the two of them, making it easier to find the picture you’re searching for.
  • More organized disambiguations and otheruses – We can use the properties to make disambigs more organized and listed. This one’s sort of low-priority.
  • Item comparison - We can get rid of the JavaScript item comparison code and replace it with some annotations and #ask queries.
  • Create lists of references - Based on the parameters in the Cite templates, we can use concepts to order them by date, type, page, reference...anything.

There are tons of other applications for SMW on our wiki. Pretty much anything that involves lists of stats or values can be created using it. Feel free to add things to this list.

Proposal[edit source]

Semantic MediaWiki[edit source]

  • Install the Semantic MediaWiki extension
  • Create the Property, Type and Concept namespaces
  • Start the use of ghost templates at the bottom of pages to define semantic information in a way that can be used by other pages and templates
  • Port help pages and other information onto the wiki

Semantic Forms[edit source]

This extension we can take or leave. I like it, but it does have some problems as mentioned above.

  • Replace the calculator script with Semantic Forms, using Special:RunQuery
  • Create the Form namespace

This would be a huge change to how we store information on the wiki, and would require work from multiple people to make it feasible. I don't think it would be a stretch to say that this would be the biggest structural change to our wiki that we've ever had. If we don’t have the time or energy to do this, it could turn into a mess that nobody wants to clean up. However, if this is something we are willing to do as a community, it could be an enormous accomplishment that would help us for years to come. Are we ready to take things to the next level? ʞooɔ 04:19, August 5, 2011 (UTC)

Discussion[edit source]

Support - Yes. ʞooɔ 21:58, August 7, 2011 (UTC)

Support - Why not? Ts4kNfA.png 04:24, August 5, 2011 (UTC)

Support - Seems like things would be a bit easier and a bit cleaner. --Touhou FTW 04:34, August 5, 2011 (UTC)

Comment Support - Seems like a good idea, my only fear is that it may be too complex to throw upon so many other editors, not to mention we have a lot of pages that would need to all use this to be useful (eg, a monster database isn't much use if only 1/2 of the pages are compatible, at that time). Hofmic Talk 04:36, August 5, 2011 (UTC)

I think everyone is scared of Semantic MediaWiki because it seems really complicated (I didn't really help that with my enormous proposal), but in all honesty it's not difficult to learn. I'm really not that great with advanced wiki coding and I found it to be a piece of cake to figure out. If you understand basic templates, categories and tables, this sort of thing comes naturally. If you don't understand those things, fortunately it's pretty easy to ignore all of the code on pages if you don't want to learn it.
As for the number of pages needed for this to be useful -- most of the information already exists on the wiki and will not have to be altered very much. We can use the {{Infobox Monster}} almost whole for the database, and the same goes for items, locations and anything else with an infobox. The stuff that is not defined yet can wait, and it should not take all that long to make it work; until it is completed we can hold off on even creating the databases. ʞooɔ 04:43, August 5, 2011 (UTC)
It was more of the random editors who just want to fix a typo, but would get daunted when they can't find it in a page of alien like code I was worrying about. I'm very good at these kind of things myself, but past experiences found that others aren't always the same. But if you're confident that others won't get lost, count me as supportive. Hofmic Talk 03:04, August 7, 2011 (UTC)

Support - Sure, we could always use these improvements :) S T Y G 05:24, August 5, 2011 (UTC)

Support - Only if there's assistance learning the tools. I can see how this will help us greatly. Sheep chathead.png DumuzidSheep chathead.png 06:19, August 5, 2011 (UTC)

Have you read the manual? That should be enough assistance. If it is not you could probably ask an user who uses it more often for help, but like cook said in his 2nd paragraph, please read the manual before asking such things. JOEYTJE50TALKpull my finger 08:45, August 5, 2011 (UTC)
If anyone has taken a look and is unable to figure out the syntax, I'd be happy to help them. ʞooɔ 09:00, August 5, 2011 (UTC)

Strong support - Not only will this make many tasks easier, it also adds a vast range of new capabilities that we can harness to better provide information to our readers. I have some reservations about Semantic Forms, however, as they are restrictive in the locations calculators can be placed. But they do have advantages, as Cook outlined, as they will reduce server load and errors by making use of less #switches as well as simplify the editing of certain pages using editing forms, which I must say is more brilliant than any of the WYSIWYG editors Wikia has been churning out bugs with. 222 talk 07:12, August 5, 2011 (UTC)

Oppose - tl;dr Strong support - Per nom. Many improvements, nearly no downsides. bad_fetustalk 13:33, August 5, 2011 (UTC)

Support all - Excellent addition; I'm impressed. Though we won't be able to redirect to special pages, we can link to them. The syntax doesn't look complicated at all either, and the wide range of new functions makes this highly appealing. It's going to take a while to have this used on the majority of pages, but with a few dedicated users, it shouldn't be much of a problem at all. Suppa chuppa Talk 00:02, August 6, 2011 (UTC)

We could probably make an index of all the pages that would have needed a redirect, to make it easier to find them. JOEYTJE50TALKpull my finger 10:09, August 6, 2011 (UTC)

Support - doesn't seem too complicated, lots of benefits. HaloTalk 01:34, August 7, 2011 (UTC)

Strong support - Yes. Matt (t) 02:14, August 7, 2011 (UTC)

Quantum Support - I'd love to get this and learn how to use it. Also, as per your asking, I'd be more than willing to help you with whatever you need. Adam SavageTalk 03:24, August 7, 2011 (UTC)

Extreme bukkit support - Been wanting this for a while, and I would be glad to help set it up too :-) ajr 21:50, August 7, 2011 (UTC)

Support - This kind of thing is great for this type of wiki 76.230.213.213 23:48, August 7, 2011 (UTC)

Phase II[edit source]

Alright, it looks like there's enough support to go to round two on this. I would encourage all of you, if you haven't already, to read up on the extension. What we need to do now is brainstorm ideas for for properties. These are the things that we define values by; in the examples in my original proposal, those are "smithing level", "bars needed", and "smithing experience". Anything (not necessarily a number) that can be defined and used elsewhere on the wiki. This is something I would like us to organize and figure out BEFORE the extension is installed. If you have ideas for properties, feel free to add them here. If there is little or no participation in this section, I will take it as an indication of the community's future involvement in this project and just close this. ʞooɔ 02:58, August 10, 2011 (UTC)

Comment - Obviously, the there has to be 25 level parameters, one for each skill. I'd recommend that instead of "smithing level" we use "level smithing" or something that puts level first (for organizational purposes so that the level parameters are next to each other in a list of all the parameters). The same applies to the experience parameters.

For your "bars needed" parameter, I think it might be better if we generalize it a bit more into something like "materials needed" so that we don't need a new parameter for each different type of supply.

Sorting by skills, here are some parameters that I think would behoove the pages that relate to them.

All skills: experience per hour (for pages that have something to do with training)

Construction: room(s) that the item can be built in

Fishing: type of fishing spot (lure, bait, net, cage, harpoon), equipment needed (fishing pole, feathers, bait, nets, et cetera)

I'll add more in as I think of them. --LiquidTalk 14:56, August 11, 2011 (UTC)

Obviously, the there has to be 25 level parameters
User:Liquidhelium

Suppa chuppa Talk 15:20, August 12, 2011 (UTC)

-.- I do not claim to be perfect. --LiquidTalk 18:49, August 15, 2011 (UTC)

Question - How would we go about putting properties in infoboxes? Matt (t) 21:31, August 11, 2011 (UTC)

Closed - While there's obviously enough support to close this successfully, the lack of participation from all but two people in the brainstorming part of this thread shows me that not enough people are interested in actually helping. Seeing as two or three people cannot possibly implement this extension in a quick and orderly fashion, I am closing this as unsuccessful. ʞooɔ 01:03, August 18, 2011 (UTC)