ResearchSpace Forum Specification

Author: Dominic Oldman

Date: 2 nd September 2012

Introduction

Overall Description & Use Story

In ResearchSpace a user would first arrive at a dashboard after login and could go straight to using a research tool - particularly if they are finishing some work from a previous session. However, in the main it is expected that most users will navigate to the project forums from the Dashboard which will show latest progress, activity and other project information.

Each project can host forums within a category defined by the project. Within a category forums that reflect research questions or objectives are established by the Project lead or a person with rights to establish a new forum. Some users will have rights to create a forum in any category while others only in some or not at all. Some users will only have access to some forums and others may only have read access.

A user with full access to a forum will use it in the same way as any other forum. The user can initiate topics of conversation and reply to other topic initiated by other users.  The main difference between a normal forum and a ResearchSpace forum is that users can, while engaging with the forum launch other tools and use the data basket to take things out of the forum and to copy and embed things into it. This allows users to display content from the ResearchSpace repositories within the forum, but also provide links that will allow forum users to launch the tools from which the content was taken and examine the content in context. For example, a user may embed a link to an image annotation allowing a user to use it and see the annotation in the context of the image annotation tool and other annotations.

User can also promote annotations to forums as new topics.

At the end of activity on a particular forum the users can run reports and sort and filter the content by dates, users, embedded data and pure forum text.

User should also be able to embed other objects from their own resources, e.g. multimedia files outside ResearchSpace, which can be viewed or heard within the forum.

Forum Structure

Structure should be similar to any standard forum (and third party software is expected to be used).

Category :               A Category of forum defined by the project

Forum:                             An area defined by a research question or a research objective in which users can post information, questions and engage in a discussion

Topic :                             An item or thread related to the forum subject

Reply:                             A reply to a topic.

User Security

By default the categories and forum subjects (research questions) are defined by the Project Lead / Administrator but this right can be given to other users within the project. The facility to create a category and initiate a forum should be available on the user’s dashboard.

A user may have a right to create a category, a forum and/ or post a topic within a forum. These rights can be configured per forum and other users may also be given read only access.

Exiting Requirements

Forum and collaboration requirements have been written about in various documents and elements of these documents are reproduced below.

ResearchSpace Requirements – Practical Vision and Supporting Notes, Dominic Oldman.

Available at http://www.researchspace.org/researchspace-concepts/researchspace-requirements-practical-vision-and-supporting-notes

“Example Use Case

When all these elements are brought together they form a powerful environment for collaborative scholarly research. Collaboration applications would have access to data and digital assets that can be utilised into a shared working space to support and generate group activity. This activity can be specifically directed by the use of workflow tools that can be configured, if required, to provide structure and control to a particular process. In addition, research tools would be available from within a collaborative application so that users can access them directly. Data from the RS repository would inform group activity and the results would be saved to inform other ongoing activities or contribute towards conclusions. This work can then be brought together to form the basis of more formal publication.      

As the discussion continues, the researchers record some formal annotations against the data. They can do this by using an annotation tool available directly within the forum. The annotations are recorded with the researcher’s identity for attribution purposes and are available to other researchers who search and view the data, and who can record their own annotations should they wish.      

The other contributing organisations do not hold their data in a structured format but use the RS gateway interface to input their information manually. As data comes into RS from other organisations, the RS system will inform the members of the research group prompting further examination and searching, perhaps to reveal any new significant links between the existing and new data. Where semantic relationships are not found by the system, researchers can create their own links and relationships and annotate these links to explain their significance.  

As more information is generated missing metadata can be entered against the object records according to a pre-defined workflow system that ensures proper sign off by content owners. This data will be recorded as having been created within RS, or if it cannot be agreed, will be assigned another appropriate status.

The discussion forum will also provide direct access to image manipulation tools. Users can select images imported or uploaded to the project and add metadata, or again create annotations. These image tools can extend to providing comparison functionality allowing annotation of images that have been overlayed, perhaps a normal image and an x-ray.   Links to this work can be embedded into the discussion so that others can view the annotations using the same view as the original researcher.

All the embedded links can be grouped and arranged in particular ways to provide other researchers with an insight into the steps taken to analyse the data. To ensure that users do not have to trawl through an entire discussion they can use a search tool, or run a report, to bring required elements together in a more structured way.

