A Design for Portfolios
using the OKI OSIDs

Mark J. Norton

Oct. 30, 2003

Based on the overview of portfolios, a design for a general purpose portfolio can be created using the OKI OSIDs. The Open Knowledge Initiative has a layered service architecture which is focused on two particular layers: the Common Services Layer, and the Educational Service Layer. Above the Educational Service Layer is the Applications Layer. Below the Common Services Layer are System and Enterprise Services.

In keeping with this architecture, a Personal Portfolio application is likely to need a new set of services in the Educational Services layer to support it. Let’s call this set of services the Portfolio Services. They in turn will require some or all of the OKI Common Services. This leads us to a portfolio architecture:

Note that this diagram doesn’t show all of the Common Service OSIDs. Those shown here are a representative sample. More discussion is made below on which common services will be needed to implement the Portfolio Services. First, however, we need to examine the Portfolio Services.

1 Portfolio Services

While the services needed to support a Personal Portfolio application could be quite broad, two important services stand out: Organization and Access Control. Each of these were discussed at a conceptual level earlier in the paper, now it’s time to take a more functional look at these services.

1.1 Organization

How do we go about organizing things? We need a way to model an organization using some organizational metaphor. We need a way to create, edit, and display it. Finally, we may need some way to package it for portability between systems, or perhaps archiving. Many different kinds of organizational metaphors were proposed earlier, but all of them can be expressed as some form of a graph. The power of general graphs is also their biggest problem. Generalization can impede performance. Fortunately, with the exception of Concept Maps, most organization metaphors are based on either trees or lists.

Organizer Functions

New Remove Rename Edit View Package Share

These functions will be needed to manage all organizations. In addition, there will be specialized functions associated with particular organization strategies. One organization needs special attention, however, which we will call a ContentCluster. The ContentCluster consists of a Content Object, a metadata collection, and one or more notes. By default, all documents and references will be bundled up in one of these clusters.

ContentCluster Functions

Create Delete Rename View Content Object Edit Content Object View Metadata Edit Metadata View a note Add a note Remove a note Interate over notes

A ContentCluster creates a wrapper around information related to a content object. There are still some open questions about these clusters. For example, if a ContentCluster is one kind of organization, do other organizations also have metadata and notes? I suspect so.

Three basic kinds of organization (in addition to ContentCluster) are proposed: maps (Concept Maps), trees, and lists. This allows implementations to be based on a model which is close to the metaphor and therefore be efficient. Since maps subsume both trees and lists, packaging can be handled at the most general level.

The Organization Function Table

Map Node Create node Get arcs Follow arc to a node Set content Get content Arc Create arc Link head Link tail Set direction Set relationship Get relationship Tree Node Create node Set content Get content Get children Get parent Set parent Add child Insert child Delete node Iterate breadth first Iterate depth first List Node Create node Add node Insert node Delete node Iterate over nodes Set content Get content

1.2 Access Control

In addition to organization, Access Control is a critical portfolio service. Access Control determine who will be able to do what to the material collected in a personal or group portfolio. Access Control breaks down in three sub services: identify groups and people, defining functions, and determining the conditions under which functions can be performed.

Access Control Functions

Groups and People Access Classes Create Access Class Remove Access Class Edit Access Class Ad Hoc Groups Create Group Remove Group Edit Group Organizations Create Organization Remove Organization Edit Organization Individuals Create Person Remove Person Edit Person Assign Access Class Change Access Class Assign to Group Remove from Group Assign to Organization Remove from Organization Functions Delete Reference View Modify Create Copy Add Note View Metadata Conditions TBD

2 Implementing Personal Portfolios using the OSIDs

2.1 Implementing Organizations

The obvious place to start with an OKI implementation of organizations is osid.filing. The filing interfaces define a hierarchical system of entries (CabinetEntry) using two types of nodes: Cabinet and ByteStore. The Cabinet class corresponds to a directory or folder, while the ByteStore can be used for files. A Cabinet entry has properties and tracks certain basic information about management. ByteStores closely correspond to files with support for MIME type, read/write access, creation and modification date, etc.

In some ways, the osid.filing interface is perhaps a bit too close a filing system to be general enough for the kind of organizations that are described here. Organizations need to be flexible enough to capture different kinds of organization styles. Fortunately, the osid.heirarchy interfaces provide a more general structure. The osid.heirarchy.Heirarchy class is a handy wrapper for an organization which provides a separate Id, description, display name, type, etc. Each Heirarchy can have multiple root nodes. From these root nodes extend sets of other Nodes which can be organized in pure hierarchies, lists, and (if multiple parents are allowed), even limited graphs. Finally, osid.heirarchy also defines traversals, which is a useful concept in defining paths through a portfolio organization.

Ultimately, a personal portfolio application will need both the osid.filing and osid.heirarchy interfaces. Filing will be needed to access remote and local file systems. Heirarchy can provide a rich representation form for organizations, but need to be extended to associate arbitrary objects with a node. Node type can then be used to identify assets (text, pictures, sound, etc.), references, and collections. Since the Cluster organization is widely used in the portfolio architecture, it might be implemented as it’s own class with associated content object, nodes, and metadata. There are some interesting possibilities with creating indexed metadata mechanisms to speed up meta data searching.

