WebOnt Use-Case Area: Web Services

Status: Draft

Version: January 12 2001

Members

Mike Dean, BBN, mdean@bbn.com
Stefan Decker, Stanford University, stefan@db.stanford.edu (Editor)
Tim Finin, University of Maryland MIND Laboratory, finin@cs.umbc.edu
Ora Lassila, Nokia Research, ora.lassila@nokia.com
Lynne Thompson, Unisys Corporation, lynne.thompson@unisys.com
Deborah McGuiness, Stanford University, dlm@ksl.stanford.edu
Ned Smith, Intel, ned.smith@intel.com
Jim Hendler, University of Maryland, hendler@cs.umd.edu

Mailing List

www-webont-wg@w3.org (Archive)
(Web Ontology Working Group)

www-ws@w3.org (Archive)
(Web Services Dicussion List)

 

Scope and Definition

In the following we list so far identified possible usage scenarios of the Web Ontology language for Web Services.

  1. Specification of Web Services. Specification of Web Services and the combination of lower-level Web Services to higher level Web Services may benefit from domain-specific task ontologies and domain-independent process ontologies, which define necessary primitives.
    Examples of such ontologies are the Process Specification Language (PSL) at NIST or DAML-S.
    The following example is an excerpt from a service ontology, which defines a class "Service" and a property "hasSubServices"
    <rdfs:Class rdf:about="&s;Service"> 
    	 <rdfs:comment>A resource representing a certain Service.</rdfs:comment>
    </rdfs:Class>
     
    <rdfs:Property rdf:about="&s;hasSubService">
        <rdfs:domain rdfs:resource="&s:Service"/>
        <rdfs:range rdfs:resource="&s:Service"/>
        <rdfs:comment>A property connecting a service and it's subservices</rdfs:comment>
    </rdfs:Property>

    The following defintion illustrates the usage of the defined vocabulary by defining a service "TravelBooking" witch consists of two subservices "bookHotel" and "bookFlight":

    <s:Service rdf:about="&i;TravelBooking">
        <st:hasSubService>
    <s:Service rdf:about="&i;bookHotel">
    </s:hasSubService> <s:hasSubService>
    <s:Service rdf:about="&i;bookFlight">
    </s:hasSubService> <s:Service>
  2. Advertising and matching Web Services on the Web, in P2P or in mobile environments require description of capabilities of services or devices. Capability ontologies may help to find available services. [1] provides a simple example how ontology-based capability descriptions may look like.


  3. The automated configuration of Services and Devices. Services and Devices need figure out how to meaningfully interoperate even though they were not explicitly designed to do so (e.g., built for different purposes, by different manufacturers, at a different time, etc.). Apart from the adversitising and matching problem (see above) this means solve the following problems:
  4. Easy Integration of Information provided by different services.
  5. Wrapping of Legacy Services. Ontologies can provide a mechanism to integrate and access legacy services..
  6. Trust, Control and Access rights. Information technology is slowly becoming invisible; entering all aspects of our everyday life. Soon IT will be unnoticed and be integrated completely into the environment and computers will become part of a network connecting all devices from clocks to PDAs and cell phones. People will be able to access computing resources anytime and anywhere. This computing, called Pervasive Computing, leads to wirelessly connected and widely distributed systems. These open loosely coupled environments lead to serious security problems. There are similar problems with open networks like the Internet or even widely distributed intranets. Traditionally, stand-alone computers and small networks rely on user authentication and access control to provide security. These physical methods use physical controls to verify the identity of a person or process, explicitly enabling or restricting the ability to use, change, or view a computer resource. However, these mechanisms are inadequate for the increased flexibility that distributed networks such as the Internet and ubiquitous/pervasive computing environments require, as these systems lack central control and in addition, their users are not all predetermined.
    Characteristics of such "open environments" include the following:
    1. Wirelessly connected components
    2. Widely distributed resources
    3. Wireless access via a handheld device
    4. Users who may not be known in advance (e.g., foreign users)
    5. Access rights that are dynamic, i.e. changing continuously
    6. Distinction between role that a user is filling at a given moment and the position the user holds in the organization
  7. User Profile Specification. To personalize a Web Service a user profile is helpful. The elements in the user profile may be specified by an ontology.
  8. Matching and retrieval of entities. Applications require the matchign of entitiy based on their description. The description might be ontology based.
  9. Planning. The automated integration of Web Services requires planning.

