Intro to TagTeam

From Harvard Open Access Project
Revision as of 15:44, 14 October 2012 by <bdi>WikiSysop</bdi> (talk | contribs) (Created page with "* Suggested short URL for this page = [] ----- {| align="right" | __TOC__ |} == General == * [http://tagteam.harvard.e...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search



  • The original idea behind TagTeam was to create a tool with the features needed by the Open Access Tracking Project (OATP) and not provided by any other tagging platform. Throughout development, we were very conscious that a tool with the features needed by OATP would be useful to social-tagging projects on any topic.
    • TagTeam is a general-purpose tool, and not OATP-specific. OATP users who want to make the transition to the TagTeam version of the project should see the OATP transition handout.
  • In addition to the standard features provided by most tagging platforms, we particularly wanted our tool...
    • To allow project participants to tag from the platforms of their choice (for example, Connotea, CiteULike, or Delicious). OATP started on Connotea but didn't want to limit project participants to Connotea or any other single platform.
    • To allow user-defined tags on the input side to evolve into a standard vocabulary on the output side. OATP wanted the benefits of user-defined tags, for encouraging participation, but it also wanted the benefits of a standard vocabulary, for searching and organizing a body of knowledge.
    • To weed out duplicates in the output feeds. If one purpose of an output feed is current awareness, or to alert readers to new developments, then duplicates in the feed are a bug, not a feature, and they annoy busy readers.
    • To allow project managers to control spam. OATP wanted to support tagging from any interested users but also to block identified spam and spammers.


TagTeam is open-source middleware designed to stand between social-tagging platforms, like Delicious or Connotea, and readers who subscribe to RSS feeds generated by those platforms. It also functions as a social-tagging platform in its own right, and an RSS/Atom/RDF aggregator. It allows a research community to tag articles, books, datasets, news stories, and other relevant web sites, in order to organize knowledge in the field and alert readers to new developments. Other tagging platforms themselves offer rudimentary versions of these services already. TagTeam goes further by combining user-defined tags or folksonomies on the input side with standard vocabularies or ontologies on the output side. It eliminates duplicates from output feeds, enables project managers to eliminate spam, and frees participants in common research projects from the need to agree on a common tagging platform. Finally, it publishes output feeds based on the arbitrary recombination of input feeds, and publishes output feeds for any tag or arbitrary combination of tags.

  • TagTeam supports any number of hubs or social-tagging projects. Each hub can subscribe to any number of input feeds and publish any number of output feeds.
  • It accepts input feeds from different tagging platforms, such as Delicious, Connotea, and CiteULike. It accepts inputs from any tagging platform that generates RSS or Atom feeds for its tags. It can accept these inputs either by subscribing to the tag feeds or by importing files of tag records.
  • It integrates tags created on different tagging platforms. We call this interoperable tagging.
    • For example, if some members of a research project use Delicious and some use CiteULike, and they agree on a common tag for project-related resources, then TagTeam can publish a unified feed of all the tagged items. If users agree on a set of common tags (a vocabulary or ontology), TagTeam can publish a set of unified feeds.
  • It supports tagging through its own bookmarklet, for users who prefer to tag directly from TagTeam rather than from a supported platform such as Delicious, Connotea, or CiteULike. It generates RSS and Atom feeds for each of its tags.
  • It supports both automated and manual modification of input feeds, feed items, and item tags. All modifications of both kinds are reflected in searches and output feeds.
    • Automated filtering allows a project to convert deprecated tags to approved tags, enabling projects to offer "folksonomy in" and "ontology out". Automated filters are both retroactive (changing all stored occurrences of a tag) and prospective (changing all future occurrences).
    • Manual filtering allows a project to delete spam, and to correct tagging mistakes too difficult to correct algorithmically.
  • It removes duplicate records from searches and output feeds, and merges the tags used in duplicate records.
    • For example, if two users tag the same item, one with tags A, B, and C, and the other with tags C, D, and E, then TagTeam will store and publish only one record of the item, with tags A, B, C, D, and E.
  • It supports user roles, allowing access to advanced features for some users and not others.
    • For example, other tagging platforms allow users modify their own tags retroactively, and only their own. Ordinary TagTeam users have the same power. But TagTeam hub owners (project managers) may modify any tags in that hub retroactively, and may use both automated and manual filtering to do so. This is an essential tool for creating tag convergence or developing a project ontology.
  • It stores all tag records in a local database for deduping, back-up, export, modification, and searching.
  • It allows different hubs to share input feeds, and allow different hubs to give different local names to the same feed.
  • It allows users to create output feeds out of any combination of input feeds.
  • It spiders or updates its input feeds often enough for its output feeds to provide useful real-time alerts. Hence it combines a prospective alert service with a retrospective knowledge-organization service.