Intro to TagTeam

From Harvard Open Access Project
Jump to navigation Jump to search

General

  • To create an account on the Harvard instance of TagTeam, just go to the front page, click "log in" at the upper right corner, and sign up.
    • Once you do, you may create TagTeam "hubs" or projects. You may always tag items for your own hubs, but you may only tag items for other hubs with the approval of the hub owner.

Background

  • 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 other tagging platforms. Throughout development, we have been 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 free participants in the same social-tagging project to tag from the platforms of their choice. OATP started on Connotea (defunct since March 2013) but didn't want to limit project participants to Connotea or any other single platform. We call this feature, interoperable tagging.
    • To allow user-defined tags on the input side to evolve into a standard vocabulary on the output side, under the control of project managers. 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. We call this feature, folksonomy in, ontology out.
    • To weed out duplicates in the output feeds. If one purpose of an output feed is alerting 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. We want to allow social-tagging projects to support tagging from any interested users but also to block identified spam and spammers.

Features

TagTeam is a versatile, open-source, social-tagging platform and feed aggregator. It allows the members of a research project to tag online resources (articles, books, datasets, news stories, and so on) in order to organize knowledge in the field and alert readers to new developments. Other tagging platforms already offer rudimentary versions of these services. TagTeam goes further by allowing user-defined tags or folksonomies to evolve into standard vocabularies or ontologies under the direction of project managers. TagTeam eliminates duplicates from output feeds, enables project managers to eliminate spam, and frees participants in crowd-sourced, tag-based research projects from the need to agree on a common tagging platform.

From another point of view, TagTeam is a mashup engine for social-tagging projects. It can integrate the tags and tag feeds from multiple tagging platforms. After making its own copies of these tag records, it supports many kinds of targeted modification and combination. Then it publishes outputs in standard formats, like XML, for further mashups by other projects. At the same time, it stores all the tag records to which it subscribes, and added by users, for flexible, boolean searching.

  • 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 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.
    • For example, if some members of a research project use Delicious, some use CiteULike, and some use TagTeam itself, and if they agree on a common tag for project-related resources, then TagTeam can publish a unified feed of all the the items they tag with that tag, regardless of the tagging platform they used. If members of the project 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 or CiteULike. It generates RSS, Atom, and JSONP feeds for each of its tags. Other services online can easily convert these to Twitter or email feeds.
  • It supports both automated and manual modification of input feeds, feed items, and item tags. All modifications of both kinds show up in searches and output feeds.
    • Automated filtering allows a project to convert deprecated tags to approved tags. 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 and B, and the other with tags B and C, then TagTeam will store and publish only one record of the item, with tags A, B, and C.
  • 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 their hub, 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. The search engine supports boolean searching, phrase searching, wildcard searching, and fuzzy 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.