Requirements:

The following requirements were derived from the provided use-cases.

 

Published Use Cases

No.: 1
Use Case Type: (3) The automated configuration of Services and Devices
CONTRIBUTOR Ned Smith <ned.smith@intel.com>
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0120.html
CONTRIBUTOR Ora Lassila daml@lassila.org
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0022.html
TASK Device/Service Interoperability/Automated Configuration
Use Cases Description A device (sensors, cell phones, printers) manufacturer builds a device that interoperates with (sensor/actuator) devices built by other manufacturers. The device properties are expressed in ontological form. The ontology of device properties or "device ontology" is embedded in the device. If the device is connected to a network, it can be recognized by and installed into that network by an agent that parses the device ontology and determines how best to integrate its function. Once installed, the device may be bound to other devices forming a composite device. The composite device, logically a unique device, may interact with other devices or services on the network. Device manufacturers are not expected to perform a'priori testing of the possible device configurations to achieve interoperability.
EXAMPLE DOMAIN: Service and Device Interoperability.
TYPICAL USER: Device Developers and Standardization Consortia
ONTOLOGY SAMPLES: n/a
WEBONT REQUIREMENTS
  • The ontology representation language (ORL?) must be simple and concise enough to represent device properties in a small memory space. Devices range in complexity - economies of scale suggests the smaller the space required the better. If the device ontology is unacceptably large, a unique reference to the ontology must be available.
  • The device ontology must be linkable with other devices' ontology forming a distributed ontology with a logical beginning and end / deterministic traversal method.
  • Discrete partitions of an ontology must be recognizable in terms of the physical boundaries and in terms of logical (composite device) boundaries.
  • The device is aware of its own ontological properties.
  • If a composite device has properties in excess of the sum of the properties of subordinate devices, these properties can be physically located on multiple nodes. Device properties may be owned/controlled by multiple entities. The owner/controller may modify property values.
  • Both property type and value can be changed. Type changes can be discovered by other services/devices and type semantics can be resolved - hopefully quickly!
    This points to ontology evolution/change. A is incomplete without being fixed in time. We might think of a more sophisticated URI that is fixed in time and possibly describes a mechanism to move forward/backward ala version histories. It seems to me the primary value of ontologies have over traditional directories is the ability for repositories to interoperate without a'priori agreement. For this to work in a non-trivial case the evolution/change issues have to be worked out.
No.: 2
Use CASE TYPE: 3 (Wrapping of Legacy Services.)
CONTRIBUTOR Ned Smith <ned.smith@intel.com>
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0120.html
TASK Ontology-based Wrapping of legacy services
USE CASE DESCRIPTION A legacy control network performs a process that administrators do not want to disturb. However, they do want to monitor certain functions. They build an ontology of the control network / process and map monitored functions into properties of the ontology. Outside services may discover the control network ontology. Property value changes can trigger notification events sent to outside services. The monitoring functions may NOT introduce delays or in any way prevent the control network from performing its task. The monitoring subsystem may be re-configured by administers periodically and will not impact the monitored control process.
EXAMPLE DOMAIN: Network Monitoring
TYPICAL USER: Network Administrators
ONTOLOGY SAMPLES: n/a
WEBONT REQUIREMENTS
  • Properties in an ontology must be associate-able with a service/function, that supplies the property value.
  • Properties must support access preconditions - namely, the monitoring network should be prevented from writing, while allowing write by the control network.
  • Property values have meta attributes describing data freshness, polling/event interval or freshness goal, type, acceptable value range(s), exception conditions.
  • Administrative update are access controlled and versioned allowing only authorized updates and rollback should an update not work as intended
