Part 3 Collaboration in the 21st Century : A Conceptual Collaboration Machine

1
Part 3Collaboration in the 21st Century A
Conceptual Collaboration Machine

• Dr. Y.V. Ramana Reddy
• Dr. Sumitra Reddy
• Vijayanand Bharadwaj
• Lane Dept. of Computer Science and Electrical
  Engg.
• West Virginia University
• USA
• August 2005

2
Part 3 Overview

• The Ideal Collaboration Machine CEPhone
• Mitigating Barriers to Collaboration
• Identifying the Solutions
• EkSarva -Towards the Ideal Collaboration
  Machine
• Theory and Concepts
• Our work at SIPLab CERC
• EkSarva Implementation
• ARTAS
• Awareness Model
• Extant Systems
• Other popular systems

3
The Ideal Collaboration Machine

• Imagine a machine ..
• Any project, Any Processes, Seamless
  Collaboration
• Barriers Mitigated
• All Collaboration Support Broken down to
  Simplified Basic Tasks !
• Discover (Lookup)
• Compute
• Communicate
• Negotiate (Conference)
• Decide
• Archive
• A TASK-ORIENTED ARCHITECTURE !
• Working with Information Not with tools !

4
CE Phone (1992)

A Conceptual Collaboration Machine !
5
CEPhone A Conceptual Collaboration Machine
6
The Ideal Collaboration Machine

• Our Work is towards realizing such a machine..
• EkSarva A Workflow-Centric Context-Aware
  Collaboration Framework !

7
Mitigating Barriers

• Barriers stem from
• Work Processes
• Organizational Factors
• Existing Technology

8
Mitigating Barriers (2)

• Barriers from
• Work Processes
• Collaborative Work processes are varied, many
  requirements, constraints, processes difficult to
  characterize, constantly morph Complexity,
  Change, Goal Disambiguation, Measurement,
  Metrics, Temporal Barriers

9
Mitigating Barriers (3)

• Barriers from
• Organizational Factors
• Human behavior, feelings, Intentions, Perception
  not easy to characterize and propagate in
  collaboration - Intention Barrier, Perception
  Barrier, Goal Disambiguation

10
Mitigating Barriers (4)

• Barriers from
• Existing Technology
• Lack of interoperability Complexity Change
  Barrier
• Lack of Support to Capture and Propagate Context
  i.e. Intentions, Perception, Goals
• Lack of Evaluation Support Temporal,
  Measurement, Metrics

11
Identifying the Solutions

• As barriers are related to Work Processes,
  Organizational Factors and Technology, we
  identify five steps towards solutions that
  mitigate barriers.
• These steps are taken with the perspective of
  Work, Organization and Technology.

12
1 Acquire Deeper Understanding

• Acquire deeper understanding of the relationship
  between Work, Organizational factors and the
  existing Technology Support wit respect to
• Nature of Work Processes to be implemented
• How Organizational factors and Technology impose
  constraints on Work Processes

13
2 Capture Essence of Collaboration

• 2. Model Collaborative Work Processes along with
  associated Constraints, Goals, Intentions,
  Perception in a unambiguous manner so they can be
  recognized and enacted.
• As collaboration is inherently complex and
  constantly morphs
• Distill collaborative processes and captures the
  essence in simple constructs (PPPSST Model).
• Complex processes can be created by simple
  combinations of the same

14
3. Provide Flexible Technology

• Enable Technology Support (Custom and/or COTS
  solutions) that can enact the modeled work
  processes.
• Adaptability can be provided by supporting the
  basic
• elements of Collaboration viz. I3C. Conceptually,
  
• Information Objects
• Communicator Objects
• Coordinator Objects
• Computational Objects
• These building blocks can be combined in a
  variety of work processes in a flexible manner.

15
4. Effective Awareness Propagation

• 4. Propagate Effectively Awareness of
  Collaboration Context
