Skip to end of metadata
Go to start of metadata

Forum Spec

Description of the Forum.docx

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

 

 

http://www.researchspace.org/_/rsrc/1281867900825/home/annotate.jpg

 

 

“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.      

 

Specific Example

 

A research project wishes to examine some of the works of a particular artist. Data about some of the paintings is held by two organisations that wish to collaborate and share their information. Other organisations also hold relevant data that would provide an important contribution to the research. The two main institutions store structured data in different database systems and export their data to the RS data repository. Data access and security rights are agreed and configured. One researcher starts a discussion thread on a particular painting. By using a search tool the researcher can quickly identify where information is lacking and can initiate group activity to help improve the data. The particular dataset under examination can be identified through a search link or can be imported into the discussion workspace for others to see and comment on.
 

http://www.researchspace.org/_/rsrc/1281975808513/researchspace-concepts/researchspace-requirements-practical-vision-and-supporting-notes/rstools.jpg

 

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

Code Reference

RS Stage

Description

 

 

 

The forum system should adhere to all the normal features of a discussion forum. On selection the additional features  available beyond this specification will be (if not simply part of the software as is) considered for inclusion. 

 

 

 

Permissions

 

Create a category – The ability to create a forum category

Delete a category  - The ability to delete a forum (would delete all forums)

Create a forum -  The ability to create a forum (research question/objective)

Delete a forum – The ability to delete a forum (deleted forums would be archived rather than deleted)

Write to a forum – The ability to post topics and reply to others in a given forum

Read a forum – The ability to read other peoples posts but not contribute (but use the data basket)

 

 

 

It should be possible for Project lead or administrator to configure these security settings.

 

 

 

Data basket

 

It must be possible to insert items from the data basket but also take items from the forum into the data basket.

 

 

 

 

The forum environment should allow the embedding of multimedia assets.

 

 

 

 

 

The forum should allow a user to launch other tools from an uncommitted  post and then come back to the post as it was left to either submit it (with or without further editing) or cancel it. This should be in a structured format that can be exported if required.

 

 

 

Linking & Launching

 

It must be possible to use links left by others to launch tools and areas in the ResearchSpace environment which load a particular state. E.g. a search result, or a particular image or data annotation.

 

 

 

 

The system should have the core functionality of a standard forum system and ideally be a third party product that can be slotted into ResearchSpace.

 

 

 

 

 

Notification of new messages – a user can configure for individual forums whether new messages are posted to them by email. (from their registry entry)

 

 

 

Messages can be removed by the project lead or assigned user.

 

 

 

 

Messages have their own titles provided by the user posting the message.

 

 

 

 

A user can get a list of their own posts (or others posts) and view these independently.

 

 

 

 

The forum should say who is online and a chat tool provided for off-forum messages

 

 

 

 

It should be possible to create reports that identify items placed in a forum through the data basket and those inserted manually by the user.

 

 

 

 

A user can tag a reply with a particular project forum keyword. This tags can be picked up by the system for use in other areas of the system and in particular the dashboards.

 

For example, a post could be a request for an action. This can be tagged as an “Action”.

 

A reply to the post and be tagged as “Action Accepted”.

 

The dashboards for the users will record the fact that one user has assigned a task (identified by the title of the post that set it) and in the accepting users dashboard as a task “to do”.

 

It should be clear to other users of the system that an action has been set and has been accepted.

 

 

 

 

The project should be able to configure addition terms to go with an Action tag so that the nature of the action is recorded and known.

 

e.g.

ACTION: Research

ACTION: Analysis