No.: 3
Use CASE TYPE: 6 (Trust, Control and Access rights)
CONTRIBUTOR Ned Smith <ned.smith@intel.com>
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0120.html
TASK Distributed Network Management
USE CASE DESCRIPTION A control network is managed by multiple outsourced management service providers. Management responsibilities are delegated by the control network owner to the service providers. Management responsibilities are divided among the service providers in such a way as to prevent administration overlap. Management actions are verified to be acceptable prior to their application. Service providers may re-negotiate how responsibilities are divided periodically. After which previously granted privileges are lost and new privileges granted.
EXAMPLE DOMAIN: Distributed Network Management
TYPICAL USER: Network Administrators
ONTOLOGY SAMPLES: n/a
WEBONT REQUIREMENTS
  • Resources in the control network are described by an ontology.
  • Resource can be managed by different / multiple entities.
  • Management responsibility may be delegated.
  • Managed resources have meta attributes describing management functions - namely actions, time intervals, audit log, owner/controller/delegate and synchronization events.

 

No.: 4
Use CASE TYPE: 1 (Specification of Web Services)
CONTRIBUTOR Stefan Decker stefan@db.stanford.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0122.html
TASK Process Description and Device Modeling
USE CASE DESCRIPTION

LastMileServices is a startup aiming to describe static and dynamic aspects of telecommunication devices, with the goal of simplifying service construction and configuration of large networks.

The ontology language is used to define device ontologies (e.g., router and switches) and to definea service description ontology, which defines primitives to declare task decomposition, control flow (using the vocabulary of a UML statechart), and data flow of services.
Other primitives enable to create new services by combining and configuring existing services.
This results in a compositional ontology-based process and service description language capable to combine existing services (given by, e.g., distributed Web Services or Java Objects) with the goal to create new services.A service description can be compiled to Java code and be executed.

EXAMPLE DOMAIN: Telecommunication
TYPICAL USER: Service Designer and Developer
ONTOLOGY SAMPLES: n/a
WEBONT REQUIREMENTS
  • We expect the modelers to be people not familiar with Knowlege Representation. Thus the language needs to be intuitive understandable and easy to visualize
  • Third party vendors are expected to write support software. Thus developers without a background in Knowledge Representation must be able to use API.
  • We want to be able to verify, that a modeled device complies with the constraints defined in the ontology.

 

No.: 5
Use CASE TYPE:

(4) Easy Integration of Information provided by different services.

(5) Wrapping of Legacy Services.

CONTRIBUTOR John Stanton StantonJ@ncr.disa.mil
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0000.html
TASK Interoperability between Different Software Products
USE CASE DESCRIPTION

Formal methods is not so much meant to focus on formal methods of expression as in -
context-free or context-dependent requirements expressed by narrative rules; or doing our own variant of Backus-Naur Form. What I mean is a connected; iterative standards development process that connects the standard under definition; the model; and a conformance testing system as they evolve TOGETHER. If all three of these elements evolve together in a clearly defined, intentional process, DOD can save money, and many other wondrous events can also occur.

We purchase as much software as a Fortune 50 company. When we encounter a product that is 99% interoperable, the other 1% costs us millions of dollars to transport across platforms; or engineer expensive, weird work arounds that then require expensive life-cycle maintenance.

When encountering this 1% non-interoperability, it can often be traced back to both the lack of formal methods of expression within the standard; but most often to the absence of an intentional overall standards development process, exploiting intentional software engineering, using iteration between the three major elements to produce quality; modeled; tested and evolved products. So... we suffer with these products having no way to test conformance; not understanding exactly what we have purchased, costing millions of dollars.

EXAMPLE DOMAIN: Military
TYPICAL USER: Military
ONTOLOGY SAMPLES: n/a
WEBONT REQUIREMENTS  

 

No.: 6
Use CASE TYPE: (4) Easy Integration of Information provided by different services.
CONTRIBUTOR Deborah McGuinness (dlm@KSL.Stanford.EDU)
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0032.html
TASK intelligent interoperable e-commerce and Web services
USE CASE DESCRIPTION

- intelligent interoperable e-commerce. Use ontologies for all levels of support including simple things like integrity checks, more complicated support such as ontology merging and mapping to “standard” upper level ontologies such as UNSPSC, etc. Simple early versions of this include electronic yellow pages such as Directory Westfield. More complicated versions of this include real configuration and solutions across complicated domains. Early examples of ontology-enhanced configuration includes work on PROSE/QUESTAR [5].

