Tags update
Posted by Huw,Thank you all for adding tags to sets. There are now nearly 700 tags which have been applied some 7000 times. Most are good but a few are pretty much superfluous or duplicates so we'll be weeding them out in the next few days.
Unfortunately, they have had a detrimental impact on the performance of the main database stored procedure that retrieves set lists and some queries are taking over 10 seconds as a result; normally it's 1 or 2.
Update: I've had to disable the display and addition of tags because the SQL needed to retrieve them for use in set results is slowing the site down unacceptably, particularly at the weekend when it's under the most load.
Update: Tags are showing again. I'm going to monitor the database and if it appears to be okay, I will reinstate adding them in the morning.
0 likes
31 comments on this article
The entire site seems rather slow today.
Huw - can you give some examples of the "superfluous" tags? I did wonder about that myself, but, for example, "aircraft" =/= "airplane".
United States of America =/= USA
In my personal opinion, "USA" is better...
Yes, that sort of thing.
Definitely noticing the slowing down. Hopefully it can be resolved.
@bluemoose, I agree. It's hard to know what's superfluous when creating a tag.
Briefer, simpler tags are definitely better.
Is there a way to view all existing tags? Or maybe we need some sort of "tagging guide" with some rules set in place? Are some things not worth tagging, e.g. could you tag all HP sets with dementors with the tag "Dementors", or is that pointless?
Dementors is pointless because you've got this already.
http://brickset.com/sets/containing-minifig-hp046
The lag is not so great, but I have a GREAT idea about the tag feature after the lag is fixed. How about in your site preferences you can change it to only show your own tags, or all tags! It would be a good idea to consider. In the Bionicle section, someone made Carapar a tag! There has only been one version of him (unless you count the minifig). Without this suggested feature, tags can be pretty annoying. So what do you say HUW?
^
I
I
@Huw.
In themes with characters (Like Bionicle, Ninjago, Ultra Agents, etc.) do you think it would be worthwhile to add tags for all sets containing a certain character (like the above example), or do you think that is a bit too much?
It's a shame to hear that the tags are slowing the site down though.
@AT-AT: Good Idea!
@curious, Didn't even realise we had that, thanks!
It is flawed however, in that it makes a distinction between versions of the dementor, so it doesn't truly show you all sets which come with dementors (since they were updated in 2010).
@curious and @Albus--there are a lot of characters, across many themes, that have more than one minifigure. Even Yoda has at least two--and then there's the question of keyrings and magnets, too! I don't see why tags for at least the most important characters in a theme would be a bad thing--other than the current resource-chewing problems caused by the very existence of tags, of course!
Animal suit guys/Suit guys is another.
If you see tags for "X4," those actually do have a valid point. I have been tagging Space (and a few Castle)sets that have specific planets that they are portrayed as being on. Planet X4 is also known as the "prison planet," housing a large Space Police III facility. A list of all planet tags I made follows:
Krysto - Ice Planet 2002 Homeworld
X4 - Desert planet containing the Space Police Interstellar Supermax Correctional Facility(The Adventures of Clutch Powers)
Ashlar - ('Fantasy Era' castle planet from TAoCP)
Sector Six - A city/planet/space sector from Space Police III media.
I also tagged sets containing members of the Black Hole Gang, but as factions/organizations are not as important to LEGO Space as they are to Star Wars, I understand if this tag is removed. However, if Chima tags like "Wolf" or "Lion" stay, then I would make the argument that it should stay also.
I think it would be handy to set up the tagging system to automatically reject tags that are words that are already in the name of a set. Let's face it; if a set with race cars already has the word "race" in the name, then it will show up in the results of a search for "race," so adding that tag would be redundant.
Last night I added the tag "baseplate" to the sets that are supplemental sets that only contain baseplate parts. Some of those sets have "building plate" in their name, so they wouldn't show up in a search for "baseplate." Other supplemental baseplate sets actually have the word "baseplate" in their name, so there was no need to add that tag to those sets. Then today I notice that someone has added the tag "baseplate" to those sets that already have that word in their name.
Sigh...
I guess I don't understand the purpose of these tags? When I search, I go to themes and find the set I needed to look at. I haven't had any issues and I haven't noticed it takes me any longer to do it.
Maybe I'm wrong, but I don't see myself using tags anytime in the future. Is there a way to turn them off?
I'm with you Sethro3. I was more than happy with my search technique and can find all the relevant information that I want to use. Everyone has their own idea of what tag they want but it'll never match all of the Brickset users needs.
@Sethro3
There are some groupings of sets that exist across different themes, a hierarchical structure can never truly capture groupings and similarities. Tags are the only way to capture more complicated relationships. Presumably the sets you are interested in exist within a single theme but this is not always the case and perhaps there are some sets you are unaware of that exist outside the theme you collect that you'd consider related.
@sklamb
Perhaps tags for minifigures to group them would be a good start and then some way to return all sets containing minifigures with that tag?
Sorry for this dumb question but how can I add a tag to set ?
It's been temporarily disabled while I sort out some database issues which came to light when the number of tags grew and the site got busy. I've resolved it now and adding tags will be reinstated tomorrow morning.
I didn't comment on the main article about tags, but I did have an idea regarding tags which came up while I was in a PM to CapnRex101, so I thought it'd make sense to repost it here rather than it remain between me and him (sorry if someone else has suggested it already, I haven't really read the main article comments!)
If you want to potentially reduce the number of superfluous and pointless tags being added, I suggest having a trusted taggers scheme (a bit like the trusted reviewers scheme here?), where certain people can have tags approved immediately, but everyone else has to wait for their tags to be moderated. Trusted taggers can include all the staff and anyone that at least one of the staff knows would be a sensible tagger. Anyone else is added on possible request or upon recognition of submitting consistently good tags with no pointless ones.
I should add I'm not a person who would use or add tags all that often (it's why I haven't read the main article in much depth), but I would like to see them being put to good use rather than having the tags system abused by presumably the minority.
@curious--that sounds like a simpler plan than tagging each set with all its characters, I agree!
But in general, I can definitely see wanting, for example, to pull up all the Ninjago sets containing the many different variations of Lord Garmadon/Sensei Garmadon. For people who aren't accustomed to formulating queries for a database, tags are a very easy way to accomplish something like that.
Of course, everything depends on how many resources tags actually chew up. There may be better ways to allocate limited resources, I understand. But *if* they don't take up much space and can be made to work efficiently, I don't see why people shouldn't put in all the tags they think they'd find useful. (Provided people who don't find the tags useful can also turn them off, I suppose.)
PS--for what it's worth, I didn't actually notice anything unusually slow with the site's front page this morning; if anything, it was faster than usual for me (meaning my connection was better than usual, I suspect).
@TheOneVeyronian, that does sound like the best way to do it but it does complicate it somewhat. If abuse becomes an issue, though (which it doesn't seem to have so far) I will definitely do something along those lines.
@Huw
You are right, no need to introduce such a system until someone abuses it. Superfluous and pointless tags can be removed as they are right now, but you never know when a particularly malicious person will pop along and abuse the tagging system for no good reason.
No need to create extra work for moderators unless the need arises, I say :-)
Another way I suppose would be to stop known bad taggers (not saying there are any of course!) from submitting more tags, but I think that would cause more problems than it would solve.
Sounds like a job for an index and a lookup table! Depends on how it was implemented though.
It's fully normalised, a table of tags and a many-many table between tags and sets. That's part of the problem because when retrieving the sets I need to get the list of tags associated with the set, rather than the joined tables as you would normally.
I used the XML path method here, http://www.sqlmatters.com/Articles/Converting%20row%20values%20in%20a%20table%20to%20a%20single%20concatenated%20string.aspx , to convert the child records to a concatenated string which worked a treat but slowed down considerably when the number of records increased.
I've now had to un-normalise it slightly for the sake of performance.
If it's a major load-time drag perhaps the tag list could be loaded asynchronously after the main list? I know that's more work but it could leverage the same code you already have working so nicely.
I am loving seeing the tags and it's great to have so much tagged so quickly by this great community.
^^ spooky, I found out about FOR XML yesterday when fixing things at work (someone had introduced it and forgot that it would actually encode the data). MS specific, but works quite well, much faster than using a cursor and without the overhead of a pivot table.
Could maybe keep tags in a map in memory, reading out tag IDs then doing a lookup to string? Would cut down the data being passed around by SQL (and hopefully keep below the magic 8KB page size) but might actually end up slower as the IDs are converted to varchar for the xml stuff then has to go through a lookup table before being rendered.
@bluemoose, @huw with regard to "aircraft" and "aeroplane", there is a slight difference which some may not be aware of: an "aircraft" is any flying machine, such as airplane, helicopter or airship, whereas an "aeroplane" is specifically a fixed-wing aircraft.
My suggestion would be to remove the "aircraft" tag and replace it with "aeroplane" or "helicopter" as appropriate.
@NickMoss - sorry, that was my point. "aircraft" and "airplane" don't have the same meaning. As you say, "airplane" is an example of "aircraft", but so are "airship", "hot air ballon", "gyrocopter", "rotordyne", etc. I don't think either should be removed.
I'd argue that we should keep both - a set with a glider in should be ragged with "glider", "airplane" and "aircraft"; a set with an airliner in should be an "airliner", "airplane" and "aircraft"; set with an airship in should be an "airship" & "aircraft"; a set with a hot air balloon in should be tagged with "hot air balloon" and "aircraft"; and so on.
I wish to add "polybag" tag because even though packaging mentioned polybag but it is not helping when I seach polybag