Branch (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot) wrote2010-07-26 05:52 pm
branchandroot) wrote2010-07-26 05:52 pm
Entry tags:
Tagging and revelations
So, I've been meditating on the uses of tags-as-labels versus tags-as-indexing, in a fic archive. Have some thinking-out-loud sort of results.
Short form: The two uses are really not the same at all.
I, for example, have tended to use tags as labels. In this usage, they need to be clear, minimal and not redundant, which leads to, for example, not tagging with a character name when that name is already included in a pairing.
On the other hand, tagging to index calls for every last bit of information imaginable, and welcomes redundancy. After all, the tags are now supposed to make the story findable along multiple axes of search.
Using searchable tags for indexing makes all kinds of sense, and I am, in fact, banging on some code to add a whole bunch of searchables to my personal archive. But part of the banging involves actually hiding the tags in question most of the time, because index-tags should not all be shown in the story blurb/summary/whathaveyou. That's the place for labels, instead. Index-tags in a label-tag context are massive information overload, and the redundancy that makes them useful for indexing just makes them hard to wade through as labels.
This is one of the things that's bugged me about the AO3 tag implementation from the start, though I've only this week managed to articulate it. The problem there, of course, is that it would involve a Whole Lot Of Work to even begin to differentiate between index and label use; even if the interface was made to do it, most authors wouldn't want to bother; but they'd sure raise hell if someone did it for them! Which leaves only the separation of tags into different reading fields (for pairing, for character, for freeform), to ease the overload of ten to twenty tags on one story. This was abandoned once already, in design, presumably in favor of a more "light weight" blurb, but I think that was a mistake; and the compromise of highlighting the pairings really doesn't ameliorate the problem much. And, in response to this I suspect, a lot of people are not tagging their work nearly as comprehensively as it should be tagged for indexing purposes--from the reader side, the tags look like labels, after all.
It's like LOC subject headings. They're wonderfully useful to search with, if you're familiar with the nomenclature, but they're never shown in the mini-record you see in search results.
Short form: The two uses are really not the same at all.
I, for example, have tended to use tags as labels. In this usage, they need to be clear, minimal and not redundant, which leads to, for example, not tagging with a character name when that name is already included in a pairing.
On the other hand, tagging to index calls for every last bit of information imaginable, and welcomes redundancy. After all, the tags are now supposed to make the story findable along multiple axes of search.
Using searchable tags for indexing makes all kinds of sense, and I am, in fact, banging on some code to add a whole bunch of searchables to my personal archive. But part of the banging involves actually hiding the tags in question most of the time, because index-tags should not all be shown in the story blurb/summary/whathaveyou. That's the place for labels, instead. Index-tags in a label-tag context are massive information overload, and the redundancy that makes them useful for indexing just makes them hard to wade through as labels.
This is one of the things that's bugged me about the AO3 tag implementation from the start, though I've only this week managed to articulate it. The problem there, of course, is that it would involve a Whole Lot Of Work to even begin to differentiate between index and label use; even if the interface was made to do it, most authors wouldn't want to bother; but they'd sure raise hell if someone did it for them! Which leaves only the separation of tags into different reading fields (for pairing, for character, for freeform), to ease the overload of ten to twenty tags on one story. This was abandoned once already, in design, presumably in favor of a more "light weight" blurb, but I think that was a mistake; and the compromise of highlighting the pairings really doesn't ameliorate the problem much. And, in response to this I suspect, a lot of people are not tagging their work nearly as comprehensively as it should be tagged for indexing purposes--from the reader side, the tags look like labels, after all.
It's like LOC subject headings. They're wonderfully useful to search with, if you're familiar with the nomenclature, but they're never shown in the mini-record you see in search results.
no subject
Interesting distinction and thanks for the guided tour inside your brain.
no subject
no subject
Our iteration of LinkCat has two reports: sorted by search term, and one-screen-per-tangible-item.
http://www.scls.lib.wi.us/linkcat.html
When it was in the card catalog, it was on the cards. Now it's on the one-screen-per-tangible-item.
no subject
no subject
no subject
no subject
Seems to me that index-tags become useful where and when we don't have full-text searching; if you do have search capabilities through title, excerpt, and text, then you don't need index-tags. Alternately, you can produce index-tags for single-page archive ("see all stories with ___") but have a search function hiding behind there, sans index-tags.
Pretty much the same thing I've contemplated with labels and whatnot on Scimitar, but I draw the line at listing secondary characters... but sometimes I can see where it might not be that clear to another admin trying to follow along behind me. Do you mention characters in pairings for which the pairing never makes a true appearance, but is only referenced? Do you mention characters who are only in there for one scene (even if they're otherwise significant characters in the canonical story)?
And perhaps most importantly: if you list a lot of tags (genre, character, pairing, whatever) as a matter of course, will the lack of a tag turn people away from the story on the assumption that if that tag applied, it would be listed, instead of assuming that tags are non-inclusive?
It's that last one that bugs me, that to label a story thoroughly might be to give the impression that the labels constitute every possible applicable label and nothing beyond that. People get picky enough about what they read, and I don't like the notion that a solid archive is inadvertently assisting readers in being even pickier, possibly to their own detriment in missing some good stuff.
Okay, yes, I know I can't do anything about that, but it's the bookseller in me, coming out. I want a way to snag the readers I know who just might like a less-read story, if I could just shove the story in front of them and say: no, really, just give it a chance! ...and thus change their mind and introduce them to something new and awesome.
no subject
no subject
One thing that might be a help, actually, is if we can make it easier to make search include tags on bookmarks. So the author could label their work with label-tags, then either the author or someone else could bookmark the work with all the index-tags.
For a while, we actually hid some of the redundant tags, but then authors complained that we were hiding information they'd put there deliberately.
no subject
For a while, we actually hid some of the redundant tags, but then authors complained that we were hiding information they'd put there deliberately.
*can't help laughing* Yeah, and that's exactly why I don't think this has an easy solution for a big archive that does allow freeform author tagging. Everyone wants to do it their own way!
no subject