- Web services. One of the focuses of KSL, Stanford's research over the last 1.5 years has been the confluence of the Semantic Web and Web Services -- self-contained Web-accessible programs, and devices, together with distributed computing architectures. As with DAML+OIL (in the guise of DAML-S), we would like to use WOL to create ontologies of Web Service properties and capabilities. Such annotations would be used to automate Web service discovery, Web service invocation and Web service composition and interoperation.

EXAMPLE DOMAIN:  
TYPICAL USER:  
ONTOLOGY SAMPLES:  
WEBONT REQUIREMENTS  
No.: 7
Use CASE TYPE: (7) User Profile Specification
CONTRIBUTOR H.J. ter Horst herman.ter.horst@philips.com
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0006.html
TASK

automated adaptation of content (media) presentation to users and the context.

USE CASE DESCRIPTION

We assume sensors to exist that conclude which objects (which people, for example) are in a certain room/space (a 'simple' way could involve tagging the objects). The objects are described in an ontology. Also metadata for content is described in an ontology. It is relevant to include information involving people's likes and dislikes, concerning media content, for example.
Sensor detection and such descriptions form the basis for drawing conclusions about the context (living room, office, mobile situation) and to adapt the presentation of content to this context. This may also include the specification of actions, for example used to personalize certain equipment, possibly in a context-dependent way. A natural connection can be made to the subject of collaborative filtering. Ultimately, it is desirable to allow individual modes of expression of user profiles, while being able to make comparisons between different user profiles.

EXAMPLE DOMAIN:  
TYPICAL USER:  
ONTOLOGY SAMPLES:  
WEBONT REQUIREMENTS  


No.: 8
Use CASE TYPE: (8) Matching and retrieval of entities
CONTRIBUTOR Nick Gibbins (nmg@ecs.soton.ac.uk)
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0128.html
TASK

Expert Finding

USE CASE DESCRIPTION

A community of practice is a group of people which are self-selecting by virtue of their involvement in some common activity, such as habitual co-publication or attendance at similar events. We have been developing heuristic techniques for identifying such groups using the structures in an ontology. The expert finding task is related to COPs because experts are often key participants in the COP related to their field of expertise. While it is not necessarily the case that there is mutual awareness between all members of a COP, we believe that the social network which underlies a COP can be used to 'justify' introductions to experts within that COP. In both cases, the knowledge which we use to identify COPs and experts is defined in terms of an ontology.

Footnotes:
[1] http://www.aktors.org
[2] http://www.w3.org/TR/xlink/

EXAMPLE DOMAIN: Work Environment/community of practice
TYPICAL USER:  
ONTOLOGY SAMPLES:  
WEBONT REQUIREMENTS  
No.: 9
Use CASE TYPE:  
CONTRIBUTOR Jonathan Dale (jdale@fla.fujitsu.com)
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0116.html
TASK

Support for agents and agent technologies

USE CASE DESCRIPTION

Both FIPA and Agentcities are aiming towards the pratical application of agents and agent technologies, so they are looking at choosing an ontology representation language (ORL) from a pragmatic standardisation perspective:

  1. To assist in the ontology modelling exercise. Both FIPA and Agentcities are closely related to standardisation and one of the key points that coollaborative ontology modelling promotes is a standarisation of vocabularies across an application domain or domains.
  2. To assist in ontology representation exchange. Initially, we expect that FIPA and Agentcities will develop ontologies in a human-centric, collaborative manner since most application domains that they are trying to define are reasonably small and finite (i.e., bottom up rather than top-down). However, in the future, it will be important that an ORL can also express large ontologies and can reference terms in other ontologies, possibly in other ORLs.
  3. To assist in ontology translation. As the nodes in the network of FIPA-compliant agent platforms increases, so the heterogeneity in the network increases. FIPA is based on a model of uinting heterogeneity through interoperability, and a key feature of a suitable ORL should be like compatibility with other ORLs. If the functionality is too diverse, then translation between ORLs will be more difficult.

