One of the core elements of the academic collaboratory at NYU, that will be based off of Sakai 3 will be a tool we're referring to as Sociable, a personal and community resource tagging and synchronized metadata management application. It will be a core element, not just because of the social tagging functionality, which is a fundamental Web 2.0 feature set, but because it will be one of the means of resolving the user experience and managing permissions for the retrieval and sharing of resources within Sakai that have been pulled from multiple repositories (see also the documentation pertaining to External Groups Management.
Sociable User Features
Sociable provides each user with a central storage location for a recordof any resource (websites, pdfs, images, bibliographic entries in library databases, datasets, discussion threads, Sakai site pages, blog posts, etc.) that he/she has located among the multiple institutional repositories available or from the Internet.
This tool will support:
- tagging and management of almost any type of resource (books, websites, bibliographic entries, blog posts, datasets, and more)
- use of a single application to conduct personal management of various resources across repositories
- personal and shared tags
- community groups for the sharing of tags
- "expert" tagging identifiers
- importing of metadata based on pre-created templates for resources that were added from centralized repositories
- creation of personal metadata templates
- aggregation of non-synchronized metadata from disparate systems into common collections
- the use of tagging and metadata to retrieve files and resources when sharing within Sakai site pages, blog entries, discussion threads, etc.
- the use of tagging and metadata to locate and share the same files and resources within other platforms (not just Sakai), such as an enterprise CMS, Drupal, Confluence, etc.
Possibilities have also been identified in other uses of social tagging systems, and will be extended by an academic environment that is not siloed by media or resource types, or organizational goals.
Intended Audience
The audience for this tool is faculty, students and researchers.
Multiple Repository Tie-ins Overview
NYU will has several repositories scheduled for integration within Sakai. However, NYU does not expect to have a 1:1 integration (i.e., full functionality replication between systems such as file upload, metadata creation, full system searches, slideshow creation, etc.) with all of the repositories and licensed databases that will be made readily available within Sakai. In addition, since many of these media files will be retrieved again and again, by multiple users, we wish to avoid any scenarios in which files are "copied" to other repositories or directories as a means of managing the inherent file retrieval and permissions issues.
NYU will instead focus on Sociable as the primary means of managing the user experience between multiple repositories and Sakai.
The Sociable tool will not store any resource itself, but will instead store and point to a durable URI of the resource, separating the metadata from the storage. Sakai would then use the URI to point to a resource when it is embedded/linked within a content page in Sakai--or a user could choose to point to the Sociable record instead. For example, a user locating a resource using the federated search tool Primo could add this resource to Sociable. Then within Sakai that user could retrieve and embed that resource within a site page using the Sociable tool:
It should be noted that NYU is not making the assumption that K2's JCR will be that store of the metadata and records for searching and tagging. Instead, NYU will conduct an analysis of the various open-source tagging and resource management tools that are available, and select the most appropriate tool to tightly integrate with Sakai. However, Sociable will serve as a system of record for a person's resources, indexing that materials that have been selected by faculty and students for easy retrieval, but avoiding the need for federated search and retrieval mechanisms within Sakai; thereby allowing each repository or applicable search tool to more aptly manage these types of user experiences. NYU will use groups external to Sakai to control access between the systems. See External Groups documentation for more details.
The full user experience has not been resolved. However, in general, a user will first add a record to Sociable from the various repositories so they are available through the searching and tagging abilities within Sakai. For any content that a user wishes to in repositories, but which he/she does not have already have record for in Sociable, that user would be guided through to an interface to the appropriate search and retrieval tools needed (e.g., Primo), and once found the user could then add to Sociable.
Argument for a non-Sakai Sociable in Sakai
At NYU it is believed that Sociable should be very tightly integrated with, but should always be independent of, any repository or system. First, by freeing the metadata from the file storage allows for the aggregation of an individual's or a group's research and data, which currently often ends up siloed in different systems (e.g., tags and personal data about video collections are on one server, books and library materials on another, archive records on another, and so on). This aggregated metadata in Sociable can be harvested for analysis.
Secondly, since Sociable will be independent of any system it can also integrate with NYU's other content sharing applications such as Confluece, ifBook, its central CMS tool, and Media Commons (based on Drupal). This allows faculty and students to use one tool to manage, access and share their resources.
Third, it is believed that having a tool like Sociable exist independent of Sakai that it will be potentially easier to integrate all of the repositories with Sociable, rather than every repository needing its own integration with Sakai.
In addition, identifying a tool that already does much of the tagging and resource management functionality that users expect has two perceived benefits: 1) the Sakai community doesn't have to spend resources creating this functionality; 2) another open-source community, in addition to the Sakai community would be vested in the development of new features and functionality within such a tool.