Personal and Collaborative Portfolios
using the OKI OSIDs

Mark J. Norton

Oct. 30, 2003


1.0 Overview

Filing systems have been with us from dawn of operating systems. Computer files are the electronic form of paper and documents - they serve to record information, knowledge, communication, etc. As we continue to move into a networked existence, however, computer files and documents are no longer the only pieces of information that need to be managed. Now we need to deal with references to remote material, annotations, relationships between pieces of information, metadata, and search results. We are seeing new ways of organizing collections of this information such as cognitive maps, portfolios, indexed collections, etc.

This document explores the possibilities presented by the Open Knowledge Initiative’s OSIDs in developing digital collections of information that can support collaborative work efforts. There is currently a great deal of attention being focused on digital collections ranging from digital repository systems at the large end to ePortfolios in the small.

To some extent, personal collections share many of the same problems that larger repositories have. There are organizational issues that determine how material will be grouped - dynamically, with multiple views, etc. Access control determines who will be allowed to view, modify, change, or annotate material contained in it. Rights management should ultimately be addressed.

For the purposes of this paper, such personal collections will be referred to as a portfolio. While this term is already being overloaded with meaning, the image of a folio containing important papers is compelling. The portfolio has personal connotations that distinguishes it from the policy laden view of massive digital libraries and similar on-line repositories. As such, don’t confuse the use of the term here with ePortfolios, school portfolios, or similar constructs in commercially available eLearning systems. While there is a lot of overlap in what these other applications are attempting to accomplish, the intent is to take a fresh look at the problems involved and how the OKI OSIDs might provide support for implementing portfolios.


2.0 Personal Portfolios

A personal portfolio is a collection of information associated with a particular person. In the broadest sense, a portfolio is any and all information that the person considers to be important. More practically, a portfolio is created for some purpose such as study towards a particular degree, work in a given field, materials relating to a project, etc. Thus, a person might have more than one portfolio, or a portfolio might be associated with the kind of information it contains (a study portfolio living on the school’s server, for example).

2.1 Content

While almost anything could potentially be included in a portfolio, certain kinds of information can be identified:


Let’s take a closer look at these information types. Documents are pretty obvious. They consist of what we currently keep in computer files: reports, correspondence, blog entries, pictures, sound files, video clips, source files, outlines, schedules, assessments, certifications, awards, and many, many more. Documents are a kind of content object. Documents (often called assets in digital repository systems) have some way to identify them, typically a name. For the purpose this discussion, documents are further defined to be physically present in the portfolio (ie, there is a local binary instance of it).

References are very similar to documents in that they can be pretty much the same kinds of things: formatted text, illustrations, music clips, and so forth. However, these objects aren’t physically present in the repository. Rather, they are a reference to a location where they can be found. Rather than having just a name, a URL (or URI) is used to identify the content object. The concept of a reference is important when DRM considerations are to be taken into account, since some repositories may not allow a local copy of an asset.

Both documents and references may have metadata associated with them. What’s in this metadata? Almost anything which describes the content object can be considered to be metadata. Common examples include author, creation data, current version, and many others. We can avoid the question of how this metadata is described (Dublin Core, LOM, etc.) for now.

An annotation is any kind of additional information which is to be associated with a given content object. Typically, this takes the form of a comment or note, but it could be anything. Annotations could be considered a kind of metadata, but since they tend to add value to the original content object, they can be considered a kind of content object in their own right. In fact, you may want to allow annotations to have annotations (etc.).

2.2 Organization

Organizers provide strategies to organize, group, collect, or relate a set of content objects (or other organizations). File systems often use the idea of file folders (also called directories, or cabinets in OKI). This is a simple, hierarchical organization strategy. Other kinds are possible including sequences, template plans, views, concept maps, and others. Organizations can be considered to be content objects themselves and have both metadata and annotations associated with them. Indeed, it is possible to treat an organization as a document and vice versa. A portfolio application might provide a means to explode a document into an organization (breaking up sections of a report, for example), or implode an organization into a document (create a plan document from collected stages).

Extending this concept a little further, you might see that each content object in the portfolio is actually a special kind of organization consisting of content objects, metadata, and annotations. This means that there are really only two kinds of objects in the portfolio: content objects and organizations. Content objects can be pretty much anything that can be viewed and/or edited. Organizations, on the other hand, come in different flavors.

If we think of organizations as a way to establish a relationship between two or more content objects, the problem starts to look a lot like graph theory along with some set of constraints. For example: a sequence is a directed list of content objects. A file/folder hierarchy is a tree, etc. If we further assume that any node in such an organization graph can be a sub graph, then arbitrarily complex organizations can be constructed.



2.3 Access Control

Depending on how the portfolio is created an managed, the person who creates a portfolio may or may not be the owner of it. Work done for a company, for example, is likely to be owned by the company itself. Regardless, one or more persons can be defined has having control over the contents of the portfolio (or levels of control). Access control typically consists of the following operations:


Some of these may be a bit different than normal file access conventions. The ability to copy a content object, for example. Annotation means that a person is granted permission to add comments to a document included in this portfolio. Reference access grants permission to make a reference to a given object. View is obviously viewing or reading the object, but view metadata allows a person to access just the metadata for an object, independent of the object itself.

In addition to basic access control, a portfolio should be able to subscribe to a other portfolios (having been granted such permission). New entries, modifications, annotations, etc. in another portfolio are made known to this one. Similarly, documents, organizations, or whole portfolios can be set up to be published to some other on-line collection of information, such as a larger digital repository. Publishing outside of portfolios could be handled by protocols such as RSS.

2.4 Group Portfolios

Groups of people are created when the come together for some shared purpose, often work related, but also for many other reasons. Portfolios can be created which represent the collective efforts of a particular group. These portfolios are identical to personal portfolios, except they are shared. Sharing means being able to impose rules on group members and those outside of it. These rules may restrict members to making additions within an organization, limit them to certain kinds of operations, etc. These operations are very similar to the access controls defined for personal portfolios, but can be applied to a group (or sub-group) of people. Thus members can do things that non-members might not be able to do. Certain individuals may also be designated as administrators as well, giving them additional privileges.

Group portfolios are the basis for group collaboration. It defines a workspace common to members of a collaboration team. Access controls allow the members of the group to create the privacy they need to explore creative solutions to work problems. Collaboration tools such as a forum, a chat room, a shared white board, or meeting managers produce content objects which are part of the group portfolio.

A few words need to be said about group membership. In the abstract, a group is any collection of people, but groups can also include sub-groups or peer groups as well. Thus, if you are defined to be a member of that group, your are a member of this group as well. This raises some interesting questions of identity of members.
There are lots of John Smiths in the world, but only one with a given Social Security Number (hopefully). Groups themselves have identity. This is important when access control or digital rights are negotiated between organizations or institutions. Thus a group working on interactive music at MIT might grant access to their portfolio to a similar group at Cambridge University in the UK.

(A design using OKI OSIDs is also available)