One of the goals of FIPA will be to probably pick up where the WebONT group leaves off. That is, FIPA will leave the standardisation of the design aspects of a suitable ORL to groups like WebONT, but will look at the more pragmatic aspects of ontologies, such as ontology description definitions, ontology discovery, ontology translation, etc.

EXAMPLE DOMAIN: Agentcities
TYPICAL USER: Service Designer
ONTOLOGY SAMPLES:  
WEBONT REQUIREMENTS
  • Complexity; how easy is the ORL to learn, use and implement.
  • Size; how big is the ORL and can its functionality be divided into usage layers.
  • Suitability; what specific problems does the ORL address and what problems is it best/worst suited to handle.
  • Adoption; what is the target audience of the ORL and who is likely to adopt its useage
No.: 10
Use CASE TYPE: 4 (Easy Integration of Information provided by different services.)
CONTRIBUTOR Mike Dean <mdean@bbn.com>
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0104.html
TASK

Automation of tasks related to business travel

USE CASE DESCRIPTION

I hope that WebOnt will be used to provide information that's currently available on the WWW (and not currently available on the WWW) in such a way that I can write and/or use programs to automate tasks such as those related to business travel. I'll use that domain as a focus for this
use case.

I generally plan my travel before calling my human corporate travel agent. For flights, I use a copy of the United Airlines Electronic Timetable, which gets monthly (weekly since 9/11) updates in a some sort of compressed binary format (I've made several unsuccessful attempts to extract the underlying data). I like the fact that I can work with this offline (e.g. on an airplane). I'd much prefer to get it in WebOnt format so that I can apply my own preferences, link to other information about airports, etc.

I have a hotel chain that I prefer. For destinations that I frequent often, I know their hotels in the area but often forget some of the details (e.g. which ones serve good hamburgers, and which room locations to avoid). For others, I look up information on their web sites. I'd like to get this information in WebOnt format, and to add my own properties for items of personal interest.

I normally try to get a hotel room that has high-speed wired or wireless Internet access. Hotel web sites are very inconsistent in reporting this service. For an unfamiliar property, I generally look at the directories maintained by the major ISPs serving hotels (CAIS, STSN, Wayport, and MobileStar), none of which currently provide the information in an agent-friendly format (most use maps, page hierarchies, and/or PDF). I'd prefer to get it in WebOnt and merge it myself with my itinerary and other geographic
information.

When I make a reservation, my corporate travel agent emails my itinerary in a format that I consider a canonical example of the "un-Semantic Web": a PDF image of a traditional FAXed itinerary. This prints well, but is virtually impossible for a program to process. I'd prefer to get this content using WebOnt, and to have it automatically routed to a personal travel agent program. I'd like to automatically share some of my itinerary information (e.g. travel dates and arrival times) with my co-workers, but keep some of it (e.g. credit card numbers) private.

After my airline ticket is booked, I generally have to call the airline directly to get an upgrade and/or better seat assignment. I prefer non-bulkhead (so I can keep my laptop
under the seat in front of me) window seats. United is unable to track this preference, so I often have to make several calls. An agent would be better (and more reliable!) at this task.

I now subscribe to United's Flight Paging Service, which automatically sends an email message to my pager 2 hours before my flight or whenever a delay or cancellation occurs. I'd prefer for my agent to get this information in WebOnt format so that it could automatically begin identifying alternative flights and routings when a problem arises.

I also subscribe to a free service from fly.faa.gov, which sends me email messages on ground stops and delays at specified airports. Unfortunately, it's not linked to my itineraries, so I get lots of such messages while I'm not travelling. If the information was in WebOnt format, my agent could easily cross-reference it with my itineraries and identify relevant problems.

While I travel, I'd like to have fast access to my itinerary using a utility like PalmDAML [1] on my PDA.

When I have a substantial wait at an airport, I like to look for high-speed Internet access. I've generally had better luck searching concourses than web pages to find such services; I'd like to get such information (translated to) my preferred WebOnt ontology. I sometimes go to the American Airlines Admirals Clubs to use their high-speed MobileStar wireless Internet access points. This is usually in a different terminal, so I'd like to also get WebOnt information on gate locations and walking times.

When I go to an unfamiliar city, I often try to rent a Hertz car with a NeverLost GPS. Rather than painstakingly toggling in the street names and numbers for my hotel and other destinations, I'd like to just beam the information in WebOnt format from my PDA using IR or Bluetooth.

I'd also like to get additional information that's not generally now on the web: service hours for restaurants (and room service) along my travel route. For flights that get in late, for example, my agent could tell me if I need to grab a bite before leaving the airport.

When I return from a trip, I have to fill-out an Excel spreadsheet for my expense report. Most of this information could come directly from my itinerary, hotel bills, and credit card receipts if they were provided in WebOnt format.

I already have a DAML application [2] for reconciling my expense reports with my credit card statements and checking account.

A few observations:

1) most of this information (flight schedules, travel itineraries, hotel addresses, expense reports, etc.) is not ontologically sophisticated

