CHEF CAPABILITIES

[ ]

Glenn R. Golden

()

School of Information

University of Michigan

$Revision: 1.11 $

$Date: 2002/10/11 17:37:14 $

Overview

CHEF is an on-line service that supports working communities; communities of scientific researchers, communities of teachers and students, people who work together in person as well as those who are geographically separated.

People in the community use CHEF to access computing facilities, to share resources, to communicate with one another, to facilitate meetings, to work together. They access CHEF through the web from any internet terminal with a supported browser, from their desktop or laptops or hand held devices or phones, or from public terminals.

The community can host a CHEF server of their own, or work with a CHEF service run on their behalf. CHEF users can extend the capabilities of CHEF to add capabilities specially needed by their community.

This document describes CHEF and what services it provides.

Section 1 - Overall Capabilities

Section 1 describes the features supported by the entire CHEF system.

1.1. Universal Access

Users access CHEF using a standard web browser on a device connected to the internet. Desktops, laptops, hand held devices, even cell phones can be used if they are connected to the internet and running supported browser software. No special software need be installed on the device, and nothing else is stored on the client machines. Users can access CHEF from different locations.

1.2. Addressable Resources

CHEF Resources are all the useful things stored on the CHEF server; the definitions and profiles and files and results created or contributed by the community. Users view and maintain these resources by using tools in CHEF. These resources are also available on the web; each has a URL web address within the CHEF server. This allows any CHEF resource to be bookmarked by users for direct access. Access to resources is read only; write access may also be supported by using standard web update technologies (such as DAV).

The resource address acts as a resource id for identifying the resource within CHEF as well, for such purposes as security access definitions, notifications, and usage tracking. The address is made up of the CHEF server name, a resource access point, and the resource's identifying information. Resource ids may in some cases be used without the server name and access point if the use is clearly referring to a resource of a specific type within the same CHEF server.

Access to resources, through CHEF tools and through direct web access, is controlled by CHEF security.

1.3. Usage tracking

CHEF tracks all significant user activity. This information can be used for notification, monitoring, and studies on the use of collaborative systems. When using a tool in CHEF, usage events are generated. Events record who did what, and which CHEF resource was involved in the action; other information pertinent to the event may also be recorded.

1.4. Security

Access to functions and resources in CHEF is controlled by CHEF security. Locks are built into CHEF tools and services, and keys are granted to users to permit them access.Groups of users, resources and secured functions may be defined to aid in the administration of security.

See Chef Security for more details.

1.5. Localization

Users interact with CHEF using their own natural language. Certain languages (to be determined) will be available for user selection; communities can support additional languages. Each supported language has a translation table which contains all the text used in CHEF user interfaces translated into the target language. CHEF always consults the active translation table when constructing user interfaces. Additional localization issues (text order, character sets, etc.) will be supported to the extent that support is available in web browsers; these parameters are also part of the translation tables.

Each CHEF user can select which language to use for their usage sessions. The CHEF community can select which language to use for initial interactions (before a user authenticates with CHEF) and as the default for new users.

Translation tables are organized into sections; one section for each CHEF tool, and one section for the CHEF framework.

CHEF resources created and contributed by the user community are NOT localized; they are presented in the form they are created.

1.6. User Configurability

The content of a CHEF site is configured by the users in the community. Users create CHEF portals for different purposes (see the organization section below), and configure each portal to their needs. Users further configure the site by contributing and describing resources of interest to the community.

Section 2 - Organization

Section 2 describes the overall organization concepts in CHEF. For more information about these concepts, see the CHEF Architecture document.

2.1. Portals

A community uses CHEF by setting up and using a set of CHEF portals. Each portal is a place for users to visit, work with tools and resources, be aware of who else is visiting, and work together. CHEF portals are collaborative portals. Workshops, worksites, classes and home pages, are all concepts which can be implemented using a CHEF portal.

Each portal is a collection of particular configurations of CHEF tools; a set of users working in the portal; and a set of resources accessible in the portal. Users navigate within a portal by invoking the different tools of the portal and switching focus between these tools. Users can personalize the portal (if they have permissions to do so) to control the set of tools, the tool configurations, the tools organization, and the tools layout in the portal.