• Both users and system components need to be aware
  of various aspects of the collaborative process
  at the appropriate time

16
5. Advance Interoperability

• 5. Technology Interoperability must advance.

17
The EkSarva framework

• Our Work at SIPLab, CERC
• Implementing the solutions.
• EkSarva A Workflow-Centric Context-Aware
• Collaboration Framework

18
Eksarva

• Provides the necessary building blocks
• facilitating a unified, modular and intuitive
  approach to collaborative application
  instantiation

19
The three pillars of EkSarva

• Enterprise Model PPP/SST
• Workflow Model I3C
• Intelligence Model Context-Awareness

20
EkSarva A Complete View
Conceptual View
Implementation
PPP/SST
Collaborative Enterprise
21
Enterprise Model PPP/SST

• Project (P) A project is a specification of the
  collaboration goal and the terminal point of the
  collaboration.
• Person (Agent) (P) Person is an individual group
  member engaged in a collaboration instance.
• Place (P) A place is a concept of a virtual
  meeting place, analogous to a physical meeting
  room, where groups of people come together to
  engage in a task.

22
PPP/SST (Contd)

• Signal (S) Signaling is a key mechanism in
  EkSarva.
• Situations (S) generate signals to indicate their
  status in which case the framework proceeds with
  newer tasks and situations
• Smart Transcript (T) Smart Transcript is an
  object that links all the situations that are
  part of the collaboration episodes. We could
  imagine the transcript as being the memory of
  the collaboration instance

23
Workflow Model I3C

• The I3C is a set of metaphor-neutral building
  blocks
• Information
• Communication
• Coordination
• Computation

24
I3C

• I3C distills the CE Phone concept as follows
• Information
• Information about the collaborative effort (
  goals, tasks, timeline etc) as well as artifacts
  created as a result of collaboration
• Communication
• Synchronous and Asynchronous

25
I3C

• Coordination
• The actions taken to ensure that the tasks are
  performed at the right time, by the appropriate
  people, taking into account all the constraints
  such as dependencies, resource restrictions etc.
• Computation
• All the necessary computational processes
  required to accomplish the tasks

26
I3C
27
EkSarva Architecture

• The architecture consists of two major
  subsystems
• Specification subsystem
• Instantiation Subsystem

28
Specification Subsystem

• Specification subsystem is responsible for
  providing mechanisms to specify the framework
  components
• Project, Person, Place, Situation, Signal and
• Smart Transcript

29
Instantiation Subsystem

• This subsystem is responsible for instantiating
  the collaboration defined in the previous
  subsystem. The collaboration engine is
  responsible for activating the collaboration
  environment.

30
EkSarva Specification and Execution
31
EkSarva A Layered View
32
Interface Layer

• The interface, in addition to, providing a
  representational view of the underlying
  collaboration Project also enables interaction
  with the project.

33
Coordination Layer

• The coordination layer is the command center of a
  collaboration project
• Various framework components that were
  illustrated in the previous section are realized
  in this layer through the following services
• Workspace Manager
• Situation Manager
• Agenda Manager
• Context Manager
• Transcript Manager

34
Knowledge Layer

• This layer contains the library of concepts that
  enables EkSarva to bring context awareness and
  intelligence to the collaboration process

35
Network Layer

• This layer represents the network infrastructure
• It enables the communication and data transfer
• Activities in this layer are triggered by the
  combination of signals, generated by the above
  layers, and awareness to perform an activity

