Tracking project tags

This list is part of the Open Access Directory.

• This list is still under development. Every part of it may change before the official launch, including its title, URL, and method of organization.

• Related pages in OAD:
  • OA tracking project (public)
  • OA tracking project (private notes)

---

Tags

Project tags

• Topic tag = oa.oa
  • Use this tag when you don't know or don't care what subtopic tags to use.
• Subtopic tags = oa.article, oa.book, oa.comment (covers blog posts), oa.data, oa.digitization, oa.event, oa.journal, oa.license, oa.negative (for setbacks, obstacles, opposition), oa.policy, oa.psi, oa.repository, oa.tool, oa.wiki
  • Use these tags to classify OA developments.

Non-project tags

• Things: oa.audio, oa.blog (for blogs themselves, not individual posts), oa.conversion, oa.copyright, oa.cost (not price), oa.database, oa.declaration, oa.developing, oa.etds, oa.fee, oa.funder (for a funder action), oa.green, oa.gold, oa.gratis, oa.hybrid, oa.images, oa.legislation (both proposed and adopted legislation), oa.library (for actions by libraries or librarians), oa.libre, oa.music, oa.mashup, oa.measurement, oa.multimedia, oa.museum, oa.oad (for items to add to the OAD), oa.oer, oa.p2p, oa.patent, oa.peer_review, oa.presentation, oa.preservation, oa.price (not cost), oa.privacy, oa.project, oa.publisher, oa.repository.institutional, oa.repository.disciplinary, oa.repository.data, oa.retroactive, oa.service, oa.software, oa.standard, oa.students, oa.study (for results of surveys and other empirical research into OA), oa.terminology, oa.textbooks (special category of books), oa.university (for a university action), oa.video.
• Dates: oa.2008, oa.2009, etc.; also oa.jan.2009, oa.feb.2009, etc.; but NOT oa.3.feb.2009, oa.4.feb.2009 etc.
• Fields: oa.anthropology, oa.biology, oa.chemistry, etc.; also oa.stm (science, technology, medicine), oa.ssh (social sciences and humanities), oa.humanities
• Institutions (major only): oa.nih,
• Languages: oa.arabic, oa.bosnian, oa.chinese, etc.
• Nations: oa.argentina, oa.brazil, oa.canada, etc.; also oa.africa, oa.asia, etc.

About these tags

• Format:
  • Start with "oa."; all in English; all lower-case; no spaces; no plurals.
  • Minimize the use of phrases, as opposed to single words; but when we do use them, use the underscore char in place of spaces, e.g. "oa.peer_review".
  • For date tags, month names reduced to first three letters; no day-of-month tags.

• There should be as many of these as needed to cover the field; but not so many that project participants might not be able to remember them all. If there were too many, participants would either consult a guide (slowing them down) or not consult a guide (increasing their error rate).

• For completeness, the full project feed also includes the pre-existing Connotea tags, "open access", "open-access", "openaccess", and "open_access".
  • These are not project tags. But by including them, there's no need for people who already use them to stop using them, and no need for subscribers to project feeds to miss out on the items so tagged.
  • Others in use for me to consider: ir, oa, plos, repository, repositories, etc.
    • It's hard to know how many others may be in use. (One reason to make all project tags start with "oa." is to make it easy to find them all, even if any search for them also brings up non-project tags with the same structure.)
  • At some later date, I may phase out support of these tags and limit the project feed to project tags. I welcome your thoughts on that.

Links

On the same wiki page listing the project tags, list the following links (probably in a table, with the project tags down the left column):