Each user can get a personal portal when they register with CHEF; users can create other shared portals for meetings, workgroups, projects, or any other community needs.

In shared portals, user presence can be made available, so users can have awareness of who else is working in the portal at a given time. Configuration changes of a shared portal are seen by all users of the portal.

2.2. Tools

All the functions available within CHEF are presented to the user as a set of tools. Each tool controls a set of user interactions. Tools act as the controllers, conducting the user interfaces, and making use of services to access and update information models and business policies. Communities can create additional tools and services for their CHEF server to meet their unique needs.

2.3. Services

The behind-the-scenes work needed to support the tools are done by a set of CHEF services. Different services are designed to handle all the processing and information models of CHEF. Different versions of each service type can be made available to support different community needs. New versions of services can be added by the community to perform needed CHEF support in ways particular to a community.

Section 3 - Common Functions

Section 3 describes concepts and models behind more specific functional capabilities of CHEF.

3.1. Administration

All interactions needed to configuration and monitor a CHEF installation are done within CHEF using administration tools. Access to administration tools are protected by CHEF security.

3.2. Users

The CHEF community is made up of users. Each user registers with CHEF, gets a user id and password used for authentication, and provides a profile of certain personal information (name, email address, phone number, etc) and preferences. Users can browse this information in the community's user directory kept in CHEF. If a community has already established a user directory, CHEF can be configured to use the user ids and authentication credentials established there, so that the community need not establish yet another set of ids and credentials.

Users authenticate their identity to CHEF for full use of the system once per usage session. Until a user successfully authenticates, they are guest users and have limited access (based on security definitions).

The user's profile entry is an addressable CHEF resource and protected by CHEF security. Creation, removal, and updating of user information, user login and logout, and access to the user directory can trigger notification events.

3.3. Presence

Users can detect the presence of other users who are also using CHEF by viewing the list of users who are currently interacting with each CHEF portal. As soon as a user starts navigating within a portal they are shown in the portal's active user list; they are removed from the list when they leave the portal (close their browser window on the portal).

Users can choose to be unlisted in a portal; unlisted users do not show up in the presence display, but also do not have access to full collaborative capabilities.

Users can 'find' another user by viewing the portals in which a user is currently active. Users can also see a list of the most 'active' portals - showing counts of active users.

The presence lists are addressable CHEF resources and are protected by CHEF security.Changes in a portal's active users can trigger notification events.

3.4. Communication

Users communicate in CHEF by sending messages to one another through communication channels. Channels can be configured into different modes such as announcements, discussions, email, chat, and instant messaging (IM). Depending on the mode, message may be sent to specific users (for email, chat-whisper, IM), or sent to all users (chat, announcements, discussions). Messages have header fields (the different modes require different sets of headers) and a MIME (text, images, etc.) body. Messages are asynchronous; they composed and sent by a user, stored for some time in the channel, and read by other users at other times.

Each communications mode has its own organizing method. Announcements and chat are organized in flat lists ordered by date sent. IM and email are also ordered by date sent, but the channels are dedicated to a single user's messages. Discussions are threaded by the "response to" header field.

Communication channels are persistent. Messages can live in a channel for any period of time. Administrative access to channels can remove messages. Some channel modes will naturally remove messages (such as when an email message is read and removed from the in-box, or when an announcement channel is set to retire messages of a certain age).

Communications channels support both a broadcast model, where tools are listening for changes to a channel (such as new messages being posted), and a check model, where tools check on the channel for their state, or for changes since some last check time.

Communications channels and messages are addressable CHEF resources and are protected by CHEF security. Sending, receiving, changing, and reading messages can trigger notification events.

3.5. File Hosting

Users in a CHEF community can make electronic files available to the community (and to the web) by having them hosted in collections in CHEF portals. Each hosted file has a body containing the bytes of the file. Each file is identified by a unique name and path. Each file has basic descriptive attributes: a MIME type describing the format of the body bytes, a hosting-date recording when the file was uploaded, a modified-date recording the last change to the file, and ahosted-by recording who placed the file into the collection.

