Digital content manager

Antti Moilanen

Introduction

Storing and retrieving digital contents can be time consuming task for user. Deciding to which category or a folder file should be stored can be hard decision and as a result from this,searching for the file can also be cumbersome.For solving this problem I’m planning and implementing digital content manager using software agents.

Let’s think about simple example where user is thinking should he save research article he wrote, while being exchange student in Japan, either to articles, or to Japan folder. Article folder has all his research articles and in Japan folder he has all material from the period he was in Japan. Let’s say he decided to save the file to article folder and after couple months he is looking for this article and thinks it should be in Japan folder but he soon finds out it isn’t. This being simple example he probably will realize to look from the article folder too and finds the article, but still nonetheless for a moment he wasn’t able to find the article.

Now let’s think system where software agents are helping him to store and retrieve the file. He selects the file, sets suitable keywords (metadata) for it, in this case Japan and article and after this lets system decide where to save the file. Now when he is searching the file he can just give which ever keyword (Japan or article) he happens to remember, and among the other files system will find with these keywords the article he is looking for will be found.

In this kind of simple situation it might seem like there isn’t need for this kind of digital content manager, but in real life much more complex file systems are used. In these situations deciding where to save files and especially where to look for them can take lot of time from people who already are busy at their work or just tired to always spend time for looking for the piece of information they need.

It also should be noted here that content manager using just basic keywords wouldn’t be sufficient when using more complex file system. Because of this, after the basic content manager using just keywords is implemented, there are plans to add more search options to make the searching more efficient. For example here is list of this kind of options:

  • Part of or full filename
  • Creation or last modification time of a file
  • Use of logical operator like ‘OR’ and ‘AND’

Construction

Thinking this kind of system we can clearly see three main parts, from which this system should consist of. First there should be some kind of interface which user can use while storing and retrieving files. For storing the file user should be able select the file which to store, way to set the keywords and also be able to get feedback from the system. When retrieving files we also need way to set the keywords and some way to show files that were found using these keywords.

After this we still need way to process request made by user, some part which decides where to save or where to look for these files, way to actually save and retrieve these files and their metadata (keywords) and also when retrieving file we have to combine information of all files found and send it to user interface. This seems little too much for just one component so lets divide it to two different parts.(This should be better explained both the tasks and the reason why it should be divided to two different parts, also kind of bad sentences there).

Firstly from the two other components we could have a manager which would work between the user interface and rest of the system. This being said, from the previously mentioned tasks, it at least has to process requests received from user interface and sum up information of files found and forward it to user interface. Manager could also take part when deciding where to save and look for files. For helping manager in this task we could also have category part which especially handles saving the keywords …(more should be added and previous part should be edited to better)

Thinking how this could be implemented as an agent system we have three types of agents:

  1. UI-agent which operates the user interface
  2. Manager-agent which is working between two user interface and rest of the system processing requests and information it receives. Basically like the name says it’s the manager of this file system.
  3. Category-agents which actually stores and retrieves files

Needed functionality when storing file

In this chapter is explained the needed functionality when storing filefor each agent and for the user interface in the first version of the system.

Manager-agent:

  1. Function to receive and process request

Takes file type from the filename and using this and keywords sends request to category-agents.

  1. Function to receive answer from category-agents

Collects answers (is agent suitable to store the file) from all category-agents.

  1. Function to process all answers and to decide which category-agents to send the file
  2. Function to receive and forward information when storing is done

Category-agent:

  1. Function to receive request and check suitability

Checks the given file-type and keywords and answers to manager-agent if this category is suitable for the file.

  1. Function to receive the file

Receives the file, stores it and after that informs manager-agent about it.

UI-agent:

  1. Function to receive request from the user interfaceand forward it to manager-agent
  2. Function to show result of storing the file

Receiving information from UI-agent concerning did storing succeed.

User interface (baseprocess of the UI agent):

  1. Function to read input from user and send it to UI-agent
  2. Function to display result concerning if storing succeed

Figure 1: Storing the file

Needed functionality when retrieving files

In this chapter is explained the needed functionality when retrieving files for each agent and for the user interface in the first version of the system.

Manager agent:

  1. Function to receive request and forward it

Retrieves the keywords from UI-agent and sends request to category-agents.

  1. Function to receive answer from category-agents

Receives list of suitable files found by category-agent

  1. Function to process all answers

Combines all received fie lists to one when all category-agents have answered.

  1. Function to send combined file list to UI-agent.

Category agent:

  1. Function to receive request and search suitable files

Searches for files using given keywords and sends list of suitable files to manager-agent

UI agent:

  1. Function to receive request from the user interface and forwards it to manager-agent
  2. Function to receive list of found files and forward it to user interface

User interface (baseprocess of the UI agent):

  1. Function to read input from user and send it to UI-agent
  2. Function to display list of found files to user

Figure 2: Retrieving the file

Implementation

First version of the system will include only functionality that’s necessary for the system to work. I started to work after having conversation with my academic advisor and using his comments and views on the topic I started by writing up what these necessary parts are and planning what functionality they have. Using these notes I made three different charts for the both storing file and for the retrieving files. After this I had conversation with my professor and now I’m going to make only one chart for storing the file and one for the retrieve. These will show better how user and different agents actually work together.

First implementation will have three different category agents:

  1. Documents

File types: .doc and .txt. Keywords: “school” and “research”

  1. Private documents

File types: .doc and .txt. Keywords: “private”

  1. Photographs

File types: .jpg and .gif. Keywords: “sendai”, “holiday”, “school” and “friends”

For the better results when testing if system is working or not, it’s important to have two categories with same file types and also categories with different file types but sharing some keywords.

Also even though current diagrams shows that files are actually stored some location, in the first version the category agents are just keeping list of files and what keywords there is attached to them. This makes implementing and testing the first version much faster and actual use of database for storing the files can be added later.

Example walkthroughs of the planned system

These two examples show only one category-agent because it’s the only one from the three that will accept request sent by manager-agent. Cases with other agents would look the same until category-agent answers to manager-agent that it can’t store the file or in the case of retrieving it send empty file list.

Functionality to implement in the future versions

It’s very likely that all of these are not implemented because they are just ideas that haven’t been thoroughly thought out yet. Also current list isn’t in priority order yet.

  1. Functionality to process different error situations and inform user about them
  2. Functionality to actually save the file to database and retrieve it from there
  3. Possibility to user select files he/she wants from the given file list when retrieving files
  4. Possibility to store multiple files at same time
  5. Use of “OR”, “AND” and other logistic operators when giving keywords
  6. Possibility to change filename when storing file if database already has file with same name and user wants to change current one
  7. Possibility to add author as a special keyword when storing file and use it when retrieving
  8. Keyword order affects to weight they have. This would affect to order of the list when retrieving files.
  9. When storing file time could be stored too and used when searching for files
  10. Function to maintain knowledge about category agents and keywords (especially when retrieving files, manager-agent should be able to know which category agents it sends request)
  11. Way to create new categories or giving existing ones new keywords if suitable category isn’t found
  12. Manager takes keywords from inside of file (if the file is text file)
  13. User should be able to use name or part of the name when retrieving files