36
(No Transcript)
37
EkSarva A Complete View
PPP/SST
38
Collaboration in the Software Development
Lifecycle
Morphing Collaboration patterns
Requirements Analysis
Design
Implementation
Testing Debugging
Local informal meetings
Peer-to-peer interaction, brainstorming
discussions, oppurtunistic collaboration
Shorter synchronization Longer individual
parallel execution
Formal Scheduled Meetings
Only Documents are exchanged.
39
Personal Space Project Group Space
Project 1 Workspace
Personal Space
Software Engg. View
Project Manager
Developer
Collaboration includes Peer-to-Peer interaction
(Mixed Initiative)
Technical Writer
Software Engineer
40
Project Workflow
Project Group Space
Project Personal Space
Drags and drops code files
1.Agent receives code files. 2. Checks if all
files are present for integration
Developer 1 Coding
If all present indicate ready for integration.
Project Personal Space
Developer 2 Coding
Project Personal Space
Drags and drops code files
Developer 3 Integration
Notify if files missing !
41
Workflow Centricity Context Awareness !!
Project Group Space
Project Personal Space
Developer 1 Coding
Project Personal Space
Developer 2 Coding
Project Personal Space
Developer 3 Integration
Communication (C)

42

• EkSarva Strategy for Mitigating the Barriers

43
Managing Complexity

• Workflow management systems Focusing on the
  dynamic nature of workflow.
• Dynamic workflow enables intuitive and automatic
  modification of goals, tasks and members and
  handle contingencies

44
Perception

• We are exploring the use of context-aware
  information in combination with visualization
  agents and immersion through virtual environments
  to identify and capture user preferences, system
  resources and capabilities and provide views
  accordingly

45
Change

• We are exploring patterns of collaboration to
  facilitate the smooth transition of collaborative
  paradigms

46
Intentions, Autonomy, Goal Disambiguation

• Through the PPP/SST modeling we believe the
  collaboration framework could facilitate the
  management of human-agent continuum.
• Introspection Strategies

47
Temporal, Measurement, Metrics

• We are exploring the use of a machine
  understandable Smart Transcript and discrete
  event simulations to explore look-ahead and look
  back of events and Real time operational
  intelligent feedbacks

48
Our Thesis

• PPP/SST I3C Intelligence Model
• Successful Collaboration !!

49
Our Current Work

• EkSarva Conceptually the Invisible Force
• EkSarva Implementation
• Step 1 Creating support for PPPSST modeling
• An Ontology-Based Approach
• Step 2 Adaptable Workflow through Rule-Based
  Execution
• Step 3 Awareness Model for Enabling
  Context-Awareness
• Step1 and Step 2 are realized through ARTAS.
• Step 3 through the Awareness Model

50
EkSarva Building Blocks
51
ARTAS

• ARTAS
• An application to create models of real-world
  systems that expresses all aspects, attributes,
  relationships among entities and constraints.
• Represents Knowledge of a system under
  consideration for any domain.
• Rules can be associated with System Models to
  trigger changes in the model based on events that
  occur.
• Can be used as an Expert System in applications
  domains where needed
• Can be used for Knowledge-Based Simulations

52
ARTAS (2)

• Origins Based on LASER - an expert system in C
  language
• (CERC, West Virginia Univ.)
• Etymology (Sanskrit)
• artha meaning
• vayas web or network
• Artha Vayas ARTAS a network of meaning
  knowledge network