2) much of the information is already available in human-readable form

3) automation currently exists only in specific stovepipes such as United's new Flight Paging Service

4) even a highly-motivated geek finds it impractical to merge the existing information

5) with widespread use of WebOnt, we should be able to do most of these things pretty easily

[1] http://www.daml.org/PalmDAML/

[2] http://www.daml.org/2001/06/expenses/

EXAMPLE DOMAIN: Personal Services
TYPICAL USER: Business Traveleler
ONTOLOGY SAMPLES:  
WEBONT REQUIREMENTS  
No.: 11
Use CASE TYPE: 9 (Planning)
CONTRIBUTOR Jonathan Dale <jdale@fla.fujitsu.com>
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0137.html
TASK

 

USE CASE DESCRIPTION

The organisation of an evening of events for a user, based upon location context information, service availability and user preferences. This will require:

  • determining and locating the required services from a directory service,
  • negotiating with each service for availability, etc.,
  • planning a set of events, and,
  • booking the necessary events.

As part of the service determination/matching process, ratings and review services may also be consulted to find closer matches to user preferences (for example, consulting reviews and rating of films and restaurants to find the 'best').


EXAMPLE DOMAIN: B2C entertainment and travel
TYPICAL USER: Either a mobile user who is connecting through a PDA or a fixed user connecting through a desktop. Someone who typically uses location-oriented, Web-based services at the moment, such as citysearch.com or yahoo.com, but requires more precise preference specification and automated organisation and booking facilities.
ONTOLOGY SAMPLES:

The work will produce various ontologies, mainly for talking about cinemas,
restaurants, transportation. Some sample ontologies can be found at:

http://liawww.epfl.ch/~acities/Lausanne/Services/descriptions.html
http://leap.crm-paris.com/agentcities/Services/descriptions.html

Other ontologies are required for service location and negotiation and can
be found in at: http://www.fipa.org/specs/fipa00023/

WEBONT REQUIREMENTS

Consideration for:

  1. representation and use of ontologies across different service domains
  2. distributed location of ontologies across the Internet
  3. potentially different ontology representations for each ontology (ontology translation)
  4. simple ontology representation, but with capabilities to support planning
No.: 12
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Smart Meeting Room

USE CASE DESCRIPTION

Consider a Smart Meeting Room, where the environment has sensors to allow relevant information to be collected about the attendees of the meeting and the environment provides access control to the resources in the room.

A user decides to have a meeting and tells his agent to arrange a meeting with a certain group of users. The agent contacts the agents of the other attendees and they negotiate a date and time. Then the organizer's agent checks the room availability and sends a message to the appropriate room with the tentative list of attendees. The room updates its schedule. When a user walks in, her/his RFID is scanned and his identity is verified. Based on the prior knowledge about the meeting the room sets the role of the user as guest, attendee, organizer, speaker etc. and assigns her/his access rights. When the organizer walks in, she/he is given the right to access the computer, projector, printer, coffee maker etc. Whereas a guest can only access the coffee maker. An organizer can delegate some of his rights to another attendee or guest based on the policy of the room. Some rooms may not allow the right to the use the projector to be delegated, or the right to use the networked computer to the delegated. When the speaker walks in, the room identifies her/him. The speaker can send her/his slides to the projector and the projector will accept them and start displaying them. The speaker can also allow all the attendees to download her/his notes and other information on her/his mobile device but allow guests to only download the slide handouts.