• Connotea page for each tag (page displaying items tagged with that tag)
• Connotea "community" page for each tag (wiki page describing the tag's purpose and scope)
• Connotea RSS feed for each tag
• Connotea RSS feed for all the project tags together
  • I'll need to revise this every time I add a project tag; hence, do it on a wiki page. Hence also: include a "last revised" date for the URL, as well as for the set of tags. \
  • Use some "push" method (like a discussion forum message) to send new url to interested subscribers?
• Instructions on how to build the link for an RSS feed for an arbitrary combination of tags (project tags and personal tags)

Tips

• It's more important to get relevant items into the combo feed than to classify them precisely by subtopic.
  • This is a reason to focus on large-scope tags and ignore fine-grained tags if you like. It's also a reason to keep the ontology fairly lean.

• You don't have to use subtopic tags if you don't want. The generic "oa.oa" tag will still put an item in the full project feed.
  • If you want an item to appear in the project feed, then you must use at least one project tag (or one of the legacy tags, see below). Hence, if you don't use the generic "oa.oa", you must use one of the official subtopic tags. If you also use unofficial subtopic tags, you help classify the item and aid rediscovery, at least for yourself. But if you use only unofficial tags, the item will not appear in the project feed.

• The "oa." prefix in project tags simply means that the tags belong to the OA tracking project, rather than to another one. Hence, for example, "oa.journal" is for any item about journals relevant to this project. It's not limited to items about OA journals. Likewise for "oa.policy", "oa.book" and so on.

• If a hot story erupts, it would be useful to give it a special tag. For example, the Conyers bill to repeal the NIH policy could be oa.conyers. But there's no reason to make these temporary tags into permanent project tags. They can be personal tags which follow the format of project tags. They can help relocate items with targeted searches.

• Connotea is not case sensitive about tags. If you've already used "oa.comment" and then tag an item with "OA.Comment", Connotea will convert the second tag to the form of the first.
  • PS: But what if a given user is new and hasn't already used "oa.comment". Would "OA.Comment" then be recorded with caps, and fail to bind with the "oa.comment" tags already in the system? Test this.

• If you use a subtopic tag, you needn't use the generic "oa.oa" tag as well. All subtopic tags put the item in the full set.

• If you choose to use date tags, remember that users an item tagged oa.feb.2009 will NOT come in a search for 2009 items unless it's also tagged oa.2009. You can use year tags without using month tags. But if you use month tags, then also use year tags.

• You needn't limit yourself to project tags. If you use personal tags as well, then you make certain items easier for you to find. You can use the project tools to create combo feeds of any subset of tags, including any combination of project and personal tags.
  • Your personal tags for OA-related content could (but of course needn't) follow the format of the project tags: "oa." followed by an identifier, all lower-case, no spaces. If you follow that format, then you leave the door open to propose it as a project tag. But even if you use a different format for your personal tags, don't forget that Connotea allows you to change a given tag to another, retroactively, for any items you tagged yourself.

• Note that Connotea allows you to change tag A to tag B, retroactively, for all the items you tagged with A. This is desirable when if discover, for example, that you've been using "oa.policies" instead of "oa.policy". Changing the tag name will then mean that items you tagged will make it into the feeds where you intended for them to appear.

Problems

The governance problem

• If we want an official set of project tags (so that we can have a "full set" project feed and search engine), then we'll need a way to agree on that set. Even apart from the inevitable quarrels, it's extra work for people.
• See the Models section of the main project page. Some models would not require a governance system.

The proliferation problem

• The number of project tags may grow so large that participants could remember them all without consulting the web page.
• It seems to me that the number is far more likely to grow than shrink.
• One solution is to remember that you can make feeds that combine project and personal tags. You needn't make all the tags of interest to you into official project tags. While true, I doubt that this would do much to reduce the pressure to add new subtopic tags.
• From one point of view, proliferation is a virtue, not a vice. It increases the freedom of users to track (subscribe to or search) just the subtopics they care about. Is there a way to see proliferation as all virtue and no vice? For example: participants don't have to remember the whole set of tags, just the tags for the subtopics they care about. Because they care about them, they're likely to remember them.

The rating problem

• The full set feed is likely to be too large for most people to read. One way to cut it down would be to create a combo feed with fewer subtopic feeds. But that would omit some subtopics. A better way would be to subscribe to all the subtopics, but support a filter based on user ratings. This would allow you to see all the tagged items above a certain rating.
• This is only a "problem" because Connotea doesn't support user ratings of tags or tagged items. We could drop Connote in favor of a service which does, and solve the problem.
  • Scintilla supports user votes/ratings. It's from NPG, like Connotea, which makes me wonder whether they can are or can be integrated to allow voting/rating of tagged items.
• Another solution: Connotea is open source and could be tweaked to support user ratings. It may come on its own or we could create the add ons we need.
• Another solution: Introduce tags like oa.1, oa.2, etc. Or simply introduce "oa.hot". If you'd trust user ratings of tagged items, then you should trust user ratings built into the tags. This is not as flexible as a true ratings system, but it's a makeshift we could implement while we wait for a true ratings system. (Why not as flexible? Any user who made an item oa.1 would put that item into the oa.1 feed, even if you and most others think it's unimportant or even irrelevant.)

The plural problem

• Should we include (for example) both "oa.repository" and "oa.repositories"?
  • If yes, then slightly more work for people to make combo feeds or search engines; they'd have to include both forms of each tag in order to assure good coverage
  • If no, then we'd have to educate participants so that they used the preferred form; bound to be mistakes
• Would be moot if we had a tool to automate the process of creating combo feeds and search engines from selected tags; we could include both forms of each tag without extra human labor and without educating users; users could use either form
• If our tagging system IS case sensitive, then we have a case problem to parallel the plural problem. For example, should we include both "oa.repository" and "OA.Repository"? (PS: Connotea is NOT case sensitive.)
• At the moment, I'm solving this problem by making all project tags singular (except "oa.humanities").

The old content problem

• While the primary purpose of a tracking project is to tag new developments, it can also be used to tag older developments in order to bring them within the scope of the tag classification system and the project search engines.
• The only drawback to tagging older items is that they will appear in the relevant tag feeds (for example, an older OA policy tagged with "oa.policy" will appear in that tag feed). Some feed subscribers might only want to hear about new developments. Tagging older items would greatly enlarge the "Full feed" --which is already likely to be too large for most people to read.
• One solution: introduce an "oa.old" tag, and allow users to use boolean logic to construct a combo feed (oa.policy AND NOT oa.old).
  • Weaknesses of this solution: different users will differ in what counts as old; many users who tag older items may forget to use the oa.old tag; all items will eventually deserve the oa.old tag; and Connotea has only implemented boolean logic and does not support NOT (hence can't search for oa.policy AND NOT oa.old).