ARCHEOGUIDE application scenarios

3,421 views
3,330 views

Published on

1 Comment
1 Like
Statistics
Notes
  • Hello
    My name is ruth. I was impressed when I saw your
    profile (www.slideshare.net) and I will
    like you to email me back to my inbox so I can
    send you my picture for you know who I believe am.i
    we can establish a lasting relationship with you.
    Also, I like you to reply me through my
    private mailbox and (ruthjohnson120@yahoo.com).
    That's why I do not know the possibilities of
    remaining in forum for a long time.
    Thanks, waiting to hear from you soonest.
    ruth.
    (ruthjohnson120@yahoo.com).
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,421
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

ARCHEOGUIDE application scenarios

  1. 1. Project Acronym: ARCHEOGUIDE Project Title: Augmented Reality-based Cultural Heritage On-site GUIDE Contract Number: IST-1999-11306 Starting Date: 01-01-2000 Ending Date: 01-06-2002 Deliverable Number: D04 Title of the Deliverable: ARCHEOGUIDE application scenarios Task/WP related to the Deliverable: WP1, Task 1.1, 1.2, 1.3 Type (Internal, Restricted, Public): Public Author(s): Consortium Partner(s) Contributing: All Contractual Date of Delivery to the CEC: 30-06-2000 Actual Date of Delivery to the CEC: 27-06-2000 Project Coordinator Company name: INTRACOM S.A. Name of representative: Nikos Ioannidis Address: 19.5 Km. Markopoulou Ave. Peania, 19002 Greece Phone number: +30 (1) 6860349 Fax number: +30 (1) 6860312 E-mail: nioa@intranet.gr Project Web Site Address: archeoguide.intranet.gr
  2. 2. ARCHEOGUIDE IST-1999-11306 Table Of Contents 1. INTRODUCTION.............................................................................................................6 1.1. PURPOSE....................................................................................................................6 1.2. GENERAL OBJECTIVES OF THE PROJECT.....................................................................6 1.3. SYSTEM CONTEXT......................................................................................................6 1.4. OVERVIEW OF THE REPORT........................................................................................7 2. ACTORS, SCENARIOS AND COMPONENTS...........................................................8 2.1. ACTORS IN THE ARCHEOGUIDE PROJECT...............................................................8 2.2. APPLICATION SCENARIOS...........................................................................................9 2.2.1. On-Site Virtual Guide Application Scenario.........................................................9 2.2.2. Off-Site Virtual Guide (remote information retrieval) Application Scenario......24 Content Creation Application Scenario........................................................................27 2.2.3. Virtual Human Representations Application Scenario........................................39 2.3. FUNCTIONAL COMPONENTS......................................................................................40 3. GENERAL REQUIREMENTS.....................................................................................42 3.1. SITE VISITORS..........................................................................................................42 3.2. CONTENT CREATORS................................................................................................42 3.3. ARCHEOLOGISTS.......................................................................................................43 3.4. SCIENTISTS ..............................................................................................................43 3.5. SITE MANAGERS .....................................................................................................43 3.6. SYSTEM ADMINISTRATORS.......................................................................................43 3.7. TABLE OF GENERAL REQUIREMENTS........................................................................43 4. SPECIFIC REQUIREMENTS.......................................................................................47 4.1. ON-SITE VIRTUAL GUIDE ........................................................................................47 4.2. OFF-SITE VIRTUAL GUIDE .......................................................................................49 4.3. CONTENT CREATION ...............................................................................................50 5. TECHNICAL CONSTRAINTS / MEASURABLE OBJECTIVES...........................56 5.1. MOBILE UNIT...........................................................................................................56 5.1.1. Memory / Processing power.................................................................................56 5.1.2. Wireless LAN bandwidth / Hard disk space.........................................................56 5.1.3. Rendering / Visualization.....................................................................................56 5.1.4. Audio output/input...............................................................................................57 5.1.5. Connectors / Slots................................................................................................57 5.1.6. Data formats........................................................................................................57 5.2. SERVER HARDWARE................................................................................................57 5.2.1. Multi-processor system........................................................................................57 5.2.2. Memory capacity..................................................................................................58 5.2.3. Network Cards......................................................................................................58 5.2.4. Video Card...........................................................................................................58 5.2.5. Hard Disk.............................................................................................................58 5.3. MEASURABLE OBJECTIVES........................................................................................58 6. CONCLUSIONS..............................................................................................................60 7. APPENDIX A – SURVEY OF RELATED APPLICATIONS AND TECHNOLOGIES..............................................................................................................61 2 of 168
  3. 3. ARCHEOGUIDE IST-1999-11306 7.1. HARDWARE/SOFTWARE AND SYSTEM SURVEY........................................................61 7.1.1. Wearable computers / Notebooks.........................................................................61 7.1.2. HMDs / Displays..................................................................................................73 7.1.3. Interaction Devices.............................................................................................84 7.1.4. Communication infrastructure.............................................................................88 7.1.5. Virtual Human Representation............................................................................89 7.2. TRACKING SYSTEMS.................................................................................................91 7.2.1. Introduction..........................................................................................................91 7.2.2. Different approaches on tracking:.......................................................................91 7.2.3. Some Advantages and Disadvantages of typical Tracking Systems....................95 7.2.4. Example for a possible Hybrid Tracking Technology.........................................97 7.2.5. Sources.................................................................................................................99 7.2.6. Survey of GPS-related technologies...................................................................100 7.2.7. GPS use on Tracking Systems............................................................................105 7.3. DATABASE FOR CONTENT REPRESENTATION CONSIDERATIONS................................122 7.3.1. Survey of related standards................................................................................122 7.3.2. The Core Data Standard for Archaeological Sites and Monuments.................126 7.3.3. The Dublin Core: Metadata on Archaeology....................................................128 7.3.4. Internet Survey of Sites on DB Standards on Archaeology...............................130 7.3.5. Geographic Information Systems.......................................................................133 7.3.6. Projects and References.....................................................................................135 7.4. PROTOCOLS / (DE FACTO) STANDARDS...................................................................136 7.4.1. MPEG-4.............................................................................................................136 7.4.2. XML....................................................................................................................136 7.4.3. VRML.................................................................................................................139 7.4.4. X3D eXtensible 3D.............................................................................................140 7.4.5. PHYTON.............................................................................................................141 7.4.6. UML – Unified Modeling Language..................................................................141 7.4.7. 3DML.................................................................................................................143 7.4.8. Integration of Animation....................................................................................144 8. APPENDIX B - SURVEY OF RELATED PROJECTS............................................145 8.1. EC-PROJECTS.........................................................................................................145 8.1.1. AQUARELLE.....................................................................................................145 8.1.2. ENREVI..............................................................................................................145 8.1.3. PISTE.................................................................................................................146 8.1.4. STARMATE........................................................................................................146 8.1.5. TOURBOT..........................................................................................................147 8.2. NATIONAL PROJECTS..............................................................................................147 8.2.1. ARVIKA..............................................................................................................147 8.3. OTHER PROJECTS....................................................................................................149 8.3.1. Columbia University .........................................................................................149 8.3.2. Carnegie Mellon University ..............................................................................150 8.3.3. Georgia Tech .....................................................................................................150 8.3.4. University of California, Berkeley ....................................................................151 8.3.5. University of North Carolina ............................................................................151 8.3.6. Massachussets Institute of Technology .............................................................151 8.3.7. University of Toronto ........................................................................................152 8.3.8. HRL Laboratories .............................................................................................152 8.3.9. US Navy .............................................................................................................153 3 of 168
  4. 4. ARCHEOGUIDE IST-1999-11306 8.3.10. IBM Research ..................................................................................................153 8.3.11. Rockwell Science Center .................................................................................153 8.3.12. ATR .................................................................................................................154 8.3.13. Sony CSL .........................................................................................................154 8.3.14. Keio University ................................................................................................154 8.3.15. University of South Australia ..........................................................................155 8.3.16. LORIA .............................................................................................................155 8.3.17. INRIA ..............................................................................................................155 8.3.18. TU Wien ..........................................................................................................155 8.3.19. Fraunhofer-IGD...............................................................................................155 8.3.20. EML (European Media Lab) ...........................................................................156 8.3.21. Conferences......................................................................................................156 9. APPENDIX C - QUESTIONNAIRES.........................................................................158 9.1. EXPERTS’ QUESTIONNAIRE.....................................................................................158 9.2. VISITORS’ QUESTIONNAIRE....................................................................................164 4 of 168
  5. 5. ARCHEOGUIDE IST-1999-11306 Executive Summary This deliverable has as its main purpose to identify the actors involved in the ARCHEOGUIDE project, to describe in detail their requirements and to describe in detail its application scenarios. The report also identifies the various functional modules of the system and their interactions. It is important to stress that the requirements described in this document will form the basis on which the whole project will be designed and built. In this report, we also provide a detailed survey of the state-of-the-art in enabling technologies and related applications. 5 of 168
  6. 6. ARCHEOGUIDE IST-1999-11306 1. Introduction 1.1.Purpose This deliverable has as its main purpose to identify the actors involved in the ARCHEOGUIDE project, to describe in detail their requirements and to describe in detail its application scenarios. The report also identifies the various functional modules of the system and their interactions. It is important to stress that the requirements described in this document will form the basis on which the whole project will be designed and built. In this report, we also provide a detailed survey of the state-of-the-art in enabling technologies and related applications. 1.2.General Objectives of the Project The project has multiple goals, which can be broadly divided in two categories: technological and business oriented. Overall, ARCHEOGUIDE aims at building a system that will provide an electronic personalized guide to cultural heritage sites; it will also provide virtual reconstruction of the monuments of the site thereby dramatically enhancing both user experience as well as monument readability. Another product of this effort will be a database of digitized information about the site together with appropriate authoring tools for population and/or modification of the database, to be used by scientists and archeologists via the Internet. The technological objectives of the project include the following:  Research and development of an accurate position tracking system suitable for outdoors augmented reality.  Development of new intuitive human computer interaction techniques applicable in outdoors environments.  Testing the effectiveness of augmented reality techniques and wearable computers in providing personalized access to cultural information. The technological objectives of the project require intensive research into many diverse new areas: in the fields of Augmented Reality, no position tracking system is currently suitable for outdoor use, nor are there currently available any techniques with the required precision for object registration (i.e. placing the virtual objects in their correct spot.) In the field of intelligent agent technologies, research is needed to understand the behavior of the user from their various multi-modal inputs. It is therefore these scientific and technological areas where the project will advance the state-of-the-art through extensive research. The business objectives of the project include:  Attracting more people to cultural heritage sites by the lure of high technology  Triggering interest for private funding for expanding various modules of the system and deploying them to other sectors or sites. 1.3.System Context There are a couple of contexts within which the ARCHEOGUIDE system applications will be deployed. Within the context of an on-site personalized tour guide, the system will act as a guide for highly customizable guided tours that may be as intrusive as the visitors desire, offering augmented reality enhancements to the site. In the context of digitization, organization and storage of multimedia material about cultural heritage sites, it can also serve as a suit of tools that will enable remote access to information about the sites. 6 of 168
  7. 7. ARCHEOGUIDE IST-1999-11306 It can also serve as a virtual reality world that can be distributed in CD-ROMs (or through the internet) to allow remote “virtual” visitors to explore it (thus enhancing its visibility.) 1.4.Overview of the Report The rest of this report is organized as follows: in section 2.1 the actors involved in the project are identified. We describe the uses of the system by each actor in a number of application scenarios in section 2.2. In this section we make use of UML use cases to describe the functions of the system from the users’ point of view. An outline of the functional components of the system is given in section 2.3. The general requirements of each actor are described in section 3. Then we present more specific requirements dictated either by the application scenarios or by technological constraints (section 4). In section 5 we present the technical constraints and measurable objectives that are implied by the user requirements. Finally we present concluding remarks in section 6. In the Appendix A, we include a survey of the state-of-the-art in enabling technologies and related applications and in Appendix B a survey of related projects. In Appendix C we provide the questionnaires that were used in order to discover users requirements. 7 of 168
  8. 8. ARCHEOGUIDE IST-1999-11306 2. Actors, Scenarios and Components 2.1.Actors in the ARCHEOGUIDE Project The actors involved in this project are divided broadly among users, archeological & cultural researchers and administrators. User actors are divided among site visitors (end users), and content creators. Archeological and cultural researchers are divided among archeologists that are responsible for the (physical) restoration of the site, and scientists responsible for interpretation and readability of the monuments of the site. Administrators are responsible for the proper operation and functionality of the system and the site in general. They are divided between site managers and system administrators. In the following table we describe the responsibilities of each actor next to their UML symbol. UML (Unified Modeling Language) is a graphical language for soft name intensive system modeling and development. Site Manager Site managers are principally concerned with the maintenance of the site, its overall visibility to the visitors and the world. Scientist Scientists responsible for interpretation and readability of remains of a site essentially provide the necessary input to the content creators about the models to be used for the virtual objects. They are also responsible for validating the audio/textual information contained in the database of the system regarding the site and the monuments therein. Archeologists Archeologists responsible for the restoration of the site may use the system to record and document their progress, and also to visualize the desired outcome of the whole restoration process (and demonstrate in the physical space of the site the results of the process before it is complete.) Content Creator Content creators are the users of the system responsible for creating content about a site. They are also responsible for creating user profiles according to various characteristics of the users, and for linking different audio or textual information about objects or areas to user profiles. Multimedia Systems and Tools These are the external tools and system that the user must use in order to prepare the multimedia content required. Examples of such tools are: 3D Studio, Alias / Wavefront, Cinema 4D, Photoshop, Illustrator, Soundforge, etc. 8 of 168
  9. 9. ARCHEOGUIDE IST-1999-11306 Visitor Site visitors are the end users that use the system as a personalized guide that provides a personalized virtual reconstruction of the monuments of the site. System Administrator System administrators are responsible for the installation of the ARCHEOGUIDE system in the site, including installation of all necessary hardware and software equipment. They are also responsible for the seamless and normal operation of the system. 2.2.Application Scenarios 2.2.1. On-Site Virtual Guide Application Scenario General Description This is the major application scenario for the ARCHEOGUIDE system. The actors in this scenario are the on-site visitors and the system administrators. The steps that need to be followed by the actors for an on-site visit using the system are the following: 1. Equipment preparation (system administrator) 2. User Authorization (system administrator, on-site visitor) 3. User Profile Selection (on-site visitor) 4. Guided Tour (on-site visitor) 5. Exit (on-site visitor, system administrator.) Graphically, the next picture shows the flow of events in this scenario. 9 of 168
  10. 10. ARCHEOGUIDE IST-1999-11306 In step 1, the system administrator ensures that there exists equipment available for the visitor to wear (a Mobile Unit, MU), that the hardware and software is up and running, that the system server is also up and running and that the wireless network is also operational. The system administrator then puts the visitor on-hold until they ensure that the number of ARCHEOGUIDE users in the site is below the maximum supported. In step 2, the system administrator asks the user to agree with the operational requirements of the system (e.g. user must agree they will not intentionally break the equipment etc.) Once the agreement is made, and other requirements (such as appropriate lighting conditions or number of concurrent users of the system) are met, the system administrator hands over to the visitor a MU and helps them wear it. In step 3, the user enters information by answering questions the system (the wearable computer) asks them; such information is entered through selections from pull-down menus appearing in the user’s screen (traditional user interfaces.) The nature of this information will be described in the specific requirements for the on-site virtual guide application scenario. For the time being suffice it to say that this information remains anonymous (system does not ask the user their name, social security or other sensitive information so that the user does not feel uncomfortable.) The wearable computer records this information, submits it also via the wireless LAN to the site server and the site server displays a set of guided tour previews for them. The visitor may (or may not) select one of the predefined guided tours. A preview of a guided tour is a list of the titles of the information to be presented to the visitor –in time order- together with information about the total time of the tour etc. The user may even modify a selected tour, by requesting that more information about selected monuments be added. It is important to mention that the user’s profile selected at this point is only a starting point and dynamically adapts during the visit according to the user’s actions (requests for more or less information from the system.) 10 of 168
  11. 11. ARCHEOGUIDE IST-1999-11306 Step 4 is the main step in the scenario. The system guides the visitor in the site in the following manner. The system knows the exact position and orientation of the visitor through advanced position and orientation tracking systems. It gives the visitor therefore navigational instructions about how to enter the site. Once they are in the site, the system retrieves any general information about the site that fits the visitor’s profile and starts the presentation. In the case the user has selected a tour, the system presents the scheduled information. If the system detects a deviation in the user’s path from the expected path of the guided tour it interrupts the presentation momentarily and provides navigational instructions to the visitor about where the nearest area of interest should be. As soon as the user enters an area about which the system has information to present, it starts the presentation. The presentations are of course multimedia presentations. The system displays virtual objects that are reconstruction of the remains of the monuments in the site, and delivers audio and/or textual information about the area and the objects in the area according to the visitor’s profile. The visitor may at any time interrupt this presentation by selecting an object (or area) and request more or all available information about their selection. The system responds by presenting the requested information, and then waits for the user to “resume” the tour. Or the user may request to stop the delivery of information from the system. In such a case, the whole tour (if there is one selected) will be modified to exclude information that was linked to the interrupted information. In the case there is no selected tour, once the system has finished the delivery of information about the current area in general, it starts the delivery of information about the selected objects in the area. Information, in other words, is presented from the general (site, then area) to the more specific (objects in the area, then objects within other objects.) Finally, after having delivered information about each object in the current area, the system provides navigational directions (audio and/or visual in the form of a map in the user’s display) about the next programmed area. Step 5 is the final step in the scenario. The visitor is informed that the tour has finished (or the visitor informs the system of their desire to end the tour) and the system provides navigational directions about the exit. In the exit, the system administrator ensures that the equipment used by the visitor has not been damaged (or else takes the appropriate actions). The visitor optionally provides feedback about the system’s operations. The visitor then departs from the site. Use Case Diagrams In the following we will describe the system using the UML Use Case Model. Use Cases describe the behavior of a system from a user’s standpoint by using actions and reactions. They allow the definition of the system’s boundary, and the relationships between the system and the environment. Use cases address a lack of support in the early object-oriented methods, such as OMT-1 and Booch’91, which did not supply any technique for determining requirements. A Use Case corresponds to a specific kind of system use. It is an image of a system’s functionality, which is triggered in response to the stimulation of an external actor. The complete use case diagram of the On-site tour is illustrated below: 11 of 168
  12. 12. ARCHEOGUIDE IST-1999-11306 Display All Virtual Objects Scientif ic Query General Query Authorize Use On-site Sy stem Administrator Enter Personal Information Track Position Present AudioVisual Information Select Tour Skip Inf o Update Visitor Prof ile Erase All Virtual Objects Interrupt Audio Inf ormation Query Database Select Object Authorize Use Resume Visitor 12 of 168
  13. 13. ARCHEOGUIDE IST-1999-11306 The use cases that are included in the above diagram are described as follows: 1. Enter Personal Information Enter Personal Information Visitor USE CASE Enter Personal Information ACTORS Visitor DESCRIPTION This use case starts when the user picks up the Mobile Unit. The system asks them to enter certain information about themselves using pull-down menus, so as to form a personalized tour for them. The system asks them to enter information about their preferred language for communication (possible choices should include Greek, English, French, German) by displaying the flag of each country. The visitor must pick (only) one category. The system reacts by selecting the chosen language for the rest of the interactions with the users. Then, the system asks them to enter information about their age (which age group they belong to such as child, young adult, adult). The visitor chooses only one category. Then, the system asks them about their education background. Possible choices are elementary, high school, university, and graduate school. User may only choose one option. Then the system asks them about their expertise in archaeology. Possible choices are novice, amateur, expert, professional archaeologist. The visitor may select only one option. Then the system asks them about their interests. Possible options include archaeology, history, culture, science, sports, dance, architecture, and sculpture. The visitor ranks zero or more areas of their interests on a scale from 0 to 10 (10 implying highest interest). 13 of 168
  14. 14. ARCHEOGUIDE IST-1999-11306 The system asks them to confirm their choices. The visitor confirms choice or moves back to previous choices (using the "back" button) to change settings. The mobile unit transmits this information to the site server, which then proceeds to prepare a tour for the visitor. The use case ends. Exceptions: The user at any point (before confirming choices) pushes the "back" button. The system displays the previous menu of choices, and their current choice. The user may now select another option from this menu. 2. Query Database Visitor Query Databas General Query Scientific Query USE CASE Query Database ACTORS Visitor DESCRIPTION This use case initiates when the user requests more information about objects, materials or any other related subjects about the site. Exceptions: The user has not selected any object in the site. In this case, the Query Database use case displays an error message "No object Selected". 2.1. General Query General Query Query Databas USE CASE General Query ACTORS Visitor DESCRIPTION The system provides a list with all the information regarding the selected object. It is possible to have many related topics about that object. In this case the user can reduce the list by giving some limitations. 14 of 168
  15. 15. ARCHEOGUIDE IST-1999-11306 The options used to limit the list of information are: Area Category of monument: temple, statue etc. Material: marble, ceramic etc. Object Periods of time (dates/ years) by which user selects the historic time period Version in the case where there exists more than one version regarding the monument's manufacturing process Category/ type of information reflecting to user's special interests: general, history, sports, arts, music etc. Exceptions: None. 2.2. Scientific Query Scientific Query Query Databas USE CASE Scientific Query ACTORS Visitor DESCRIPTION This use case begins as soon as a site manager, an archaeologist or a scientist carries out a query in the site manager requesting to retrieve information residing in the database. In this case the user selects the table from the list of tables in the database and then performs a query construction following the steps of attribute selection and criteria selection. The user selects a table from the database from a list. Then the system responds by presenting a list of attributes contained in the selected table. We add clauses selecting for each clause an attribute and criteria to form the query. The system responds by returning the results of the query (but not executing any visual or audio 15 of 168
  16. 16. ARCHEOGUIDE IST-1999-11306 objects). Exceptions: None. 3. Erase All Virtual Objects Erase All Virtual Objects Visitor USE CASE Erase All Virtual Objects ACTORS Visitor DESCRIPTION The use case is initiated when the visitor selects the option "Erase All Virtual Objects" from the HMD. The system responds by erasing any virtual objects displayed on the user's HMD, but continuouing the audio presentation of the tour. The use case may be initiated by the Track Position use case automatically too. 4. Present Audiovisual Information Visitor Present AudioVisual Information Display All Virtual Objects USE CASE Present Audiovisual Information ACTORS Visitor DESCRIPTION The use case starts as soon as the visitor enters an area for which there is a scheduled presentation. The visitor enters such an area. The system displays all the virtual objects that were selected by the tour and the virtual objects pre- selected by the visitor. The system starts an audio presentation of the part of the tour related to this area. Exceptions: The user selects an object from a menu 16 of 168
  17. 17. ARCHEOGUIDE IST-1999-11306 of all available visible objects. The system displays the selected object. Include (Interrupt Audio Information). The system then prompts the visitor for a continuation of the tour. Exceptions: The visitor interrupts the audio presentation using the Interrupt Audio Presentation use case. 4.1. Display All Virtual Objects Display All Virtual Objects Present AudioVisual Information USE CASE Display All Virtual Objects ACTORS Visitor DESCRIPTION The use case starts when the visitor selects the option "Display All Visual Objects". The system responds by drawing all virtual objects. Include (Interrupt Audio Information). 5. Interrupt Audio Information Interrupt Audio Information Visitor USE CASE Interrupt Audio Information ACTORS Visitor DESCRIPTION The use case starts when the visitor selects the "Interrupt Audio Presentation" option from their wearable computer. The use case is also initiated by the "Select Object" use case automatically. The system responds by interrupting the audio presentation. Exceptions: If the use case was not manually initiated, and the information presented is about the selected object, nothing happens. 17 of 168
  18. 18. ARCHEOGUIDE IST-1999-11306 6. Select Object Select Object Visitor USE CASE Select Object ACTORS Visitor DESCRIPTION The use case initiates when the user wishes to select an object (that can be as general as the whole site, or as special as an individual wav file containing a piece of information about a column of a temple.) The user navigates through a tree-like structure containing folders: the route folder is entitled "site", which contains information about the whole site, as well as folders containing the areas which comprise the folder, as well as scripts containing guided tours. 7. Skip Info Skip Info Visitor USE CASE Skip Info ACTORS Visitor DESCRIPTION The use case is initiated when the visitor wishes to skip the audio/textual information they are receiving. The system responds with a path of the hierarchy of the information being received for example: Site. Area. Temple. Temple roof. Script k. Paragraph about the builder of the roof. 18 of 168
  19. 19. ARCHEOGUIDE IST-1999-11306 The user selects the level from which they wish to skip the information presentation. 8. Resume Resume Visitor USE CASE Resume ACTORS Visitor DESCRIPTION The use case is available only after the user has interrupted the flow of the presentation. The system resumes from the beginning of the most recently interrupted presentation. 9. Select Tour Select Tour Visitor USE CASE Select Tour ACTORS Visitor DESCRIPTION The use case is only available before the visitor enters the site. The user may select one of a number of predefined tours, which are displayed on the wearable computer's screen. Each tour is categorized as appropriate for a number of user profiles, which are all displayed to the user as well as the title of each tour (e.g. short tour emphasizing games or long tour with scientific details) The system displays a preview of the tour as a drawing on the map, and as a list of information metadata (i.e. title) of every piece of information to 19 of 168
  20. 20. ARCHEOGUIDE IST-1999-11306 be presented during the tour. The user may even edit a selected predefined tour to include certain objects that were not originally included in the tour. 10. Track Position Track Position Visitor USE CASE Track Position ACTORS Visitor DESCRIPTION This use case starts as soon as the visitor starts the mobile unit. The visitor moves in the physical cultural heritage site. The system tracks the position of the visitor continuously using a GPS. The output of the GPS is used to determine the identifiable landmarks near the visitor, so that the image-based position system can search for them. The system determines the position and orientation of the visitor, and sends this information to the mobile unit for presentation control -correct registration and rendering of the objects. The system displays on the screen of the wearable computer the position of the user on a 2D map. The use case ends only when the visitor ends the visit. Exceptions: The image-based system fails to determine the identifiable landmarks within the visitor's eyesight. In this case, the system sends an appropriate message to the mobile unit's presentation control system for further actions to be taken (such as interrupting any virtual object drawing). Exceptions: The GPS fails to determine the visitor's approximate position. The system sends an appropriate message to the mobile unit's 20 of 168
  21. 21. ARCHEOGUIDE IST-1999-11306 presentation control system for further actions to be taken (such as interrupting virtual object drawing, and notifying visitor about loss of position tracking). Exceptions: The user approaches an area outside the covered places. The system issues a warning that the user is moving towards off-limits. 11. Update Visitor Profile Update Visitor Profile Visitor USE CASE Update Visitor Profile ACTORS Visitor DESCRIPTION The visitor may initiate the use case manually at any time, when they wish to modify their profile. The user may modify their profile using this use case by modifying the level of their interests in any of the interests supported by the system. As a side effect, if the user has selected a tour at the beginning of their visit, the system stops the scheduled presentations of the tour. It now selects a new set of objects to present to the visitor according to their new profile. Exceptions: The system may decide automatically to initiate this use case when it detects a consistent pattern of actions from the user that indicates that their profile needs to be changed. 21 of 168
  22. 22. ARCHEOGUIDE IST-1999-11306 13. Authorize Use Visitor Authorize Use Authorize Use On-site Authorize Off-site Use System Administrator USE CASE Authorize Use ACTORS Visitor DESCRIPTION This use case is initiated when the user wishes to use the system. The system verifies that user is allowed to do so and that all necessary resources are available. Exceptions: If the user does not have permission to use the system, the system logs them out. Exceptions: If the resources needed are not available (e.g. not enough wearable computers) the system puts them on hold. 13.1. Authorize Use On-site Visitor Authorize Use Authorize Use On-site System Administrator USE CASE Authorize Use On-site ACTORS Visitor, System Administrator DESCRIPTION This use case is initiated when a visitor arrives at the site and wishes to use the system. The system administrator checks to see that there is equipment available (an operational Mobile Unit). Then they check that all conditions for use of the system are satisfied; such conditions include appropriate weather conditions, lighting conditions, and the number of concurrent users of the system. Exceptions: At least one condition is not met. In this case, the use case starts over again waiting until all conditions are met. Normally, all conditions are met, the system administrator proceeds to obtain an "agreement of 22 of 168
  23. 23. ARCHEOGUIDE IST-1999-11306 use" from the visitor, which states the terms of use of the system and the responsibilities of all parties. Normally, the visitor signs the agreement and then proceeds to use the system (using the Run Mobile Unit use case). The use case has ended. Exceptions: The user does not accept the "agreement of use" in which case the use case ends immediately. 23 of 168
  24. 24. ARCHEOGUIDE IST-1999-11306 2.2.2. Off-Site Virtual Guide (remote information retrieval) Application Scenario General Description This scenario enables scientists, archeologists and other qualified persons to retrieve multimedia information about the site without being present in the site. This scenario is made possible because of the digitization of information about the site in a CIDOC-compliant database. Equally importantly because there exists via the content creation application scenarios a virtual representation of the site (a Virtual Reality world, described in VRML) complete with geographic information –geodesics and other cartographic information- and representations of all static objects in the site –trees, big stones, buildings etc. The actors of this scenario are therefore the off-site visitors of the system. The steps in this scenario are the following: 1. System authorization. 2. Login and personalized tour creation. 3. Off-site information tour. 4. Exit. The figure below shows the flow of events of this scenario. Visitor Login Authorize Use Profile Selection Tours Display Tour Selection/ Modification Moveto Next Area Present Audio/Visual Information Query DBMS Schedule Presentation of Information Visitor System Update ScheduledPresentation of Information Present Audio/Visual Information Exit Moveto Different Area Visitor Login Authorize Use Profile Selection Tours Display Tour Selection/ Modification Moveto Next Area Present Audio/Visual Information Query DBMS Schedule Presentation of Information Visitor System Update ScheduledPresentation of Information Present Audio/Visual Information Exit Moveto Different Area In step 1 the system recognizes the off-site visitor as a valid user. In the case of remote access to the site server via internet, the system asks the visitor for a valid name and password in order to verify that they are indeed authorized users of the system. Step 2 checks the system’s databases for an existing user profile (in this scenario, the user is not anonymous since authorization is required in step 1.) If it finds one, it proceeds to retrieve the user’s profile. Else, it is the first time that the user logs in to the system, and the 24 of 168
  25. 25. ARCHEOGUIDE IST-1999-11306 system asks the visitor for various information in order to create an also dynamically adaptable profile for them. Once this step is finished, the user may proceed to step 3. Step 3. The user starts exploring the virtual reality world contained in the system’s database. The visitor has two options. They may choose the guided tour or the free-roaming tour. In both cases the system behaves as in the on-site guide application scenario step 4, but with different user interfaces since the visitor has no HMD, cameras or microphones to interact with the computer, but rather only a keyboard and mouse. Step 4 logs outs the user upon explicit request, or after the virtual tour has ended. The system keeps a record of all users’ activities so as to statistically process the categorization of the various information about the objects in the database. (For example, if more than 90% of the visitors of the system that were young adults with no athletic interests, interrupted the information about an object deemed as appropriate for young adults with any interests and adults with athletic interests, the system should restrict the appropriate categories of this piece of information to young adults or adults with athletic interests.) Use Case Diagrams The complete use case diagram of the Off-site tour follows: Mov e to Dif f erent Area Display All Virtual Objects Scientific Query General Query Authorize Of f -site Use Enter Personal Information Present AudioVisual Information Select Tour Skip Inf o Update Visitor Profile Erase All Virtual Objects Interrupt Audio Information Query Database Select Object Authorize Use Resume Visitor 25 of 168
  26. 26. ARCHEOGUIDE IST-1999-11306 System behavior is almost the same as in the case of the On-site tour, thus most of the use cases are the same. Two use cases are added, the “Move to Different Area” and “Authorize Off-site Use”: 1. Move to Different Area Move to Different Area Visitor USE CASE Move to Different Area ACTORS Visitor DESCRIPTION This use case initiates when a user during the Off- site tour wishes to move to a different area. The system responds by providing a list with all areas available for off-site visit and the user selects the one he prefers. Exceptions: None 2. Authorize Off-site Use Visitor Authorize Use Authorize Off-site USE CASE Authorize Off-site Use ACTORS Visitor DESCRIPTION The use case initiates when the user wishes to run the system remotely (using a CD-ROM or access the server through the Internet). The system asks the user to enter their login name and password. The user enters this info, and then the system verifies the validity of the user. Exceptions: The user login and password pair is not valid. The system refuses the connection. 26 of 168
  27. 27. ARCHEOGUIDE IST-1999-11306 Content Creation Application Scenario. General Description The Authoring Tool is the part of the application that is responsible for the creation and maintenance of the Site Information Server Database. The actors involved are: • Site managers responsible for the parameterization and non-periodic maintenance of the database • Archeologists and scientists responsible for the scientific data of the database • Content creators responsible for the creation of end-user multimedia information, user profiles, scripts etc. The Authoring Tool will be used periodically by various actors, which may not have sufficient time for learning a complex tool. It is therefore necessary to provide a simple, concise and easy to use interface that will enable casual users to use the system with minimal training. The involved actors can perform the following actions: 1. Site Setup 2. Site Documentation 3. Content Creation Parameterize Site Set Tracking Information Update Site Information Server Update Site Information Server User System SiteSetup Edit Artifact Update Site Information Server Edit Scientific Information SiteDocumentation Update Site Information Server Query Database Select New Object Exit In the figure above we show the flow of events of actions 1 and 2 1. Site Setup 27 of 168
  28. 28. ARCHEOGUIDE IST-1999-11306 The site manager is responsible for the initial setup and any subsequent changes in the system parameterization. This way the site manager can customize the Archeoguide system to the specific needs of his/hers respective site. The Tracking Information required for the site includes all the information related to GIS, fiducial points, site geometry and topology etc. 2. Site Documentation The documentation of archaeological sites and monuments plays an essential role in promoting the understanding, conservation and preservation of the archaeological heritage. Within Europe, a wide range of recording methods are employed in the compilation of inventories, often within a national framework. We have decided therefore, to base our database on the CIDOC Core Data Standard for Archaeological Sites and Museums. There are several advantages to the implementation of the CIDOC standard: 1. Many scientists may already be familiar with the CIDOC standard 2. The interoperability of the database with other international systems is guaranteed 3. The soundness and completeness of the database is guaranteed Archeologists will use the CIDOC-compatible database to thoroughly document the existing archeological site. This database shall be continuously maintained and provide an ongoing scientific reference for ongoing archeological work. However the CIDOC standard is more an inventory of the site in question than a complete documentation system. In order to fully document all aspects of the site and the works in progress we allow users to augment the CIDOC database with any kind of multimedia information that is relevant to the CIDOC entries, in the general form of scientific information. Last but not least, users of the system can perform various queries to the complete database, be that simple hierarchical viewing of the database contents or complex retrieval of objects from the database. The results can be viewed and of course further processed. 28 of 168
  29. 29. ARCHEOGUIDE IST-1999-11306 3. Content Creation Prepare Multimedia Objects Query Database Select Documentation Object User System Create Personalized Information Object Update Site Information Server Create Personalized Tour Script ContentCreation Update Site Information Server Exit Figure 1 Content Creation Flow Archeologists have created a complete and scientifically sound documentation for the archeological site. However this database is suitable only for expert usage (e.g. by other scientists). It is therefore necessary that Content Creators enrich this database with multimedia information suitable for the on-site guide functionality required by site visitors. In the following we describe in a little more detail the steps needed to populate the database (and the tools used.) Multimedia Objects This multimedia information (including Virtual Objects) must be prepared from suitable tools, e.g.: 4. VRML models with 3D Studio MAX 5. Audio sequences with Sonic Foundry 6. Video Sequences with Adobe Premier Personalized Information Objects The Multimedia Objects (MO) must now be integrated into the database created above. To accomplish this, the multimedia objects must be attached to their logical parent from the database. Furthermore the content creator will have to provide additional information about the nature of the object, e.g.: 7. targeted audience (age / education / etc) 8. language 9. estimated presentation duration 10. author / creation date Thus the content creator will have created a new Personalized Information Object (PIO). 29 of 168
  30. 30. ARCHEOGUIDE IST-1999-11306 In order to support coherent pieces of information, as required in the on-site application scenario, the content creator must create Personalized Tours Scripts (PTS). A PTS is simply a pre-selected sequence of PIO, which: 11. is targeted at some specific audience 12. has a specified flow and timeline 13. has an estimated duration Use Case Diagrams The complete diagram for the site and content creation – related use case is presented here. Complex Query Archeologists Parametrize Site Set Tracking Information (fiducial points) Site Manager Multimedia Systems and Tools Categorize Object Hierarchical Selection Prepare Multimedia Objects Create/edit Information Object <<uses>> <<uses>> Create/edit Personalized Tour Script <<uses>> <<uses>> Add / Edit new artifact <<uses>> Add/Edit scientific information <<uses>> Scientist Content Creator Query Database <<uses>> 30 of 168
  31. 31. ARCHEOGUIDE IST-1999-11306 1. Parameterise Site Site Manager Parametrize Site USE CASE Parameterise Site ACTORS Site Manager DESCRIPTION In this use case the site manager is presented with a list of all the configurable parameters in the system. The user can now tailor the Archeoguide system by changing the parameters to match the needs of the specific site. The list of configurable parameters includes: supported languages, areas of interest, parameterisation of the equipment used (camera characteristics), wearable network configuration and more. The site manager is also responsible for the GIS information contained in the database. 2. Set tracking information (fiducial points) Site Manager Set Tracking Information (fiducial points) USE CASE Parameterise Site ACTORS Site Manager DESCRIPTION This use case starts with the site manager placing fiducial points into the archaeological site. The points will be recognized by the user's camera to identify the exact position and orientation of the user. The exact position of the fiducial points, in complete coordinates according to the coordinate system used by the GIS, has to be entered in the system database, for the fiducial points to be 31 of 168
  32. 32. ARCHEOGUIDE IST-1999-11306 correctly recognized. This is a prerequisite for the tracking system to work correctly. 3. Add / Edit new Artifact Scientist Add / Edit new artifact <<uses>> Hierarchical Selection USE CASE Add / Edit new Artefact ACTORS Scientist, Archaeologist DESCRIPTION In this use case the responsible actor creates and maintains the site documentation. This use case begins with the user selecting the parent object for the new object to be created. For each monument / artefact of the site, the user must create a new entry in the site documentation. These entries are hierarchically organized. Then the user can populate the newly created entry with various attributes, i.e. location information, time reference, GIS data, etc. A basic set of attributes is mandatory for every entry, whilst other attributes are optional and are only populated when suitable. Logical objects (e.g. areas) are also allowed. 32 of 168
  33. 33. ARCHEOGUIDE IST-1999-11306 4. Add / edit scientific information Scientist Add/Edit scientific information <<uses>> Hierarchical Selection USE CASE Add / edit scientific information ACTORS Scientist, Archaeologist DESCRIPTION To fully document an archaeological site, more data is needed than provided for by the CIDOC standard. This case begins with the selection of a monument or an artefact from the site documentation database by the user. The user can now augment the object with additional multimedia information (text / audio / video / 3D / etc) as needed. The information entered at this stage is meant to complete the site documentation and NOT for presentation to visitors using the system. 33 of 168
  34. 34. ARCHEOGUIDE IST-1999-11306 5. Query Database Scientist Content Creator Query Database Hierarchical Selection Complex Query USE CASE Query Database ACTORS Scientist, Archaeologist, Content Creator DESCRIPTION Query Database This use case initiates when the user requests more information about objects, materials or any other related subjects about the site. Exceptions: The user has not selected any object in the site. In this case, the Query Database use case displays an error message "No object Selected". 5.1. Hierarchical Selection Hierarchical Selection Query Database USE CASE Hierarchical Selection ACTORS Scientist, Archaeologist, Content Creator DESCRIPTION All the data contained in the database (site documentation, scientific information, PIO, PTS) is presented to the user in a unified view. This view is hierarchically based, so that the user can 'open' and 'close' parts of the site hierarchy, 34 of 168
  35. 35. ARCHEOGUIDE IST-1999-11306 thus 'exploring' the site hierarchy. By a simple 'point-and-click' interface, a user can quickly locate the desired object in the database and select it. 5.2. Complex Query Complex Query Query Database USE CASE Complex Query ACTORS Scientist, Archaeologist, Content Creator DESCRIPTION In this use case a user wishes to locate an object or a range of objects in the database. He can do so by entering a series of attributes about the desired item. The system will locate the items and allow the user to examine them more closely. 6. Prepare Multimedia Objects Content Creator Prepare Multimedia Objects Multimedia Systems and Tools USE CASE Prepare Multimedia Objects ACTORS Content Creator DESCRIPTION In this use case, the content creator prepares the content that will be presented to visitors. This multimedia information (including Virtual Objects) must be prepared from suitable tools, e.g.: 35 of 168
  36. 36. ARCHEOGUIDE IST-1999-11306 1. VRML models with 3D Studio MAX 2. Audio sequences with Sonic Foundry 3. Video Sequences with Adobe Premier By using suitable tools the content creator(s) will prepare the required data files for later integration into the database. 7. Create / Edit Information Object Content Creator Create/edit Information Object Hierarchical Selection <<uses>> <<uses>> Categorize Object USE CASE Create / Edit Information Object ACTORS Content Creator DESCRIPTION This use case starts with the user selecting some object (monument / artefact) from the site documentation database he wishes to augment with more information for the site visitors. The multimedia data with which he wishes to augment the object has been prepared in a separate use case. After adding the multimedia data to the object, the user has to categorize the object. The content creator has now created a new Personalized Information Object (PIO). 36 of 168
  37. 37. ARCHEOGUIDE IST-1999-11306 8. Create / Edit Personalized Tour Script Categorize Object Hierarchical Selection<<uses>> <<uses>> Create/edit Personalized Tour Script <<uses>> Create/edit Information Object Content Creator USE CASE Create / Edit Personalized Tour Script ACTORS Content Creator DESCRIPTION In this use case the user wishes to create a sequence of information objects to be prepared to a visitor, much in the same way a writer prepares a script. This sequence will be called a Personalized Tour Script (PTS). The user must select the database object, for which he wishes to create his PTS. Then he is given a list of all the available Personalized Information Objects (PIO) for this object, as well as all the available PTS for any direct children of this object. He can now select and order a mixture of PIO according to his wishes. The newly created PTS must be also categorized. It is now available, under the selected object, for presentation to the user. 9. Categorize Object Categorize Object USE CASE Categorize Object ACTORS Content Creator DESCRIPTION In this use case the user has to designate the targeted audience for some database object. In order to accomplish this, the user must assign a number of attributes to the object. 37 of 168
  38. 38. ARCHEOGUIDE IST-1999-11306 Examples of this attributes would be: 1. Age {young, young adult, adult} 2. Education {elementary, high school, university} These attributes (and the possible selections) are defined by the site manager. 38 of 168
  39. 39. ARCHEOGUIDE IST-1999-11306 2.2.3. Virtual Human Representations Application Scenario General Description To enrich the tour and make the virtual scenes more dynamic, virtual human representations will be created and inserted. There are some different ways in which a standard VRML avatar might be used. We will present three ways that can be implemented in Archeoguide. All of them will work in either a single or multi-user environment. 1. Simple, Repetitive Key frame Animations If the main objective is to use an avatar that performs some sort of repetitive action, such as "background characters" or "extras", to give some life in the VRML scene, the procedure is simple. The key frame animation sequence is converted into a series of interpolator nodes, which are driven by a Time Sensor with its loop sequence. Conceivably, avatars could share animations. For example, a number of athletes in different parts of the stadium might be driven by the same key frame animation sequence, which means that the sequence data has to be downloaded only once. These avatars and their animations would work equally well in either a single-user or multi- user environment. 2. Multiple Actions, Triggered by Sensors On some applications could be necessary, multiple actions performed by the same avatar, i.e., different animations are associated to the same avatar, to be executed on different periods of time. If this is the case, multiple key frame animation sequences are created for the same avatar file. All the outputs of the interpolators are connected to the avatar, but independent Time Sensor drives them all, which are triggered by automatic or user events. To understand how this might work, consider an athlete warming up (one animation associated to the avatar). Upon a sound display, for example, he begins the race (another animation associated to the avatar). For the example above, a sound sensor trigger and different animations are executed. 3. Multiple Concurrent Animations for the same avatar Other possible situation is the performance of multiple behaviour (animations) simultaneously. For example, if there's an animation sequence for running and another for jumping, the avatar can execute them simultaneously. This simply involves triggering more than one Time Sensor simultaneously. Obviously, problems will arise if multiple animation sequences are all trying to control the same joints or body segments. If this is the case, special care must be taken at implementation phase. 39 of 168
  40. 40. ARCHEOGUIDE IST-1999-11306 2.3.Functional Components The picture below shows the various functional components of the ARCHEOGUIDE system and their interactions. These components are described in more detail below:  Client component: it comprises of  User Input. This module is responsible for providing to the visitor a friendly and easy-to-learn graphical user interface (GUI) that allows them to interact with the system. Novel multi-modal techniques such as gesture recognition and speech processing will be combined with traditional pull-down menus that will be displayed on the user’s HMD or screen of the wearable computer. All these user interfaces allow the visitor to select, retrieve or interrupt information about the area in which they are located.  Client Database. This module is responsible for storing the 3D models (VRML files) comprising the site together with the site cartography and other geographic information. It also stores audio/textual information about the site to be presented to the visitor upon request.  Position Tracking. This module tracks the position of the user continuously with very high accuracy.  Presentation Control. This is the module responsible for selecting the virtual objects to be rendered in the user’s display, for selecting the appropriate audio information to be presented, for ordering this information, and for handling various latencies in the system. It is also responsible for dynamically adapting the original presentation plan (which is a skeleton of an ordered chain of information material to be presented at various times during the visitor’s tour) to include or exclude information.  Multimedia Presentation. This is the functional component responsible for rendering and displaying the 3D models of the selected virtual objects, for playing the audio information selected (when instructed by the presentation control) and for displaying any textual information for navigational help or for user interface purposes (menus on the user’s display.) 40 of 168
  41. 41. ARCHEOGUIDE IST-1999-11306 The client component therefore must at least include the following hardware equipment on the on-site guided tour application scenario:  Head Mounted Display (HMD).  Global Positioning System (GPS) for approximate position tracking.  Camera attached to the HMD and interface to the client computer for image based position and orientation tracking with high accuracy.  Microphone and interface to the client computer for voice input.  Wearable computer (laptop) with keyboard, trackball, fast hard disk, LCD display for traditional user interfacing and processing.  Batteries for electric power.  Server Component: it consists of the following components:  Content Creation (authoring) tools. They are responsible for populating the site information server’s database, which will be used to populate the client databases as well.  Server Database. It is responsible for storing the whole site cartography (together with locations and details of the fiducial points), the content created by content creators for the documentation about the site (according to the ICOM-CIDOC standard), and audio-visual information about the site to be used in the guided tours.  Adaptive Presentation Modifications. This component is responsible for tracking user behavior and automatically updating the scheduled information presentation (expanding and/or reducing the audio information scheduled for presentation to the visitor.) The server component is implemented on a high-end server computer. It requires high processing capacity for handling multiple user requests for audio (and less frequently visual) information, computing any changes in the planned guided tours in real-time by tracking each user’s behaviour, and enough network bandwidth on the server side to transmit the results.  Network Component. The network component is responsible for the wireless transport of client requests to the server side and the subsequent response of the server. The CORBA architecture standard will be used since it allows a uniform and systematic way of defining and using the system’s various components’ interfaces and encapsulates network complexities within it. The network requires certain hardware equipment: access points (AP) will be installed in various places in the site so as to cover in a wireless fashion most of the site area. Fast Ethernet cables will be used for AP interconnection with the server computer. 41 of 168
  42. 42. ARCHEOGUIDE IST-1999-11306 3. General Requirements 3.1.Site Visitors First we shall describe general requirements stemming from the site visitor actors of the system. Currently, cultural heritage site visitors may only get acquainted with the site’s various aspects through the guidance of a group guide. Such guides usually only have limited knowledge of the history of the site, the architectural details of the monuments, the site’s role in the history of the surrounding area or the civilization that created it etc. Detailed knowledge about the excavations in the site or the methodologies used to study it, are not available since such information requires scientific expertise. Furthermore, human guides usually memorize a certain amount of information about some of the most important elements in a site and “lecture” the visitors allowing them little interaction –since the tour always includes more than one person. The nature of these tours forces the visitors to follow a pre-specified path that may not correspond to their individual preferences; in such cases the visitor loses interest in the site very fast, and either mechanically follows the group or abandons the tour altogether. The proposed system provides personalized tours enhanced with multimedia information presentations that offer the potential for a much higher level of entertainment and education. In order however to achieve these goals, it is necessary that the system acts reliably as a personalized source of “exciting” information about the site. The visitors therefore broadly divide their requirements in the following categories: a. Personalized and Context-related Information Delivery: the system should have a good idea of the interests and background of the visitor and deliver information relevant to their surroundings that they will appreciate. Within this category are issues of the quality of the virtual reconstructions of the site’s remains (image resolution, object registration etc.) b. Navigation & Orientation Assistance: this category includes all site visitor requirements for assistance from the system in order for the user to locate objects or places of interest to them in the site (or guide them to the exit or the parking lot.) c. Tours: it includes requirements regarding the behavior of the system while operating in a mode that resembles a single-person tour by an expert human guide. d. User Interaction: this category describes the visitors’ requirements regarding the various interfaces through which they will interact with the system. It includes traditional as well as novel user interface methods since the equipment with which the visitors are equipped allows for much more intuitive user interaction than what is available in standard desktop computers. 3.2.Content Creators The role of the content creators is to create content that is to be delivered to the end users, i.e. the site visitors, as well as the archeological and cultural researchers. They are responsible for populating the central database with multimedia information and organizing it in appropriate hierarchies. Their requirements can be divided in the following categories: a. Authoring Tools for (multimedia) Content: the category describes requirements about the tools needed to create, organize, link and store in the system’s databases multimedia content about the site. 42 of 168
  43. 43. ARCHEOGUIDE IST-1999-11306 b. User Interface: the category describes their requirements about their interaction with the tools in order to quickly organize (create, link, store) the information they prepare about the site. 3.3.Archeologists The role of the archeologists responsible for the restoration of a site –or parts of it- is a combination of a content creator and end user. Their requirements stem from their needs to create visual content, i.e. virtual models of the monuments to be restored, store these models as different versions of information about the same object, and attach to each such version appropriate information about the process that will be used to create it. They also act as site visitors while they use the system to inspect the models they have created. 3.4.Scientists This category of users is responsible for the readability of the monuments. Since they provide input to the content creators (and may in fact be themselves content creators) their requirements overlap with those of content creators. However, they also add some new requirements in one particular application scenario, that of remote access to the system’s database (through intranets or the web for example.) Such access enhances the readability of the monuments. In the following table we describe analytically the requirements gathered from each actor of the ARCHEOGUIDE system. The table describes requirements from these actors that are common in the application scenarios of the system. 3.5.Site Managers As mentioned earlier, site managers are those user actors of the system that are responsible for its overall smooth operation in a way that is beneficial for the site. They require the minimization of the system’s “intrusion” in the site. This single requirement is in fact of paramount importance, because in order to achieve accurate position tracking several fiducial points have to be identified in the field of view of the user. Artificial landmarks (in the form of small labels) serve as easily identifiable fiducial points, and the site managers’ requirements deal with the minimal introduction of such labels in the site. They also require minimizing the impact of the equipment (server computers, network access points, cables between access points and server etc.) to the environment. 3.6.System Administrators The system administrators require tools for the easy installation and monitoring of the system. They also need tools for issue recording (bug reporting to be fixed in subsequent releases of the system.) 3.7.Table of General Requirements Code Origin Description Comments Related URG1 Site Visitors Multi-user capability The system should support many visitors simultaneously. URG2 Image quality The quality of the virtual 43 of 168
  44. 44. ARCHEOGUIDE IST-1999-11306 objects displayed should be as high as possible when the visitor is standing still. At least, simpler objects of the objects should be displayed while user is moving. URG3 Object registration While the user is standing still, the virtual static objects to be drawn must be placed in their correct place and they should not appear to be moving. URG4 Context related information delivery The audio information presented to the visitor should be relevant to their surroundings i.e. only about objects in their vicinity or general information about their surroundings (unless explicitly requested by the user.) URG5 Personalized information delivery The audio information delivered to the visitor should be appropriate to them according to their characteristics or else it should have been directly requested by the user. URG6 Information presentation structure System should display upon request the groups to which the currently presented information belongs. URG7 Information categorization for personalized delivery The information in the system’s databases should be categorized as appropriate for audiences matching the following attributes: 1. age (child, young adult, adult) 2. education (high school, university, graduate, expert archeologist). 3. Interests (general, reading, history, archeology, paleontology, science, athletics, fine arts) Each interest has associated a level (0-10). 4. Expertise (novice, amateur, expert, prof. Archeologist) Each piece of information may be valid for many values of an 44 of 168
  45. 45. ARCHEOGUIDE IST-1999-11306 attribute. URG8 Multilingual information delivery The system should deliver information to a language selected by the user (system should provide support for the most common languages.) URG9 Audio/visual navigational help The system gives directions to user about how to move to certain places when asked. It also provides directions about how to move to the next area of interest when it has presented all currently relevant information to the visitor. URG10 Tours The system should provide guided tours selected by the user. It should also allow him to move freely around the site and ask information about real or virtual objects. URG11 Real-time adaptive behavior The system should adapt to the visitor’s behavior during a guided tour and change the scheduled presentation as appropriate. URG10 URG12 Ease of Use The system should be very easy to use and should not require any learning curve. URG13 Speech controls The system understands simple voice commands by the user: select <object name>, Stop info, Erase [<object>|all], Refresh, More [about <object>] Where is [<object>|exit…] The language available for speech processing should be English. URG14 Point & click The system provides a traditional point & click user- interface available through the user’s wearable computer. URG15 Real-time audio response. The system should respond correctly to unambiguous user input in real-time. It should offer help when user enters wrong commands. URG16 Content Authoring tool The system should provide a 45 of 168
  46. 46. ARCHEOGUIDE IST-1999-11306 Creators for virtual objects. toolkit for creating or modifying virtual objects. URG17 Authoring tool for audio/textual information. The system should provide a toolkit for entering audio/textual information, organizing it in hierarchical structures, linking it to objects in the site and storing it to the database. URG18 Site cartography The system database should contain all the (static) objects of the site together with their exact position. Such objects are trees, monuments etc. It should also contain site geodesic information so that virtual objects can be accurately registered. URG19 Intuitive user interfaces The authoring tools should be easy to learn with no learning curve. URG20 Scientists Remote access System should allow remote access to its databases for retrieval of information. URG21 Site Managers Minimize system’s intrusion to the site. No artificial landmarks on monuments. Minimum artificial landmarks in other places (garbage bins, trees etc.) No cables or large antennas should be visible. URG22 System Admin. Easy-to-use administration tools Installation scripts for the system. Monitoring tools to check server status, mobile units’ status and network status. 46 of 168
  47. 47. ARCHEOGUIDE IST-1999-11306 4. Specific Requirements In the following we describe specific requirements from each actor as they appear in each of the application scenarios outlined before. Those requirements that overlap in most application scenarios have been already classified as general requirements and described above. 4.1.On-site Virtual Guide As already mentioned, this is the main application scenario of the ARCHEOGUIDE system that serves as an on-site guide for cultural heritage sites offering augmented reality enhancements to the overall visitor experience. There are two possibilities for this scenario. In the first, the visitor picks up a mobile unit, enters personal information such as background and interests in the wearable computer and chooses the guided tour option. Then they proceed to follow a guided tour where the system delivers information –according to a coherent order- to them about some objects in their vicinity, and then directs them to the next area in the site that information about it is available. Finally, there is the possibility of a free-roaming tour where the visitor (equipped with the wearable computer) moves around freely in the site. The system displays virtual objects that are of interest to them, and delivers audio information about an area or an object after a direct request from the user. Code Origin Description Comments Related URS1 Site Visitors Lightweight mobile unit. The mobile unit (computer, HMD, earphone, camera, batteries etc.) should be lightweight so that typical visitors can carry it for more than 2 hours without getting tired. URS2 Mobile unit autonomy. The rechargeable batteries supporting the MU should allow 2 hours of autonomous operation. URS3 Wireless infrastructure coverage The wireless coverage of the area should be such so that user can roam freely in the whole area. When network connectivity is lost, user should be made aware of it. For such disconnected areas, all information should reside permanently in the MU databases so that user can still be guided by the system in it (through approximate GPS- based tracking.) URS4 Image visualization rate System should be as fast as possible in terms of frames per second it can support 47 of 168
  48. 48. ARCHEOGUIDE IST-1999-11306 depending on the hardware etc. (goal is about 12 frames per second) even while user is moving. URS5 Visitor speed System should be able to register virtual objects and render them in real-time in as good resolution as possible for user speeds up to 3 km/hour. The resolution should be the maximum that still allows correct registration and rendering at 12 frames per second. URS4 URS6 Audio delivery As soon as user enters a new area and system has finished delivery of previous audio information, the system starts delivering audio information about the area and the objects in the area in a priority order (most important objects first.) URS7 Occlusion handling Real static objects (e.g. trees, small hills) that are between a visitor and a virtual object to be drawn should be modeled and recorded in the database so that they can be displayed giving the user a view of the scene with minimal occlusion errors. URS8 Selection of virtual objects to be displayed All objects of interest to the visitor should be displayed when their location is within 30m of the user. URS7 URS9 Taking photos The user should be able to take a snapshot of their viewpoint and have the server print out a copy. URS10 Manual selection of important topics or objects System should provide to the user the option to select a number of topics or objects from the database about which to receive all available information. Time needed for such information about each object should be displayed to assist user in their decisions URS11 Guided tours Information to be included for delivery should be selected based on indicated user time 48 of 168
  49. 49. ARCHEOGUIDE IST-1999-11306 availability. The system takes into account user profile and any special requests for presentation, computes the time needed for the tour, and then discards information to be delivered based on information importance until tour time matches user’s available time. System should still allow user to obtain more information upon request. Information importance is computed on the fly. URS12 Coherency and non- redundancy of information. Information should never be repeated unless explicitly asked by the user. Information delivery should follow a coherent order within the guided tour. URS13 Archeologists & Scientists Multiple versions of the same virtual object supported and version control In order to accurately record the progress of a restoration process, the system should be capable of recording and displaying according to user commands, different versions of the same virtual object (representing different periods or different points in a restoration process). The system should provide a sense of version control in such cases. URS14 User interface for display of multiple versions System should provide a menu with options about versions of selected virtual object and display in highest resolution possible the user selection. URS13 4.2.Off-site Virtual Guide A subset of the functionality of the system, namely the system’s databases together with the traditional user interfaces of the system and the content browsing tools can be used to provide an off-site guide in a virtual world that is a recreation of the site. This virtual world will be created as a standard virtual reality application on a moderately powered workstation (no augmented reality problems are present here.) This world can be explored the same way that visitors in the real world can explore the site with the superimposed synthetic images. Such functionality is very useful for scientists located in remote locations doing research about the site who wish to find what information is available in digital format. The multimedia capabilities of the system (which can be accessed remotely through the web 49 of 168
  50. 50. ARCHEOGUIDE IST-1999-11306 assuming certain authorization clearing, or through CD-ROMs where the whole software with its content will reside) will enhance the site’s visibility dramatically and facilitate scientific research. Code Origin Description Comments Related URR1 Site Managers Secure access Content about the site should be accessed only by authorized persons. URR2 Scientists & Archeologists Multiple versions of the same virtual object supported and version control In order to accurately record the progress of a restoration process, the system should be capable of recording and displaying according to user commands, different versions of the same virtual object (representing different periods or different points in a restoration process). The system should provide a sense of version control in such cases. URS13 URR3 Image Quality The image quality of the displayed virtual world should be the highest possible for refresh rates of up to 15 frames per second. URR4 User Interface for display of multiple versions System should provide a menu with options about versions of selected virtual object and display in highest resolution possible the user selection. URS13 URR5 User Interface for navigation and content retrieval in the site. System should provide an easy to learn user interface for navigating in the virtual world and accessing information about its objects. Emphasis is on traditional user interfaces such as point & click to highlight, select, edit objects and/or retrieve information about them. 4.3.Content Creation The content creation application scenario defines the approach that is required in order to create (and maintain) the database required for the Site Information Server. As indicated in the corresponding scenario, the database consists of several distinct but interconnected modules: 50 of 168
  51. 51. ARCHEOGUIDE IST-1999-11306 Database Module Responsible Actor Operating parameters and site meta-information (e.g. fiducial points) Site Manager Scientific Site Documentation Archeologists Multimedia content linked to the site documentation Content Creators Guided Tour scenarios Content Creators Before we present analytically the user requirements gathered from the actors of the content creation application scenario, it is worth explaining in a little more detail the organization and structure of the information that ARCHEOGUIDE will record and present. The ARCHEOGUIDE system will follow closely the CIDOC core data standard for archeological sites and monuments. This standard facilitates greatly the tasks that the experts in the field (archeologists and other scientists) face in their day-to-day operations. It helps them retrieve and store information about monuments and archeological sites in a fast and meaningful way. This way we can assure a sound theoretical model for the site documentation that will help avoid wasting resources. Furthermore the adherence to an international standard will greatly facilitate the exploitation of the system in an international level, as well as data exchange or integration with other systems. The theoretical framework about the structure of the information about cultural heritage sites in this standard is a set of four elements:  Archeological items  Archeological groups  Physical spaces  Physical groups Archeological items are the fundamental pieces of archeology. They may be individual artifacts or ecofacts, components of sites or monuments (such as remains of walls) or even complete monuments, depending on the level of the desired granularity for the data. Archeological items may be logically grouped to form archeological groups. An item may be part of zero or more groups and such groups may be based on different logic (an item may belong to the group of artifacts from the hellenistic era, and also belong to the group of items made of gold.) Finally, archeological items occupy physical space, which in turn may be grouped to various groups based on different logical criteria. Next we present the minimum structuring of information required by the ICOM-CIDOC standard (the extensions required by the content creators of ARCHEOGUIDE are described analytically in the table below.) 1. Names & References 1.1 Ref. Number 1.2 Name of Monument or Site 1.3 Date of Compilation 1.4 Date of Last Update 1.5 Ref. Originator 1.6 Cross References to Related Records (set) 1.6.1 Ref. Number 1.6.2 Relationship Qualifier 1.6.3 Ref. Originator 1.7 Cross References to Archeological Collections and Artifacts (set) 1.7.1 Ref. Number 1.7.2 Ref. Originator 1.8 Cross References to Documentation (set) 1.8.1 Ref. Number 51 of 168
  52. 52. ARCHEOGUIDE IST-1999-11306 1.8.2 Doc. Type 1.8.3 Originator of Reference 1.9 Cross References to Archeological Events (set) 1.9.1 Ref. Number 1.9.2 Event Type 1.9.3 Start Date 1.9.4 End Date 1.9.5 Ref. Originator 2. Location 2.1 Administrative Location (set) 2.1.1 Country or Nation 2.1.2 Geo-political Unit 2.1.3 Administrative sub-division 2.2 Site Location 2.3 Address 2.3.1 Name for Address Purposes 2.3.2 Street Number 2.3.3 Street Name 2.3.4 Locality 2.3.5 City 2.3.6 Zip code 2.4 Cadastral Reference/Land Unit 2.5 Cartographic Reference 2.5.1 Cartographic Identifier 2.5.2 Spatial Ref. System 2.5.3 Topology 2.5.4 Qualifier 2.5.5 Sequence Number 2.5.6 X, Y, and Z co-ordinates 3. Type 3.1 Monument or Site Type 3.2 Monument or Site Category 4. Dating 4.1 Cultural Period 4.2 Century 4.3 Date Range 4.3.1 From Date 4.3.2 To Date 4.4 Scientific & Absolute Dates 4.4.1 Date 4.4.2 Method 5. Physical Condition 5.1 Condition 5.2 Date Condition Assessed 6. Designation/Protection Status 6.1 Designation/Protection Type 6.2 Date of Designation/Protection 6.3 Ref. Number 6.4 Ref. Originator 52 of 168
  53. 53. ARCHEOGUIDE IST-1999-11306 In the next diagram we show a logical structure of the database containing information to be presented to the site visitors. The site is divided among areas (and connections via roads, bridges etc.) within which there are a number of objects (monuments, houses, trees, rocks and other physical items) each of which may contain a number of other objects. An object may also be contained in a number of other objects. Finally, the objects in the database may be grouped in categories (e.g. stone tools) in which case, an object may be contained in more than one category. Each object, area, site, and category has attached information (available in many languages) that has descriptors, or attributes, indicating categories of users for which presentation is appropriate. Finally, we present the user requirements for this scenario in a tabular format. Code Origin Description Comments Related URC1 Site Managers Site Customization Site Managers should be able to influence (through the Authoring Tool) all the operating parameters and the site metadata required to customize the ARCHEOGUIDE system to their specific site and its respective requirements. URC2 Archeologists Information Organization about the site to follow The organization and structure of the database should follow closely the Draft International Core Data 53 of 168
  54. 54. ARCHEOGUIDE IST-1999-11306 ICOM-CIDOC standards Standard for Archeological Sites and Monuments. URC3 Site Documentation Archeologists (and other scientific experts) should be able to thoroughly document the site (including places, monuments, museum exhibits, etc). URC4 Site Exploration The Authoring tool should provide an interface simple yet powerful enough, so that scientists (e.g. visiting archeologists) can make use of the same tool to explore the realm of scientific information that has been stored in the database. URC5 Content Creators Multimedia and 3D tools Many kinds of multimedia and 3D (VRML) information can be added to the system. Therefore Content Creators need to have access to a large and appropriate set of tools that will assist them in the task of preparing the multimedia / 3D information for inclusion in the system URC6 Multimedia / 3D linking The multimedia / 3d content has to be embedded in the database and associated with the appropriate parts of the site documentation URC7 Content Access The content creator should be able to view and (again, if possible) edit the content they manage. Especially for 3D models that would mean that a 3D viewing ability of them is highly desirable. This should be possible in a manner following closely the documentation system of the site. URC8 Multimedia / 3D information categorization Audio/textual information to be presented to the visitors should contain attributes indicating appropriate categories of users. Null attributes match all categories. A piece of URG7 54 of 168
  55. 55. ARCHEOGUIDE IST-1999-11306 information will be included for presentation to the user if the values of its attributes match all the attributes of the user profile. URC9 Guided Tours The content creator should be able to prepare sequences of database objects that shall constitute guided tours for some targeted audience. It should be easy to create, view and review the generated sequences (guided tours). URC8 URC10 Information Coherency The information delivered to the visitor should be coherent for all possible visitor profiles. URS12 URC11 Multilanguage support The system should facilitate (wherever possible) the content creator in translating a series of objects or even a complete tour in some other language. URC12 Authoring tools for creating & editing visual models Toolkit should provide what- you-see-is-what-you-get functionality; produce optimized VRML code of manageable size for inclusion in the wearable computer’s database. URC13 Content browsing tool for audio/text information Toolkit should allow user to select from an organized hierarchy of information. Toolkit should automatically detect inconsistencies of information and prompt user in the following cases: 1. Change of information about an object is not cascaded in all supported languages. 2. Information entered about an object that is part of another object matches broader user profiles than parent objects. 55 of 168
  56. 56. ARCHEOGUIDE IST-1999-11306 5. Technical constraints / measurable objectives In the following we describe the technical constraints the system components must follow in order to satisfy the user requirements and provide all the services with acceptable quality and performance. We further list the measurable objectives that are implied by the user requirements. 5.1.Mobile Unit 5.1.1. Memory / Processing power The mobile unit is the central component of the Archeoguide system. Therefore, a lot of different tasks have to be done by this computer, e.g.: • Interaction with the user • Tour scheduling • Position and orientation tracking • Rendering of 3D models • Decompression and visualization of MPEG video streams • Decompression and playback of MP3 audio streams Most of these tasks need a lot of resources in terms of processing time and memory. To provide high quality and little delay of feedback to user requests, the mobile unit should be equipped with a fast processor and plenty of memory. 5.1.2. Wireless LAN bandwidth / Hard disk space Audio and Video streams need a lot of network bandwidth. Most probably, with the existing WLAN technologies it will not be possible to transfer video on the fly with sufficient quality. Therefore, we need to put as much multimedia data as possible onto the build-in hard disk of the mobile unit. Caching strategies can be used to store the most often and most recently requested data on this disk. Prefetching of data most probably used next can be implemented by analysis of the tour schedule and by knowledge about the distribution of points of interest over the historical site. As a conclusion, we need a combination of high WLAN bandwidth and plenty of hard disk space to provide the user with high quality multimedia data and fast feedback to user requests. 5.1.3. Rendering / Visualization The mobile computer has to render the virtual 3D models used to augment the real scene. Furthermore, the computer has to decompress and display all video streams. Because both tasks need a lot of processing power, it is recommendable to have a 3D acceleration card that is capable of rendering 3D models and handling MPEG video streams by hardware. The VR toolkit “Avalon” used for rendering is based on OpenGL. This implies that an OpenGL driver must be available for the 3D accelerator. For decompression of MPEG video streams, we will use the DirectX (DirectShow) application-programming interface. Therefore, a DirectX driver must be available to use any hardware decompression features of the accelerator card. 56 of 168
  57. 57. ARCHEOGUIDE IST-1999-11306 5.1.4. Audio output/input The mobile computer has to handle simultaneous audio input and output, i.e. it needs a suitable sound card. Audio input is needed to control the Archeoguide system by speech. Audio output will be used to play acoustical information. Because audio data may be compressed by data reduction techniques like MP3, the computer has to do decompression work. It is recommendable to have a soundcard that can do this decompression by hardware. For all audio operations, we will use the DirectX (DirectSound and DirectShow) application-programming interface. Therefore, a DirectX driver must be available for the soundcard to use any hardware acceleration features like mixing of multiple audio streams or decoding auf MP3 streams. 5.1.5. Connectors / Slots The Archeoguide system consists of a lot of different hardware components. Most of these components have to be connected to the mobile unit: • Video cameras: There are several ways to connect video cameras to a computer, e.g. FBAS and S-Video connectors, USB and IEEE 1394 ports, and PCMCIA slots. • Tracking systems: For position and orientation tracking, we will use a hybrid tracking system consisting of GPS, video and inertial trackers. These trackers get attached to the computer via RS232 and USB ports or PCMCIA slots. • Connectors for human interface devices like keyboards, mice and joysticks. These devices need PS/2, RS232, game or USB ports. • VGA connector to connect the head mounted display. • A PCMCIA slot for the wireless LAN card. • Connectors for power supply, external CD-ROM drives etc. 5.1.6. Data formats The following data formats will be used by the rendering system: • VRML97 for 3D models • MPEG for video streams • WAV and MP3 for audio streams 5.2.Server Hardware 5.2.1. Multi-processor system Tightly connected processing units (shared-memory) are not a must because of algorithms that must distribute processing to the various processors and perform a lot of fork-join operations. In fact each user request can be handled as a single-threaded process in a single processor. However, the need for large amounts of available memory (to edit perhaps large multimedia objects, and to respond quickly to database requests) is a stronger argument for choosing a shared memory multiprocessor. Systems in this category include the IBM SP/2 multi-processor that is a network of distributed memory computers (running AIX) connected via a high-speed network switch, having a shared-memory simulator running on top to allow shared-memory applications to run. Other true shared memory multiprocessors are available from Sun Microsystems (more than 16 high-performing processors, and a total shared memory easily exceeding 4 GB), SGI, Intel (with top performing Mercer processors) and others. 57 of 168

×