Using this approach, different kind of organizations become differently typed hierarchies. Additional work is needed at the content object level, to properly type it (perhaps using MIME). Virtually all information which might be associated with a content object can be represented in a metadata system (Dublin Core, LOM, METS, etc.), but it may be better to pull certain types of things out into the object structures for faster access to data. These include things like access controls and authorization, owner, various time stamps, and the like. Some form of viewer registry will likely be needed to define viewers and editors which are associated with specific content types.

Finally, we should consider the osid.dr (Digital Repository) interfaces as an other candidate for organizations. To some extent, the osid.dr interfaces provide a control structure above the level of organization. Support is provided for defining high level collections (a Repository), and then carefully defining the parts and record which might be contained in it. Given this, it is quite possible to save content objects associated with a portfolio in a local (or central) personal repository. There are some distinct advantages to this, since there a great deal of work being done on providing repository services and related services such as Digital Rights Management.

Ultimately, a portfolio is a collection of organizations, which itself is a kind of organization. Like clusters, this top level organization might be special cased to include information which needs to be globally associated with all data contained in it. This information might include identity data, access notices, blanket copyright notices, and contact information.

2.2 Implementing Access Control

Access control describes what kinds of things can be done to material collected in a portfolio, and who may perform these kinds of operations. The OKI OSIDs provide two important interface definitions for implementing access control: osid.authentication, and osid.authorization.

Authentication is the process of verifying the identify of a person, agent, organization, or group. The osid.authentication interfaces permit different kinds of authentication strategies, which are typically based on underlying enterprise authentication services such as Kerberos, LDAP, X.500, IMAP, POP3, etc. Various kinds of evidence can be provided for authentication, typically user name and password, but might include digital certificates, public crypto keys, and even hardware keys like dongles and smart cards. Regardless, osid.authentication is the first step in access control: verifying the identity of the person, agent, organization, or group.

Before moving on to discussing authorization, it should be noted that osid.shared provides support for the definition of agents (people), and groups (organizations, groups, etc.). Agents can have properties associated with them, can be typed, and be made persistent with minor extensions to SharedManager. The Group class allows Agents to be collected hierarchically.

The osid.authorization interfaces provide virtually all the support needed to implement most kinds of access control. An authorization is a triplet consisting of an Agent, a Function, and a Qualifier. The agent defines who (person or group) has this authorization (ownership). The function can be any kind of access operation, starting with those defined above. Each function has its own unique Id, a FunctionType, a display name and a description. The qualifier describes the context in which this authorization is valid. It includes an Id, display name, description and QualifierType. Qualifiers can be arranged hierarchically, thus allowing the creation of logic trees (AND / OR trees).

Digital Rights Management (DRM) shares some challenges associated with access control. DRM provides an owner with control over their work and how they would like it to be distributed. It also allows for the creation of references and inclusion of work by other people. DRM is a topic of active debate in the IEEE Learning Technology Standards Committee and other standards organizations. Likely, this effort will lead to a rights management description language, represented using XML, which will allow business rules and rights management rules to be defined. Certain aspects of DRM can be represented now using a combination of metadata and authorizations, but this a candidate to become a standalone common service in the (hopefully) near future.


3 Portability and Interoperability

So why reinvent the portfolio wheel yet again? Electronic portfolios and the management applications associated with them have been around for years. Why do we need yet another? The answer lies in portability and interoperability. With the wide scale use of XML (and derived technologies like XML Schema and RDF), true data interoperability has become possible on a global scope for the first time. Certain types of data recur often in portfolios: skill assessments, certifications, contact information, demographic data, etc. As XML representations for these structured data form appear, moving them around between portfolio applications becomes possible.

Data portability is also important in a collaborative environment where members of a group are teamed together to perform a common task. Collaboration also exists between a student and teacher. Where ePortfolios are used in an academic environment, the information contained in a portfolio either comes from a technology based learning environment, or is used as inputs to one. Data portability allows the portfolio system to be decoupled from other learning support systems, creating more flexibility for system integrators and developers.

More and more, learning systems combined components from diverse sources: registration systems, student management systems, course management systems, eCommerce, school and campus schedulers, portals, etc. One of the intended purposes of the Open Knowledge Initiative is to make learning support services and application components based on a uniform set of underlying services (Common Services and Educational Services). This in turn improves code portability and sharing of custom software solutions that can be integrated into larger systems.

Interoperability between ePortfolio applications and other learning applications requires that new systems leverage the old were possible, and take compatibility into account where possible. The Open Source Portfolio Initiative (OSPI), for example, is leading the charge to repurpose portfolio software developed at the University of Minnesota and make it broadly available to academic institutions. The ePortfolio Consortium is a group of vendors, organizations, and institutions banding together to create standards for ePortfolios. Vendors are starting to open up access to their products for customization and making them interoperate with other eLearning applications.

Besides the ePortfolioConsortium, there are other standards bodies who have produced work which is relevant to the development of ePortfolios. The Interstate Teachers Assessment and Support Consortium is developing standards for assessment and certification. In the corporate world, the HR-XML consortium have produced standards which capture corporate skills in a data portable manner. The National Center for Research on Evaluation, Standards, and Student Testing (CRESST) has been working toward standards for student testing and evaluations for many years. Finally, the IMS Global Learning Consortium has developed the Learner Information Package which contains support for representing many of the descriptive aspects of a person.