ACTION: Proposed Research Question (This would appear on the Project Administrators Dashboard

 

ACTION: etc

 

 

It should be possible to attach documents to a post, like a word document, pdf, image etc. that can be opened.

 

 

 

 

 

Project Administrators Dashboard

 

The Project managers dashboard will display information in summary about the types of post that are entered by way of the tags used. The Project administrator should have a quick way of browsing ACTION posts and entering an automated post to approve or reject proposed actions and state a reason.

 

 

 

 

It should be possible to configure the menu within the post dialogue box with addition tools as they come along and are installed on the researchspace system. This would require a registration system for ResearchSpace tools .

 

 

 

It must be possible to bookmark a forum post that is saved in your databasket.

 

 

Sorting and  Filtering

 

It should be possible to filter on the following;

 

·        User

·        Tag

·        Embedded Link Type (eg. (links that for a particular tool or ResearchSpace area)

·        Date

 

It should be possible to sort by user, date

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Forum Workflow Addition

[Forum tagging v03.docx]

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. 

User Help

The use of tags should provide some user help. The use of a question tag should provide some instruction as a how to form the question and the information that should be provided (in the post narrative area). This help dissappears whern the user starts typing their post. A similar mechanism should be employed with an action and with responses to actions. For example, a prompt for a full description of completed work, or a reason for rejection, or why an assigned action is incomplete.

Filtering 

The filtering mechaism within the forum should be able to show different types of post according to their tag, users that have been assigned to active action posts (so that a user can see all action posts that have been assigned to them) the ability to add a date range filter, as well as filter by the other different tags.

For example,

1.       A user wshes to know what action posts have been assgned to them in the last 7 days.

2.       A user wishes to know what actions posts have been assigned to them that have been completed or closed. (or for which they have provided a completed answer).

3.       A user wishes to see all the question posts.

4.       A user wishes to see all question posts for which they provided an answer.

5.       A user wishes to filter in a similar way but for other users.

The status of a post is also displayed on its header and/or in the summary of the forum.

While the dashboard shows all the actions and questions that have been set and assigned within the forums, users can set the dashboard summary to show only those items that relate to them like a personal to do list.  

Dashboard

The dashboard representation of the forum’s is action based although actions should be capable of being filtered by forum and forum category. In the dashboard the list of questions and actions would look at follows;

Type

Description

Assigned

Date

Due Date

Forum

Status

Activity Type

The subject of the question or action taken from the post topic or subject header (links to the post)

The person(s) the work is assigned to. (Should be able to re-assign from this column (drop down)

Of post

(modifications should be recorded and displayed)

The date the question or action is due. Should be colour coded or icon denoting whether overdue

The forum in which the post was made (links to forum)

The current status of the activity. This can be modified from here in terms of closing the activity. A tool tip should give more information with activities that have been assigned to more than one person. Ie status for each person

 

Example 1  - Question

A user starts a topic in a forum. The topic is a question which is typed in as a subject. For example,

“Do the brush strokes on <a painting> indicate that this was from the the Rembrandt school”

The post is tagged as a “question” and in the forum the subject and post type are indicated. The user then types a fuller description and background for the question in the main body of the post. As a tagged post it is reflected on the project activity board. Another user sees the item and clicks on it to go to the post entry. They then provide an answer. Other users may do the same thing and the Project Activity board would record the number of replies. When the initiator is satisfied they will changed the status of the item to ‘completed’ either on the project activity board or in the post itself.


Example 2 - Action

A post which sets an action to do some analysis on the brush strokes of Rembrandt would set a tag of ‘action’, a due date (if so wished – this should not be mandatory) and potentially set one or more users by selecting them for a list. The narrative of the post itself should describe the work required. A user may reply with a general post asking for more information and the original post can be edited to provide more information (the modification date should be noted in the forum summary and also indicated in the dashboard as updated. The action may be assigned to multiple users but instead of creating a separate post for all assignees the details of the assignment are simply described in the post (help is prompted). If the action is not assigned then it is an open action and users can choose to accept the open action. If only one person accepts then the action operates as a singularly assigned action. If more than one then it operates as a multi-assigned action. Assigned actions will also require an accept reply and this should also give the assignee the opportunity to ask for more information. An action with multiple assignee will remain ‘open’ until all assignees have accepted or rejected the action. An initiator can remove an assignee from the list by editing th original post. The summary should show which assignees have accepted the action using an indicator next to their name. Users should be able to choose whether questions and actions assigned to them should be emailed to them.

 

C:\Users\Dominic\Documents\bmwork\balsamiq\forums.png


Summary

1.       The forum is the central hub of the environment.

2.       It support the same general type of post used in any other forum but will also support a more defined topic. (Action and Question)

3.       A special type of post uses a predefined label or ‘tag’.

4.       Posts are surfaced on a project dashboard.

5.       The forums support normal sorting and filtering but with extended ‘tag’ metadata.

6.       The forum system would make use of the open annotation schema.

7.       A formal ‘question’ tag can be used to ask a specific question.

8.       A reply tagged as an ‘answer’ should provide a direct and more formal reply to a question.

9.       The question initiator can tag an answer as a “accepted answer”.

10.   The status of a post can be viewed and tracked.

11.   A question or action post can also assign a due date.

12.   Action posts can be assigned to multiple users.

13.   The dashboard summary links to the forum and the posts.

 

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.