Where changes to original data sources have been agreed, authorised institutions can choose to update their own local systems with the new information. However, RS would keep a copy of previous versions of the data.

From ResearchSpace Business Requirements and Specification, Dominic Oldman              

At para 8.2.2

Messages from other project users should be viewable. A simple user interface will be provided to

allow a non-technical user to set these questions. By default, although a social networking component

may be included in the project, the Project Administrator is the only person who can initiate a discussion or blog unless otherwise configured. Therefore the Project Administrator can initiate all discussions and questions or allow other members of the team to initiate them also.

At para 21.1

Introduction

It is currently envisaged that ResearchSpace will use social networking tools already available with the selected content management system. The social networking tools are the hub of the ResearchSpace environment forming the basis of collaborative discussion with links out to documents, assets and data. This means that the architecture must facilitate interfaces with the different data and administrative components. Some of these may already be inherent within existing CMS functionality.

At para 21.2

Component Location

Social networking tools are applications within the CMS system.

At para 21.3 - Interfaces

1. The ResearchSpace toolbar - providing navigation application launch capability

2. The RS Data Basket – a mechanism for managing data to and from the social networking tools.

3. The Research Tools – which are launched from the CMS environment and which interface with the CMS environment through the data basket.

4. Navigation to other ResearchSpace components.

5. Reporting engines for reporting activity.

6. Search Engine (searching within active social networks)

7. Through hyperlinks (used to link and locate data, documents and assets and as parameters for

launching Research tools).

8. Dashboard

Views / Screen Reporting

·       Activity by User Account – posts, data entries and annotations made by each project member

·       Activity by User Account – Detail. Showing all the entries made

·       Links back to the entry in context. A filter should also include publication status.

·       Activity per component or discussion thread. A filter view of all the inputs per collaboration

·       tool.

Social Networking Tools

At 4.2.1

ResearchSpace objectives mean that when posts (contributions) are made within a social networking

tool, the information should be stored in the RDF store if that information enriches the store of

cultural heritage data and information stored there. This means that, even when scholars are contributing to a general discussion, they should have the opportunity of saving their post as anannotation with the appropriate associations or relationships in the RDF store. By default, CMS tools only store data in the CMS database and therefore some work would be required to support this alternative commitment of data.

The Discussion Topics are defined by the Project Administrator on the Forum Administration Dashboard. Each thread corresponds to a Research Question; therefore some threads will automatically be created from the Project Administrator’s page where different Research Questions-Threads are defined. Other new threads can be added by the Project Administrator from the dashboard. A specific thread entitled “Project Questions and Aims” is a forum Discussion Topic which will be added by default.

The forum menu should show a list of form topics arranged in Discussions, and include a forum search button Discussions should also be tagged using tags defined by the project administrator on the project administrator dashboard. It should be possible to sort discussions and filter them on the basis of date and tags.

Sub-discussions related to set Research questions (main Discussion) would be defined by users from the Forum menu. To add a sub thread, users would click on the Discussion Topic and this would open up another Tab of threads. A button “Add a new related discussion.” When adding a related discussion, a title and free text description, and tags would be necessary.

When responding to any thread, there are various options-tags:

Reply/Assign a task/New Research Question/New Related Discussion

When Reply is clicked, a new text screen is opened and the user adds free text-images-links-etc, and by clicking “save”, the entry is added to the Forum Thread

When “Assign a task” button is clicked, the user adds a description of the new task, and clicks “save”. The entry is saved on the forum and colour coded.

At this point the Discussion Entry is added to the Project Administrators Page of “tasks which require approval” . The Administrator can then review and edit the task if necessary, and then do one of the following: assign or respond to (i.e. not assign) the request. The task can be assigned to the project, to a particular institution or to a particular person. After it is assigned it will appear on the Project “list of tasks” page, and on the personal or institutional dashboard, and a description of the assignment will be added to the Forum entry indicating the date of the task, the title of the task, a link to the task on the project page, and the person-group assigned to carry out the task. If the task instead is not approved, the Project manager will add a comment to the task indicating a free text comment or  reason for the task not being approved and this comment will follow the thread. The task will not be added to the Project dashboard.

ResearchSpace Forum Concepts

Action tags

ResearchSpace introduces the concept of tags related to workflow. While researchers collaborate within the forum workspace their posts may have a particular significance to the project. In particular they may propose a new action within the Forum. This could be for additional research, some analysis, a new research question that has opened up as a result of a discussing and so on. These “Action” tags  