EXAMPLE DOMAIN: meeting room
TYPICAL USER: attendees of a meeting
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Authenticating users
  2. Role based access control
  3. Wireless access to resources
  4. Allow users to set access rights to their own resources
  5. Delegation of some access rights
No.: 13
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Visiting Lecturer/Speaker

USE CASE DESCRIPTION

Carol, an executive in an organization is asked to give a talk in a University on a decided date and she accepts. On the predetermined date, she drives into the campus and looks for a place to park. The 'parking lot controller' recognizes her as a visitor and gives her directions to the visitors' parking lot on her PDA. She parks her car and tries to find the right department. Again as a visitor, she gets directions from the parking lot 'controller'. She finally finds the correct room and decides to set up her slides. The room recognizes her as a visitor and checks if she is supposed to be the speaker. The room has been notified that Carol is the speaker for today. As a speaker, Carol can access the projector but not the printer. She realizes that she has forgotten to print her handout. Her host delegates to Carol the right to use the faculty printer only for printing handouts, for the next 10 minutes.

EXAMPLE DOMAIN: Schools, Universities, Offices that invite speakers
TYPICAL USER:  
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Authenticating foreign users
  2. Constraints on the delegation
No.: 14
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Requesting access rights

USE CASE DESCRIPTION

A Masters student in a University has just completed his Masters project and has included images in color. He decides that he would like to print color copies of his project. The only color printer is the faculty printer, that he does not have access to. He requests his advisor to allow him to use the printer. The advisor considers his students request and decides to grant it as the student is trustworthy. The advisor delegates to the student the right to use the faculty printer for one day and not print more than 100 pages. The student sends his job to the printer. The printer checks the job and finds that it is from a student, then it checks if there has been any delegation to the user from someone authorized to make delegations. As there is a delegation and it is still valid, the print job is allowed to go through.

Another similar example is when the student requests permission for a group of students to use the faculty printer. If this group is predetermined, the advisor can create a group delegation. But if this group of students cannot be decided in advance, the advisor can give the requesting student the right to re-delegate the right to the printer for a certain period and to a certain group of students, for example research assistants or students with GPA greater than 3.5.


EXAMPLE DOMAIN: Universities, offices where access to certain resource
is restricted
TYPICAL USER:  
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Unique identification of resources
  2. Requesting access rights
  3. Delegating to a group of users
  4. Allowing redelegation
  5. Restriction redelegation

 

No.: 15
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Database driven websites

USE CASE DESCRIPTION

For websites with frequent updates and a large amount of information management like CNN or MSN, there are a number of designated data entry operators that are allowed to modify and add certain kinds of information on the website. These operators are managed by editors, who approve the changes before they are visible on the website.

If an editor is unable to complete his duties for a day, and the workload is extremely heavy, he can delegate some of his duties to a data entry operator that he trusts for a limited time period. So the work can continue as normal, with the operator authorizing the changes on behalf of the editor. Once the editor is back, the operators rights revert to normal and the editor continues with his tasks. In a normal scenario, the system administrator would have to be involved, who would create a new login for the data entry operator or change his access rights for the day and then change it back a day later.

EXAMPLE DOMAIN: Large news sites like CNN, New York Times or community
sites like slashdot, ittalks.org etc.
TYPICAL USER: Editors, users who add news items
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Along with role based access rights, there should be a way of delegating access rights without changing the users roles.
  2. Delegation should be restricted by time
  3. Users should only be able to delegate certain rights, not all their rights. For example, the editor should not be able to delegate to the operator the right to view certain confidential information.

 

No.: 16
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Intranet

USE CASE DESCRIPTION

Generally in organization information access is restricted by roles that are arranged in a hierarchy with rights becoming more restrictive as you go down the hierarchy. For example, a software engineer has fewer access rights than his manager. Certain roles have certain access rights. A manager decides that she cannot complete working on some confidential document. Her secretary does not have the right to view or change that document. She trusts her secretary and delegates to her secretary to right to modify a portion of that document. She continues working on a section of the document while her secretary works on another portion.