Each portal has its own separate collection of files. A file's path and name combination must be unique within the collection of the portal in which they are hosted.

Each file is a CHEF resource, and so has a unique address on the web. This address is made from the CHEF server name and resource access point, the name of the portal in whose collection the file is being hosted, and the file's path and name.

A file's path may consist of 0 or more directory names, separated by a "/" character, forming a conventional file path. Any path string may be entered for a file, as long as the file path and name remain unique within the collection. There is no explicit directory creation process (although files can be selected by partial path strings in the expected way to, for example, show the contents of one directory in a collection).

File names and paths are limited to certain characters, to avoid conflicts with URL naming conventions, and to certain lengths.

A file may be uploaded from a user's computer, created online using CHEF editing tools, or copied from another hosted file in the same or another collection (a copied file is completely independent of the original). Once in a collection, a file can be renamed, changing the name, or moved, changing the path. File bodies can be updated, by uploading a new byte set or editing the bytes of a file. Updating a file sets a modified-date attribute to record when it happened, and a modified-by to record who did it.

When the CHEF server is asked to deliver the file (by its resource address), it sends the bytes of the file body with the associated MIME type, hosting-date (as a creation date) and modified-data (as last modified date).

A hosted file can be linked to other resource addresses, other names and locations in the same collection, or in other collections. Each of these other collection, path and name combinations is considered a separate CHEF resource, but they all refer to the same file body and basic attributes. Changes to the hosted file are seen when the file is accessed using any of the resource addresses that are linked to the file. Each resource address of a file can have its own security definitions.

One type of file's body bytes are treated specially by CHEF.External files are files whose bodies are external to CHEF, and are identified by a URL to the file within CHEF. These files are known by their MIME types. The body bytes of these files is the URL to the external file. External files have names and paths within CHEF collections, just like normal files. They differ only in that their bodies are retrieved from the external source at access time rather than being hosted in CHEF, and the dates and MIME types reported at access time are those from the external access rather than those associated with the file in the CHEF collection (these attributes are available through the CHEF tool interfaces as they are for all files).

Hosted files are addressable CHEF resources, and access to and manipulation of files are protected by CHEF security. New files, changes to file contents, name or location, updates and file access can trigger notification events.

3.6. Resource Description

Users in CHEF can share knowledge of things by entering resource descriptions. Resources can be any CHEF resource, anything on the web addressable by a URL, or any thing in the world that can be assigned a URN. Descriptions are statements about these resources, asserting qualities to resources and relations among different resources.

CHEF resource descriptions are based on W3C's RDF.

Resource descriptions are used to reason about resources. Search makes use of these descriptions to help users find things. Descriptions also enrich user's understanding of the resources described, capturing knowledge for the community.

What vocabularies?

Each resource description statement is an addressable CHEF resource, is protected to CHEF security, and may trigger notification events when created, changed, or used in reasoning.

3.7. Search

Users find resources in CHEF or resources they have described in CHEF by using search tools and specifying filters of search criteria. Search can apply to all types of CHEF resources and resource descriptions.

Filters are defined to limit the search to what the user is looking for. Filters can be stored for later reuse. Filters are patterns of resource descriptions. They can limit the search based on the resource address, on resource type, on file type, on any descriptive information known to or generated by CHEF.

What language for filters? Where are filters stored and how are they edited? Are they a MIME type of hosted file with an on-line editing tool?

Filters are addressable CHEF resources and are protected by CHEF security. New filters, changes to filters and use of filters can trigger notification events.

3.8. Notification

Users are notified when certain events occur in CHEF. Users establish sets of filters to control when and about what they are notified. Notification is immediate when the user is online, and can be delivered asynchronously (by email or other communications channel). Notification history lists past notifications and can be maintained by the user.

Is notification always individual, or can a group be notified?

Notification uses the same format of filters as does Search. These filters are addressable CHEF resources and are protected by CHEF security. New filters, changes to filters and use of filters can trigger notification events.