• ARTAS Implemented over Protégé by incorporating
  LASER paradigms and constructs
  (http//protégé.stanford.edu)

53
ARTAS EkSarva

• Relation to EkSarva
• Ontology-Based Modeling Generic Rule Engine are
  used
• Collaborative Enterprise Modeling (PPPSST)
• Elements of the Collaborative system are defined
  and modeled through ARTAS.
• Adaptable-Workflow Enactment
• Rules are associated to trigger behavior
  implemented in user-defined methods.
• Rule Engine receives the events based on human
  actions, and system states during collaboration.
• Rules that match event-conditions are selected to
  fire.

54
ARTAS Screens
55
ARTAS Screens
56
ARTAS Screens
57
ARTAS Screens
58
ARTAS Screens
59
ARTAS Screens
60
ARTAS Screens
61
ARTAS Screens
62
ARTAS ARCHITECTURE
63
ARTAS Components

• The basic components of ARTAS are
• User Interface
• Rule Engine
• Knowledge Base
• Application Interface

64
ARTAS USER INTERFACE

• ARTAS User Interface includes both graphical
  version and command line version
• The ARTAS Graphical User Interface was built upon
  Protégé. This interface can be used to model a
  system with classes and instances. The rules for
  the system can also be specified and saved
  through this interface.
• Another feature that comes with Graphical
  Interface is Graphical View of the model

65
ARTAS USER INTERFACE (2)

• The Graphical View can be used to view the models
  as graphical representation. The Models graph
  can be rotated, zoomed and modified. This graph
  is stored in XML format
• The command line interface is an added feature.
  All the operations except graphical view can be
  performed using command line interface. The
  commands are provided in the ARTAS Manual

66
ARTAS Rule Engine

• ARTAS Rule Engine consists of the following
• ARTAS Rule Server
• Rule Kernel
• Dynamic Compiler
• Rule Language Parser
• A Queue
• User defined Java Methods and a Generic Method
• ARTAS Rule Server is a server listening on Port
  2400.
• It communicates with the applications through
  Application interface. The protocol that it uses
  is called ARTAS Rule Protocol (ARP).

67
ARTAS Rule Engine (2)

• Any application that needs to check its rules for
  an event should first create an instance of the
  Application Connector object. It should specify
  the Host IP address of the Rule Server, Knowledge
  base, Class Name in the model to the application
  connector object.
• The application connector takes care of the Rule
  Protocol. This removes the burden of Rule
  Protocol implementation.
• The connector first connects to the Host IP
  Address of the Rule Server specified by the
  application. The port used is 2400. This is a
  standard port for all Rule Servers.

68
ARTAS Rule Engine (3)

• When the Rule Server receives a request for
  connection from the application connector, it
  creates a separate thread for the Rule Kernel.
• The Rule Kernel is the CORE part of the Rule
  Engine, which takes care of managing the
  RuleParser, Dynamic Compiler and finally firing
  the appropriate Method.
• When a thread for Rule Kernel is created, it
  takes care of getting the data from the
  application connector.
• A Finite State Machine mechanism is implemented
  for the Rule Kernel. The Rule Kernels state
  diagram is shown in the next slide.

69
Rule Kernel FSM
70
Rule Kernel FSM (2)

• When a Rule Kernel object is created, the Kernel
  would be pushed to IDLE STATE. The kernel would
  be waiting for a command from the application
  connector. In any state of the FSM, if the kernel
  does not receive a command from the connector, it
  moves to the END_STATE in which the connection
  would be closed for the application.
• The first command from the application connector
  would be SETUP command. When the kernel
  receives the setup command, it would move into
  SETUP STATE.

71
Rule Kernel FSM (2)

• When kernel is in SETUP STATE, it can accept two
  commands namely, SET KB ltKbnamegt and SET
  CLASS ltClassnamegt.
• Upon receiving these commands it will set
  knowledge base and class name respectively.
• The setup operation will be completed only after
  receiving the END SETUP command. Kernel moves
  to IDLE STATE again after the completion of setup.

72
Rule Kernel FSM (3)

• When the rule has to checked, the application
  calls the connectors check method. This method
  sends CHECK RULE AND EXECUTE command if the
  rule has to be checked and fired by ARTAS Kernel
  itself. If the rule has to be checked and the
  corresponding method be fired locally in clients
  machine, CHECK RULE AND RETURN command should
  be sent to the kernel. This command checks the
  rules and sends the name of the method to be
  fired. If rule was not satisfied, it would return
  NULL. The kernel goes to EXECUTE STATE and SEND
  STATE respectively.
• When END command is received by the kernel, it
  moves to END STATE, in which the connection would
  be closed for the application.

73
Rule Parser

• Rule Parser is a built-in class. When the kernel
  moves into the CHECK STATE, it first creates an
  object of Rule Parser. It will set the knowledge
  base and class name of the Rule Parser object. It
  will then call the parse method.
• The rules are specified in XML format. The Parse
  method of the Rule Parser object parses this XML
  string and verifies the rules and the kernel
  moves to SEND STATE or EXECUTE STATE

74
Dynamic Compiler

• If the kernel enters the EXECUTE STATE, it should
  fire the appropriate method. For this, the kernel
  uses dynamic compiler.
• Dynamic compiler replaces the string Generic
  inside the Generic method with the methods name.
  It then compiles the Generic method. An object is
  created and the corresponding user defined method
  is called.

75
Team EkSarva
76
Team ARTAS
77
Extant Systems

• We examine some Prominent Computer Supported
  Collaborative Systems in existence
• Industry Commercial Products
• Academic Research Efforts
• These range from
• Environments Supporting Collaborative Application
  development and deployment
• Groupware
• Individual tools

78
Extant Systems

• IBM Workplace Collaboration Services
• ( http//www-306.ibm.com/software/lotus/)
• Suite of products for Collaboration including
• Lotus Domino Lotus Notes
• WebSphere Portal, WebSphere Everyplace
• Application Development Portal for Collaborative
  Applications
• Provides Components (Domino Server, Notes Client
  etc.)
• Messaging Services (Email and Instant message
  metaphors)
• Calendaring and Scheduling for teams.
• Document File Management (Collaborative
  authoring, sharing )
• Web-Based Deployment if preferred
• Mobile User Support
• Customizable Work Spaces Views, Integrated
  Presence Awareness
• Team Conferencing
• Workflow System
• Presence Awareness

79
Extant Systems

• IBM Workplace Collaboration Services

80
Extant Systems

• IBM Workplace Collaboration Services

81
Extant Systems

• 2. Microsoft Office Suite for Collaboration
• (http//www.microsoft.com/office/prodinfo.mspx)
• A host of components (application servers and
  client programs) providing essential services for
  collaboration such as
• Messaging (Email and Instant messaging)
• Calendar and Scheduling
• Document Sharing
• Customized Workspaces
• Rule-based Workflow
• Conferencing, Voting
• Supports Presence Awareness

82
Extant Systems

• 2. Microsoft Office Suite for Collaboration
• LiveMeeting
• World Wide Web-Based Conferencing Support system
• Requires only Internet Connection to a PC
• Can also provide the following along with
  conferencing by integrating
• with MS Office Products such as
• PowerPoint Viewer
• Instant Messaging Chat
• File Sharing
• E-Polls (Instant Voting results among teams)
• Whiteboard
• Outlook Calendar and Scheduler
• MS Excel

83
Extant Systems

• 2. Microsoft Office Suite for Collaboration
  LiveMeeting

84
Extant Systems

• 2. Microsoft Office Suite for Collaboration
  LiveMeeting

85
Extant Systems

• 2. Microsoft Office Suite for Collaboration
• InfoPath Collaborative Information Gathering
  Decision Support
• Enables information gathering through dynamic
  forms. This information can be shared, reused
  across various work processes across teams in
  the organization.
• InfoPath 2003 supports any customer-defined
  Extensible Markup Language (XML) schema and
  integrates with Web services.
• Project Server Project Client Enterprise
  Project Management
• Manages aspects of a Project such as enterprise
  resource management, project timelines,
  deadlines, schedules, tasks, personnel. Project
  Clients can work together to create project
  plans.
• SharePoint Server Collaboration Portal
• Teams can manage personnel information,
  processes, meetings
• Multiple services accessed through Single
  Sign-On
• Document versioning, Approval workflow, check in
  and check out, document profiling, and publishing
• Powerful Search capabilities.

86
Extant Systems

• 2. Microsoft Office Suite for Collaboration
• OneNote Sharable Note-taking management
  system.

87
Extant Systems

• 2. Microsoft Office Suite for Collaboration
• Microsoft Exchange Messaging Collaboration
  Server
• Supports both stationary and mobile clients
  through various protocols such as IMAP, POP3, WAP
  etc.
• Supports sharing Calendars, Schedules, Task
  Management, File Sharing, Rule-Based Workflow and
  filters.
• Other components Outlook, Word, PowerPoint,
  Access, Excel, Instant Messenger etc.

88
Extant Systems

• 2. Groove Virtual Office by Groove Networks
• (Recently Acquired by Microsoft)
• http//www.groove.net/home/index.cfm
• Collaboration and Messaging Platform includes
  services for
• Managing Projects Assign tasks, timelines,
  track progress get status, track resources etc.
• Virtual Meetings conferencing
• File Sharing
• Messaging
• Supports Presence Awareness

89
Extant Systems

• 2. Groove Virtual Office by Groove Networks

90
Extant Systems

• 3. eGroupWare (http//www.egroupware.org/index.php
  )
• World Wide Web-based Groupware platform and
  toolkit
• Open-Source built using only PHP HTML ( uses
  standard RDBMS backend)
• Can create Collaborative applications by using
  existing services for
• Supports Messaging ( Email and Instant)
• Sharing files through Access Control Lists
• Group Calendaring, Scheduling,
• Address Book facility
• Project Management System , Trouble Ticket
  System (Issue tracking)
• InfoLog A kind of CRM (customer-relation-managem
  ent) appliance which uses/includes data from
  Address Book and combines to do-list, notes and
  phone-log.

91
Extant Systems

• 3. Lucane (http//www.lucane.org)
• Open-Source Groupware Toolkit implemented in
  Java.
• Similar to eGroupWare in basic functionality.
• However not Web-based, uses Java-Remote Method
  Invocation.
• Group Projects have a Server and users use client
  programs an be used as a client-server
  application.
• Provides an API where external modules or
  plugins can be added

92
Extant Systems

• 3. Lucane

93
Extant Systems

• 3. BSCW- Basic Support for Cooperative Work
• (http//bscw.fit.fraunhofer.de/index.html)
• Web-based Collaboration Platform Royalty-free for
  academic research, commercial license required
  for commercial purposes.
• One of the precursors to systems such as
  eGRoupWare
• Concept of Shared-Workspaces
• Flow Folders Folders that can be handed-off to
  users during work
• Virtual Spaces for group work.
• E-Polling
• Mobile User Access enabled
• Frozen documents to mark them final ( no change
  allowed)
• Discussion Forums, Calendars, Schedulers
• Reminders and Notification Service
• Multiple-Language Interfaces available
• User Defined Adaptable Workflow

94
Extant Systems

• 3. BSCW- Basic Support for Cooperative Work

95
Extant Systems

• 4. Oxygen Project (MIT)
• http//www.oxygen.lcs.mit.edu
• Aim Bringing abundant computation and
  communication, as pervasive and free as air,
  naturally into people's lives

96
Extant Systems

• 4. Oxygen Project (MIT)
• (reproduced from http//www.oxygen.lcs.mit.edu/Ove
  rview.html )
• To support highly dynamic and varied human
  activities. The Oxygen systems technical
  challenges. It must be
• Pervasiveit must be everywhere, with every
  portal reaching into the same information base
• Embeddedit must live in our world, sensing and
  affecting it
• Nomadicit must allow users and computations to
  move around freely, according to their needs
• Adaptableit must provide flexibility and
  spontaneity, in response to changes in user
  requirements and operating conditions
• Powerful, yet Efficientit must free itself from
  constraints imposed by bounded hardware
  resources, addressing instead system constraints
  imposed by user demands and available power or
  communication bandwidth
• Intentionalit must enable people to name
  services and software objects by intent, for
  example, "the nearest printer," as opposed to by
  address
• Eternalit must never shut down or reboot
  components may come and go in response to demand,
  errors, and upgrades, but Oxygen as a whole must
  be available all the time.

97
Extant Systems

• 4. Oxygen Project (MIT)
• Reproduced from http//www.oxygen.lcs.mit.edu/vide
  oh21visit.html
• Visitor Guide Demo

98
Extant Systems

• 4. Oxygen Project (MIT)
• To Accomplish its Goals Oxygen is comprised of a
  Set of Technologies
• Oxygen Device Technologies
• Equipped with microphone, camera, speaker and
  adapted to be powerful and energy efficient.
• Oxygen Network Technologies
• Cricket Location Service Analogous to Indoor GPS
• Intentional Naming System Discovery based on
  what devices do rather than their location
• Self-Certifying Cooperative File Systems Secure
  data access over untrusted- networks
• Trusted Software Proxies Access remote services
  wihout revealing ones location
• Oxygen Software Technologies
• Goals Architecture To enable software
  components to adapt to changes in the users
  needs and location and continue to deliver
  required services in presence of failures while
  hiding the complexity from the user

99
Extant Systems

• 4. Oxygen Project (MIT)
• Oxygen Perceptual Technologies
• Multilingual and Multimodal User Interfaces
• Oxygen User Technologies
• Haystack Working with Information Not with
  Programs i.e an application that allows users to
  customize their information space and access
  information in a manner bets suited to their
  work.
• Piggy-Bank Semantic Web Support
• START Natural Language Answering System

100
Extant Systems

• 4. Oxygen Project (MIT) - - HayStack

101
Extant Systems

• 4. Oxygen Project (MIT) -- Piggy-Bank
• (http//simile.mit.edu/piggy-bank/)
• Piggy Bank is an extension to the Firefox web
  browser that turns it into a Semantic Web
  browser, letting you make use of existing
  information on the Web in more useful and
  flexible ways.

102
Extant Systems

• 4. Oxygen Project (MIT) -- Piggy-Bank

103
Extant Systems

• 4. Oxygen Project (MIT) -- Piggy-Bank

104
Extant Systems

• 4. Oxygen Project (MIT) -- Piggy-Bank

105
Extant Systems

• 4. Oxygen Project (MIT) -- Piggy-Bank
• Combine information from several web sites and
  browse it all together
• See where coffee shops are located relative to
  restaurants and theatres,
• Find schools and subway stations in the
  neighborhoods of apartments for rent
• Learn how progress has been made in a research
  field by chronologically sorting scientific
  papers, industrial product releases, news
  articles, etc., collected from various sources.
  etc.

106
Extant Systems

• 4. Oxygen Project (MIT) -- Piggy-Bank
• Browse and search through an existing web site in
  better ways than the site allows you to.
• Save information you have found on the Web, not
  as bookmarks but as full database records that
  can later be sorted and searched by any attribute
  they carry.
• Tag each item you save with several relevant
  keywords rather than filing it into one single
  bookmark folder.
• Share the information you have saved by
  publishing it onto a Semantic Bank with just one
  mouse-click.
• Do all that, and more, right inside your current,
  familiar Web browser.

107
Extant Systems

• 4. Skype Peer2-Peer Voice services.
• (http//www.skype.com)
• Users can talk to anyone ( using landline, cell
  phone) over the Internet
• Includes ability to make
• Regular Calls
• Conference Calls
• File Transfers
• Chat
• Maintains Contact lists and events
• (Similar non-voice services are AOL Instant
  Messenger, MS IM)

108
Extant Systems

• 4. Skype Peer2-Peer Voice services.

109
Questions Discussion
Thank You! Ramana.Reddy_at_mail.wvu.edu Sumitra.Reddy
_at_mail.wvu.edu vijay_at_csee.wvu.edu SIPLab Smart
Internet Programming Laboratory http//siplab.csee
.wvu.edu CERC Concurrent Engineering Research
Center http//www.cerc.wvu.edu LDCSEE Lane Dept.
of Computer Science Electrical Engg. at West
Virginia University, USA http//www.csee.wvu.edu