Assumptions

It is envisaged that a suitable open source third party forum system will be incorporated into ResearchSpace.

Functional items

RS Forums – Simple Workflows (additional to Forum specification)

Author : Dominic Oldman

Version: 0.3

Date: 13 nov 2013

Concepts

The bulletin board system within ResearchSpace is the cental hub of the environment. This is because it is organised around the project’s research questions that are central to the project. The ResearchSpace project will have categories of question that are declared as forums, and within those forums the research question can be explored through a range of different topics (or subjects). A ResearchSpace forum will support the same general type of post used in any other forum but will also support a more defined topic, like a formal question or a request for some activity to take place.

This special type of post uses a predefined label or ‘tag’ which has significance to the project in terms of requiring some response or action. These posts are surfaced on a project dashboard for other team members who can click on the item as a link to the original post. Users can also see tagged posts within the forum itself and reply as normal. These tagged posts can be filtered so that different types are displayed for rapid response. For example, you can see what open ‘action’ posts exist or ones assigned to a particular user. Information about these workflows can therefore be seen through normal sorting and filtering of forums; through a summary on the dashboard; or through reporting (reporting is not covered in this document).

Technical Assumption

The forum system would make use of the same open annotation schema used for the annotation tools. The only different would be that the posts are annotating a subject (Research Question). The RDF constructs will, at their core, be the same but with some added elements to support the additional workflow functionality.  

Tags

It is proposed that the number of tags be kept as low as possible.

The following tags are allowed:

For a new Post

1.       General (Default)

2.       Question

3.       Action

4.       Action Type

5.       Completed (as an initiator edit)

6.       Closed (as an initiator edit)

For a Reply

7.       Answer

8.       Completed

9.       Accepted

10.   Rejected

Questions and Actions

A Question

A formal ‘question’ tag can be used to ask a specific question of the other members of the research team. This is different from a general post which could be just a comment, part of an ongoing discussion or other useful information. It also denotes the need for a more formal answer. A reply to a question post can still be a ‘general’ post but users can also tag their reply as an ‘answer’ and try to provide a direct and more formal answer – in which case they would use an ‘Answer’ tag. The project dasboard would reflect the summary view within the forum but is only concerned with special tagged posts – not general posts. In the dashboard the number of answers to a question are displayed. The question initiator can tag an answer as a “accepted answer” at which point the question is closed for the purposes of the dashboard. A question initiator can accept more than one answer but only one accepted answer is enough for change the status of the post. A question can be closed without an accepted answer by the Project Lead or the initiator of the question.

An Action

An ‘action’ tag signifies a request for some activity to happen. Again, an action post is recorded on the dashboard and provides a link to the post. An action post can be assigned or unassigned – and left open for anyone to pickup. An assigned post provides the ability for one or more people to be assigned the task. An assignee must reply to the action post with an ‘Accepted’ or ‘Rejected’ tag. These posts might ask for additional information or give a reason why the work cannot be undertaken. On completion the assignee will reply with a ‘Completed’ tag post and, if necessary, provide additional information. Replies to any post are by default general replies. However, the system should always prompt the user and ask whether an answer, completed or rejected tag should be applied on saving the reply post. In this way users do not have to remember to set the tag before posting. For example, a reply to a post assigning the user should prompt to set an ‘Accepted’ tag. A reply to an assigned job that has been accepted should prompt for a ‘Completed’ tag (Has the action been completed?).

An action that has been rejected by an assignee is either given a status of closed if only one person was assigned (until it is assigned again) or the action will continue as normal with the other assignees.

The dashboard will record the action and its status. The status of an action is:

·       Open,

·       Assigned,

·       Completed,

·       Closed.

An open action is one that has been posted but not assigned. An assigned action is one that has been assigned but not completed. A completed action is one that where the assignee or, if multiple assignees, all assignees have replied with a completed post. A closed action is one which has been closed by the initiator or by the Project lead. The dashboard should be available to the initiator for closing a question or action.     

A question or action post can also assign a due date. When the due date is exceeded this is reflected on the foum summary along with the due date information. This could be achieved using colour coding. The number of days to the due date should also be shown and, in the cas e of an action post past its due date, the number of exceeded days.