EXAMPLE DOMAIN: Any Intranet
TYPICAL USER:
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Need not be strictly wireless
  2. Information sharing
  3. Delegation can override role based access control

 

No.: 17
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Security between different offices of the same company

USE CASE DESCRIPTION

Let ABC be a company with several offices all over the country. John, an employee of the New York office, visits the Los Angeles office for a training program. He walks in with his PDA and cellphone. His personal agent on his PDA contains information that authenticates him at the LA office. The LA office figures out his role in the NY office and assigns him certain access rights. John needs to check his email, so he sits down at a terminal. The terminal negotiates with his agent and decides to allow him to use the internet. John then decides to go to the meeting room where the training program is being held. His agent looks around for a service that will give him directions to the appropriate room. As John is enrolled in the program and an employee of the company, he is allowed to use the mapping service that directs him to the right room. John receives a phone call from his secretary at the NY office telling him that he forgot to sign some extremely important papers. Now his agent has to locate a fax service or some combination of services that will allow him to receive a fax. Whether he can actually access the services will depend on his credentials and the security policy of the company, the policy of the LA branch and the access control information of the services.

EXAMPLE DOMAIN:
TYPICAL USER:
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Authenticate users within the same organization but from different offices

 

No.: 18
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Security between Heterogeneous Systems

USE CASE DESCRIPTION

Let XYZ be a company that is providing the company ABC with consulting services. So different employees from XYZ, often visit the offices of ABC. Consider Marty, a consultant from XYZ, who walks into ABC's office in Virginia. He is be able to open doors, put on lights, access the coffee maker, use a certain workstation, but not log into a server, or use the fax machine or enter the mainframes room etc. Another employee of XYZ, Susan, should have different rights from Marty, because she may be a manager or work in a different department or be in charge of another project etc.

EXAMPLE DOMAIN:
TYPICAL USER:
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. Authenticate foreign users
  2. Understand in some way roles of other systems and use them to decide access rights

 

No.: 19
Use CASE TYPE: (6) Trust, Control and Access rights
CONTRIBUTOR Tim Finin finin@cs.umbc.edu
URL http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0153.html
TASK

Medical database

USE CASE DESCRIPTION

Alice decides to go to the hospital for a general checkup. Her personal agent goes out and contacts her hospital to make an appointment. Her agent checks her calendar and negotiates with the hospitals agent to find an appropriate slot. It is for the next day at 12.00, when Alice has time off from work for lunch. Alice goes to the hospital for her appointment and meets Dr.Jonhson. Dr. Johnson uses her mobile or embedded device to view Alice's medical history to know what she should be aware of and be looking for. She decides that Alice needs an X-ray of some sort and asks the nurse to take one. The nurse in turn needs to access a certain portion of Alice's medical history that deals with why the X-ray is needed and what portion of Alice's anatomy should be involved, but the nurse should not be able to view Alice's entire history. Once the X-ray is taken, Dr. Johnson goes on with the rest of the checkup and decides to ask for a second opinion. A doctor from another hospital, Dr. Smith, is called in. Dr. Johnson delegates some of her 'doctor' rights to Dr. Smith, so that Dr. Smith can use certain equipment, access certain parts of the hospital's knowledge base and view a part of Alice's medical records. Dr. Smith goes through all the information and declares that Alice is fit.

EXAMPLE DOMAIN:
Hospitals, clinics
TYPICAL USER:
Doctors, nurses, administrative staff
ONTOLOGY SAMPLES:

 

WEBONT REQUIREMENTS
  1. The system should allow foreign entities to access entities within the system
  2. As rights are dynamic, the system should not follow strict Role Based Access Control
  3. Rights can be tailored for each entity
  4. The system should be easy to configure and maintain.
  5. Delegations should be possible with constraints attached to the
  6. delegatee, time, the action and redelegation

 

 

 

  • References

    [1] http://www.argreenhouse.com/InfoSleuth/publications/agents2000.pdf