These minutes represent noyhing but the best understanding of the chair at the time of dicussions. Occasionally, I may have misheard something, misunderstood something, or been plain stupid. For clarity, read the position papers as well as the presentations along with these notes.
Second, very few people stated their name and affiliation during questions (despite reminders). The questions are therefore marked with Q, which refer to questions from the floor (also for comments), and answers with A (which refers to the speaker).
The minutes follow the actual agenda, which was substantially different from the agenda published before the workshop.
Brief introduction to the W3C mobile access interest group (so brief that it was not minuted - see the home page of the W3C Mobile activity for more information).
The WAP Forum has numerous activities which need to define location. There has been little coordination. This is true for the entire industry. We want to get a cooperative spirit forward. but fear that the fragmentation will contiume. we will be faced with a lot of marginally open protocols in the absence of an open standard. The best is to get an open standard, this will grow the industry. That is how it works in the fixed/wired side, and it is comung in wireless. Currently, I understand there are 20 different activties working with positioning formats. It will be hard work to pull them together.
In the Telematics Expert Group in the WAP Forum, we defined a number of use cases for location services, starting with the classic emergency use case. That is what got the industry started. In Asia, that is not culturally as much a problem, it seems. The difference between this use case and the se case for breakdown services is that an emergency is when a person needs help, but a breakdown is about equipment, which does not have to be only the car. It can be something that requires a service to be delivered, physically or nonphysically. One possible use case for breakdown services is motorized wheelchair remote servicing, for instance.
Another class of applications is stolen vehicle/client tracking/fleet management. Comes in location dependent. and non location dependent versions.
Location dependent push, to which the user subscribes, is another example of a use case we have defined.
Location dependent pull is anther. Ask for information dependent on location - your typical tourist information or concierge services.
Remote control. diagnostics, programming. These all depends on location, to make the remote control remote.
Asset management is a further usecase. Asset that leave an area they are not supposed to leave can be shut down. Diagnosis remotely can direct them to a special place for service. change vehicle programming based on location, etc (an example can be a vehicle recieving a program that gives more air to the engine when it passes a certain altitude).
The Telematics Expert Group has suffered from terminological confusion as much as anyone else in the business. This has led them to define a set of simple terms.
Position is related to a coordinate system.
Location is position, taking and referencing it to something else.
Posessor, defined as somebody who gathered and can continue to gather information. The group had a terrible debate about the term Owner, which was percieved as nebulous, and it was eventually agreed it was easier to understand the term posessor. Owner may mean somebody else.
Subscriber is who pays the bills.
User is the one who uses the information (device or person).
The requirements that the TEG has developed are:
Future proof. 25 years ago nobody thought of GPS. New processes and data formats can come up.
The system has to be scalable. Why transmit a lot of stuff over the air, when you dont need it? But when you need it, you must be able to get it, so the system should be able to transmit small or large amounts of data.
Transparency of source and procedure is a further requirement. The origin server should not need to know the origin of the position information (ie the method of positioning). Nor should it need to know where it comes from (although it is nice if you do). This means that a reasonable number of data formats have to be supported. Of course, it is nice if there is only one.
In creting the requirements, the group broke privacy in two (and it seemed Rick had further shortened what they wrote, which was three pages). There has to be a mechanism for user/subscriber possessor/to prevent unathorized use of the information. This gets around the legal issues, which can be thorny.
The other aspect of privacy is operator privacy. The network operators feel it is important to protect their infrastructure. The cell location may be sensitive.
The client can have position awarness, which creates potential for revenue generation. If your client user want to give the origin server position information, they could buy it (or the origin server owner could - there is a host of possible business models).
Quality of position is another aspect. The system needs to have different levels of position accuracy. This means enabling different levels of quality. Both request and response quality. This ccan be negotiated - the origin server asks for a level of quality. And the client gives information with that quality.
Location data entry can be done almost everywhere in the WAP architecture. The source could be GPS, it could be the user giving his position, it could be roadside beacons. In a VIX-type approach, the beacon knows where it is, and can tell where you are. The position information source can be physically inside the terminal as we more forward. In a WAN, we can look at triangulation of different forms. Can come in any number of places.
In the WAP Forum, different groups have created unique solutions. There is need for a unified solution, a task given some priority. In its last meetings, the WAP Forum created a "location dependent drafting committee" which will hold workshops to create requirements. It will also call for different requirements.
This is intended to be a high-level process, to gather up information and analyze requirements. Requirements needs to be concrete to measure. One thing we have recommended is to see if there are relevant external specs, and ifit is possible to reuse pieces to satisfy internal and external reqirements. First priority goes to the internal requirements.
Last weeks meeting, we generated an overview, high level roadmap. The drafting committee will ask the WAP specification committee for permission to publish the early drafts outside the WAP Forum. The idea being to solicit more input.
WAP TEG goals are to have broad participation, and involve other worlds than just the world of wireless and wap. The use cases we developed can adress this. We have tried to start the process towards convegence and consensus. The first step is to involve all the worlds that we can achieve in discussions.
Q: Who is the chair of the drafting committee?
A: Frank Zillikens is the interim chair.
Q: What is the timeframe for these specifications?
A: Less than a year. Possibly WAP 1.4, depending on the timing and numbering of the versions.
Our traditional members are GIS companies, and those companies traditionally and primarily makes maps. The consortium has 210 members, all around the world, comprising traditional GIS companies as well as IT companies. our goal is to make interoperability a reality, primarily in networked environments.
I have been fascinated with the wireless side for some time. I always scan news releases, february 1 a year ago there was a release related to Motrolas Psion on a palmtop. Sun and Netscape, one year later, taking iPlanet, which works with wireless. WAPit in Finland threw together some services, wants to go mobile with spatial connectivity.
To our members, this is untapped and unquantified. They don't know how to get at in a meaningful way. Since all our activities are tied to producing maps, it is somewhat problematic to get there.
It deends first on member overlap. Not a lot of OGC interfaces can be made "lite". Interfaces can derive information from mobile users. OGC is considering to establish a "spatial productivity forum" - make sure it is used in a good way. Important if this occurs, is that it takes place in agreement.
OGC follows specific rules. It is an industry funded consortium, and the modus operandi is to find out where the pain is in market and solve it. Regardless of medium. It develops specifications, that are part of standardized, commercial open software. The testbed is driven by sponsors. The pilots reuse the specs.
One of the testbeds is concerned with web mapping. That one took four months from start to finish. Products are already out in the marketplace. The OGC has established a fast track specification process. That has innumerably expanded the number of web tools. Users can get the data they care about. It is a simple decision based on position, which opened some eyes in the OGC.
The unique partnership cuts the specification development process with 60 %. We can pull out the requirements from the way the testbed is populated, the way the network is utilized, and the pilots also generate requirements. There are 12 operating servers around the world. Data is being distributed all over the place.
We also have other testbeds, like disaster management, which use mobile applications. We intend them to be feeders to the EU 5th framework project, TIDE, traveeling info on demand, that we have proposed. Pre-specification work on that is going on.
With our next testbed, web mapping 2, we intend to get a wider view. We need catalogs or databases of geographical information, so we can get to the information people need. We want to enable self publishing/unassisted catalog population.
The mapserver can get GML, Geotiff. But we have problems with authentiction security and access control. It is not our cup of tea, we need help. There is a lot of work to be done in the semantic area. And there is lots of work on symbolization an symbology.
The testbed has a stable infrastructure. It runs on a donatred server from Sun, which Nasa adminsters. It connects to 12 different mapping services. And we are moving quickly. Webmap servers use the specs, serve up info on a desktop. Mobile connectivity is also being studied. Extensible coordination - done. Location reference system, done. We can exchange specs.
The possessor, the metadata? We do that with catalog services. the foundation for ecommerce using geoservices. There is an ISO standard, to do and build. Semantic standard, vertical industry. Subscriber and user, we need help. As for scalability, we need your requirements for taking our APIs to a "lite" state. Probably there is a way to move API to lite state. Data formats, we adress comprehensively, completely even. It is a well known strucure, can be transmitted as binary, if we do not have to restructure. We believe we have everything covered. Privacy aspects, we want to work with others to foster appropriate use.
Quality positioning needs user requirements definition. Govern content, pretty detailed and accurate. In certain cases we have to give accuracy down to 6 inches (19,2 centimeter). Users dont want, or want to pay, for accuracy. 100 feet (384 metres) is enough, better they don't want to pay for.
We have not done anyting wireless yet, other than study. We have mainly worked with databases and catalogs. Oracle, Mirosoft, Teleatlas, Mapinfo, Mapquest, just to name a few.
We are interested in demo work. But we do not do things that are not GIS. If there is nothing that can relate to an earth plane, we do not include it in the testbed. We show that you do not have to understand the ugly stuff.
GML: Consortium last Friday passed the GML (Geographical Markup Language) work. It will go to the W3C for review in the next two months. Ron Lake developed GML, he was not able to be here, but I will introduce it tomorrow if you want to look at it, and we hope you are interested in looking at it.
GML also specifies that data has a life cycle, we specify timing, etc.
Part of the work is going on in our web mapping 2 testbed. It is going to be incumbent on populators of catalogs to use metadata standards. The shelflife of data, other time aspects, we do allow for, and use accordingly.
Some more information on TIDE. It is now under review by the EC. submitted Jan 17. Those reviews last for several months. That work is the centerpiece in what we try to do with wireless. Look at what wireless is, whch new businesses can start in the wireless environment. We wanted to go where the market accepts that right now. So the specifications can do something good. Europe is the place right now. US is not the place, Japan is ahead in some places, not in others.
Further work is to specify 3D-data, minimal bandwidth. We are effectively aiming at GPRS, which will happen in one to two years. The timing is perfect.
We created a context-aware tourist guide. It was deployed in Lancaster, evaluated on actual end users. That gave us some idea on end user acceptbility.
The project was run in the distrbuted multimedia research group, which started 8 years ago. Focus has been to build systems which adapt to the mobile environment. Potentially, they could adapt to changes in the network quality of service. Previous work included a system for field engineers in the electricity industry. 2-3 years ago, we started looking at context aware systems. Originally, this was about quality of network service. 3 different levels of context: Personal, environmental, device.
Personal context is where the position comes in. We were specially interested in tourist applications. That could involve dynamic attributes like the traffic situation, and informtion such as which attractions are open early. The device constraints can involve which capabilities the device has.
It is interesting to note the similarities between the personal and network quality adaptability. Location systems are not always available. That means you are not able align the information structure. The actual quality of the system differentiates. Go from high to low granularity systems. There are tradeoffs between resources, in order to recieve certain qualities. Info can come for free. But if you use a GPS device, power has to be expended. There is a clear tradeoff between power expense and information quality.
We were interested to see what you can do, when you are mobile with a context-aware device. We focussed on the tourism industry. Tourists have mobile interactions with context-aware information. So we created tools for tourism navigation. This also let us experiment with the user experience.
Traditionally, group-guided tours have to start at a certain time, follow a fixed route, and are not individually adaptable. Books can also be out of date. We saw that we could overcome this.
The project started with a requirements capture. We spent a few days at the Lancaster tourism center, to see the information requirements. We interviewed staff and visitors. Eventually, we found that there were four key requirements: Flexibility, because the tourists wanted to explore Lancaster in ways that in way suited best. If person wanted a passive role, we had to support that as well as active. We could still create tailored information an deliver context awareness. And of course, it would be great if the user information was based around the current location. Also specific interests.
Another major requirement was to handle dynamic information. Guidebooks are usually updated every six months. Here, we can do it on an hourly basis.
This is particularly important since Lancasters old castle is also a court of law, but it is open to the public when the court is not in session. This makes it difficult to plan a tour. By supporting dynamic information, we can change that information.
Another service we decided to offer was interactive services, basically book accomodation etc online.
To enable the comunication we set up a wireless cellbased infrastructure. It provides information to the mobile guide unit, and also location info. We used WaveLAN, 802.11, 2 Mbps per cell. It has very poor propagation characterisitics through stone masonry. We were able to use this to tailor the cells, by strategically positioning the base stations. The cell diameter is normally 2-300 m, by placing cell antennas right we could get cells down to cover onlyone or two attractions. One cell would cover only the tourism info center, another the castle. The mobile devices would recieve location beacons from the cell (we do not have separate devices for this yet). We could also schedule broadcasts in he cells. If we had used a connection oriented solution between cells and devices, we would have overloaded traffic fast. By creating a broadcast schedule, we got rid of that problem.
Visitors carry a Fujitsu Teampad 7600, which weighs less than 1 kg, and has a grayscale display, Pentium processor. It runs Windows 95. We will be looking into CE, but when the development started, that development environment was not usable.
The user interface is based around a browsing interface, basically we just modified the browser a litttle. That means it is familiar to users. We also wanted to give the system a friendly personality. This was based on the "Media Equation" thinking - to relieve user anxiety.
To retrieve information, the user uses the information booklet in center of screen. The systeem will then tell you about the area you are in. At first, we presented only the location aware information to visitors, only which current attractions were nearby. But they felt to constrained, feeling that we were overdetermining what information they could access. What they felt was that it was important to get position dependent information, context aware information in general, but not for us to overdetermine what information they can get. Users want to click and get information about what is near, from a scrollable page that is built dynamically. Attractions which are open are higher up on the list.
One thing we thought to get away with was not supplying a map. But users wanted it. Visitors definitely liked to have map. The message system, to all, one-to one, between device holders and groups, was also popular.
Q: Did you also keep track of users where they are?
A: Not currently.
The tour guide system provided categories, such as food and drink, historical attractions. Users get a tailored tour based on what they selected and the best route and time to visit. The route could be tailored to avoid busy times. Interestingly, this could be use as a form of load balancing between attrctions.
In the evalutation, however, users found this feature too flexible, complicated. Users liked set tours. Although it did not give flexibility. Now, the guide breaks the tour into steps. You scroll down, go to next attraction.
The information model was created specifically for the project. When looking at what was available, there was nothing that supplied our various needs. We needed representation of geographical information, hypertext information, and most important, active components.
Active components could be navigation points used to generate tours, and also active components such as the castle object, which has a state, open times, locations,operations and methods. When queried, an active object can give a list of nearby attractions.
That the mobile environment has to include a potential for disconnection also brings a number of implications. Certain guide functonalities become unavilble like messaging and location. This has implications for the users trust in the information. For instance, the castle could have been closed when the user was out of connectivity. If he arrives at the castle then, trust in the system drops.
Some services have to be available while the user is disconnected. Clearly an issue. You can not access web pages. We worried about this because we did not want to build a system that seemed overly unpredictable. We tried to find a metaphor to help the user understand the role of the connectivity in the system. Mobile phones dont always have connectivity, but they use the little field strength indicator to give feedback. We wanted to give the user a model that enabled them to understand that not all functionality was available. So we borrowed the connectivity bar. While it solves that problem, it doesn't solve the problem of having a single metphore for what the current quality of location information is. At the moment, we try to set up a partnership between system and user. The status bar and the indication when the system was latest updated, we try to use to keep the user informed.
There were a couple of choices for the resynchronization of information. Click on the link, click where they are, or get a palette of picures from which you can select one you recognize. That way, the system can find out where user is.
Q: Can the system locate objects in the image?
A: In our experiments with Windows CE, which does not have Wlan drivers, we use image recognition in the location, enbling the user to wander around, and as soon as it finds the location where they are, it provides appropriate information. It is an interesting alternative.
The evaluation of the experiments was very throrough: first, they did a walkthrough of the system with experts. They got a look at the system at an early age. This brought up some interesting UI issues, such as that we had buttons in the wrong location on the screen, for instance. It lso highlighted the need not overconstrain the user. During five weeks, we also organized a field trial, to find out what the public thought. And determine the implications, especially concerning issues like trustand granularity of location information. But we were also very concerned that we did not impinge on the users holiday time. The users took between 10 minutes and 1 hour. There were big differences in age and experience.
Users appreiciated the location awareness, they found it reassuring. Shows where you are. Awareness was also useful, since it reduced the number of tasks the user was required to perform. But users were fickle in their trust. They seemed to think the system knew where was. The opposite happened when the system got it wrong.
Some people were quite prepared to browse around sitting on a parkbench. They would switch from using maps to using directions to get to castle, and follow links for more infomrtion.
People did apprieciate the flexibility, but others wanted a system with only three buttons.
Q: What about the concept of the packaged tour?
A: On the UI, the tour gave you the choice to go to the attraction. That might change with where you are.
Q:Did you create failures as part of the trial?
A: That happened automtically.
Users where prepared to walk around with the computer. The assumption we make of people not wanting to carry computers around is different today.
Q: Did you test the system during rainy days?
A: Yes, some users used them as umbrellas.
Two-handed operations was a problem. One-handed operations would have been needed for exmple when holding an umbrella.
Users were not too enthused about the interactive services. With the e-commerce wave, we have more online booking now, so that may have changed.
10-20 users loved the system. They visited twice as many links as others.
Users accepted the role of connectivity, and they accepted the mobile phone anlogy.
The bandwidth between user and endsystem was limited, which narrowed down the possible interactions. The display was also a constraint. Users walk round, which narrows the possibiliites further. Using context (especialy location) simplifies the users tasks. Users do not have to specify what they want to see, where they are. Intelligent agents react to the context. It also tailors the presentation. Hopefully, this means that the most relevant attractions come on top of the list. Basically, the system does a filtering job as well.
Because the constraints on information, you have got to be carefull. There is a tradeoff between prescription and freedom that becomes particularly relevant in the context aware setting. Predictability is an issue. This is similar to existing adaptive hypermedia systems, by the way. List of information can be different, if factors change. That in turn has a whole set of implications.
Q: Direction as opposed to mapbased navigation.
A: That depended on wether users were passive or active. Big split.
Tour provides context. Cell info provides synchronization points.
Q: Test users were only testing during a short time. What if they wanted to do something outside system contraints.
A: System would be able to aid them, because the objects are larger than the cells. A user could add an attraction into a tour (i.e. pause the tour). The tour would be modified to take the next attraction into account.
Q: So the system would not rearrange the tour automatically?
A: That is a general point, what level the user is intrerrupted, what level the user interrupts the system.
Q: What about correlation between age and map use?
A: We did not check that specificly, but the feeling is that the older, the more you prefer a map.
In the future we will have more microcellular networks, such as bluetooth. We can build tourguides into museums, etc. With Bluetooth we get a accuracy down to metres. We are also looking into GPS integration. You are in the line of sight of the sattelites 60% of the time, so it is no panacea. You might have areas of both types, one type, or no type. You can use GPS, and broadcast corrections over the Wlan. Then you have differential GPS without cost. Also there are tradeoffs you have to take into account, in terms of power. Power is the crucial factor. One hour is all you can get from the system. That is a factor 10 off what we would want.
You can extend the context of services, press a button to get a cab, for instance. The system knows where you are. This can also be use for adhoc meetings. We need to experiment with how people uses the end system. It could for instance be through a WAP phone or connected PDA.
Q: In your requirements anlysis, did you take this extended context awareness into account?
A: Yes, for specific objects. We are now also specifying a Guide 2 project, and fishing around for suitable models.
One thing we found is that there has to be persistence of profile. Not only users preferences, but also learning in building the profile. When the system presents future information, it should reference previous information. We will substantially increse the learnability of the system.
In conclusion: The user interaction does not only take place in the UI. Designers need to consider the metaphores and interaction styles, and avoid to overdetermine users.
Context aware systems is one way of achieving the "information appliance" vision of Don Norman.
Navigation is an important service, both for car drivers and pedestrians. Car drivers get the navigation from the car navigation system. It stores the map, on DVD or other systems. Car navigation does not have to use the network. Pedestrian navigation systems get their information from Internet. Such systems can be position based or station based. Position based systems includes the Locatio device by Epson. DoCoMo is testing a GPS system. Toshiba is running a station based system, "eimae tanen club". This is a station based exploring system. You can get information about greater Tokyo and greater Osaka. Currently it generates 1 million page views per day. All information is in Japanese. It is now accessible from PC, and in a test system from mobile phones using the Japanese mobile telephone system PDC.
The system gives inforation based around the train stations. Say you wanted to go from the Tokyo Metro building in Shinjuku (a big shopping and office area) and meet someone in the Oshiba area. You can search transfers and time tables, which are provided by the rail lines. Kwasaki is the station nearest the Toshiba research center. The system searches the transfer routes. It will find out when you should start, the travel time, and the ticket price in yen.
The user must provide the start- and endpoints himself, and the system can then search the route. You give the name of the starting station, and input the name of the goal. The system uses a map, provided by a large japanese map maker. You use the route map to find your way. The system puts in the route in blue, and landmarks along the route.
If you have trouble, you can get information based on station. There are also additional services, such as reserve a hotel.The system is based on stations, because many users don't have GPS. In the near future, many people can use GPS. We want to extend that to position based systems.
We have summarized our requirements in four points. There has to be a dynamic user profile. What we are using now includes fixed information, such as the user interest, name, etc. But to provide a position dependent system, we have to provide information about where the users are, and what information to use. In order to securely provide the information, the user must be anonymous. Users want to know the adress, where they are, not coordinates. Coordinate to address translations are important. Also for correction of information, when the granularity is too coarse.
The dynamic profile includes the personal position independent information. In order to be context aware, we must know the dynamic user profile. We must know the position. Or position for the users point of interest. Wether that is area specific or not, there is a central service provider that gives information. A regional service provider can give area specific information to cellular phones. Conventional ads and cupons are not specific to an area - they use the same context. Ads can be broadcast, and you can send out the same general ads plus local ads. If we get a dynamic user profile we can provide ads and cupons, dependent on where the users are.
The area size also becomes important, as the car area becomes larger than pedestrian size. The mode of locomotion must in other words be included. Another requirement is that dynamic profiles are coordinated to address translation and quality of service control.
Q: Are you currently at planning stage, or do you have a business model?
A: In the PC it is free, in iMode you pay per view.
Q: When yu are a pedestrian, does not that make the need for accuray in your position requirements higher?
A: Yes. In a car you can get by with GPS and gyros. Pedestrians need to use a finer granular mobile phone system like PHS (the japanese Personal Handyphone System, where cell typically are 50 metres in diameter), and beacons.
Q: You collect a lot of information - what about privacy concerns?
A: Cellphone services, annd other carrier services, provide only an IP address. Carriers protect user privacy.
Looking at augmented reality and what WAP is today, we are far from augmented reality. But the step is not so big it will not be taken.
Augmented reality is a term where that describes an enviroment using a viewing device where the real world is overlayered by generated optics. A large variety of services are possible.
In Oulu they choose to develop wearable computers as navigation systems. Navigation is one way to use augmented reality, other examples are telepresence and ubiquitous intelligence, for instance when you are visiting somewhere and you recieve a fax, the system can print it out on the nearest printer and guide you to it.
The requirements of augmented reality on the mobile environment is extensive. But it is not impossible to do. 2 to 4 years ahead, there will be commercial services. Preferrably using headmonunted displays. Today we have small screens, but soon we will all wear eyeglasses anyway. The airlink will be packet data. Virtual Reality (where the entire environment is simulated, instead of projected onto the "real" reality) is used a lot in Japan, it is an entire industry. The new generaton of video games is based on it. In augmented reality, you add something to fix your augmented world.
Augmented reality Needs 1 to 30 m accuracy. The speaker then gave a list of requirments from a technology point of view. He also presented a table which described the accuracy defined by how the tag stays near the object (which can be found in the presentation).
Spatial information in augmented reality requires both the position and orientation of the user. Most dependent on position. But orientation is also important. The accuracy of the position is another factor. One idea is that it could be selected based on the accuracy of presentation. If you use the system to check cabling, you need higher accuracy than when you check for iron ore deposits. The system needs to offer at least on meter also in height.
No cost estimates, just looking at presentation requirements. These depends on the user. You have to select syntax so that it alows for future services. Currently cost is not an issue for us - we are a university, and we look further ahead.
For selected information using GPS, WGS 84 is a great start. You have 3 degrees of freedom, user pan and tilt. It is related to worlds magnetic north.
Position can be attained from many different systems. You can get from the bottom of the stack if you are getting it from the bearer, or from the top of the stack for users. And everywhere in between. User profile should tell who they want to give their profile to - eg blacklist.
An example is service navigation. These last few days, I have been driving around in France with GPS and a palmtop. It is almost useful on highways. But i spent two hours in Antibes trying to find the hotel, and one hour finding the conference location.
We created a service example scenario. The demo system uses tcp/ip, a wearable computer, and Java. The speaker howed some pictures of himself riding a bike in downtown Oulou wearing the system, and a simulation.
The map is rotated in the direction where you are looking, you are always in the center. The system can recalculate depending on changing directions. Streetnames, where there are any, are included.
On the wearable computer, we use a resistive touchpad for navigation. Almost as good as my PDA when driving. We are not ourselves exprimenting with voice activation.
Q: How do you know it is a pedestrian zone?
A: The worry is that the level of data is for automobiles, not intended for pedestrians, collected information is not commercializable.
Orientation will be userful for the future. Source transparent.
We have studied enduser acceptance, but not in our group. When the prototype is done, we will take that into account.
Q: Is there an issue in transferring to other places?
A: It is a standard system, location database could be a cellular system, log into network default address to database give info services. Divided global decentralized system.
Integrated GPS in wristwatch in 1997, together with Swatch. Will be presented in a month. We have learned how not to do it. The antenna is the difficult part, even more in watch than phone. So we said in 93, we should use the GSM network.
Today, positoning systems are based on several devices, not integrated. Today, we have WAP phones. Alphanumeric capability to users. End 2001, we will have graphical phones. Today we need WAP, tomorrow you will have all in one. You can do nothing against the service.
Using products like the MPC from Ericsson, operators can position you or you can position yourself. These use triangulation, and are dependent on operator involvement.
There is another technology which could be used in GSM: Enhanced observed time difference. One advantage is that privacy is not an issue. You can not be traced yourself. Big advantage from legal aspects. By filtering out reflections, you can also enhance precision. Robust system in terms of accuracy. Now, 50 m. Athough this requires at least 3 different antennas. It is also an ETSI standard. You need to get cell location plus location for near cells (up to 32).
Mogid has developed a server that anyone can set up. It contains bank information, post offices, shopping, etc. There is also an event relation thanks to the time reference. By listening to the network, you can find a position in Bern. Connect to network, Mogid server gives information, user requests information services. Only the information about his area. WAP does not provide geographic information (but address).
Today, what is running is going in a city, adress a system. You can really navigate. Live demos on web server.
Mobile station calculates its own position. User can switch position on or off. In an emergency, it can send its position automatically. There has to be software to handle this in the phone. But you need no extra hardware in the network.
It also fulfills the american E911 standard.
A pessimistic estimate of the accuracy is down to 50 meters, but we have simulated 3 meters. When you can listen to 3 cells, you get good accuracy.
Currently, the system transports the position in the URI. The server can be adressed in many ways, including over the Internet.
Mogid proposes a new WML element, the 4d tag. This would contain the area where the location is, plus time. An attribute list would contain all the attributes. This would imply that you can search for information and get relevant/contextualized information.
Calculations are few, really about protocol analysis, simple computations. Cell ID is provided together with position, but encrypted. The user needs a key to decrypt it.
The system is not mandatory in Europe. In the US it will be next year.
Position dependency as opposed to what I get on the Internet. How do I get from here to there.
No dependency about the information you provide and the the location. It may be a car crash and a marathon goal at the same position.
Perception of space - we do not know areas where we are not familiar. Maps are a way for us to understand the the relation between a location and our home base. A location related to our position requires a map. On the Internet, we have maps, but bitmaps. Vectororiented maps, either with plugin or proprieaty application, would enable us to handle maps differently. To create a relevant map you need to continously work with the data.
A functional requirement is that you can position yourself on maps - the problem is finding yourself on the map. Navigate - go from here to there. Be scaleless. Zoom in and out. Care only for relation to relevant objects (objects you percieve relevant). Also pan. And combine information. Querying different items - is this a one-way street.
Utilize bandwidth. Maps shall be presented on any device. Maps may be updated - only change the changed items. Maps shall communicate - share location reference - two maps must be related.
Vectormaps can solve these problems. Use coordinate systems, your coordinates and the vector map is independent of each other (i.e. you do not have to create a dedicated map for you). Vector maps knows the properties of the objects on it. Vector maps are zoomable. Same map can be used for many diffferent formats. Group content according to various applications - Know which roads to take. Where are sidewalks, etc. Also seamless, no border, move though content as you like. You can prccisely move through a map as you like.
You can attach whatever content you want to a vector. Not only related to one vector, but also to vector intersections. Smaller than bitmaps but if lot of information is attached, it will be a problem. And the content is unique.
Example vector map format, Geographic Data Files format (GDF). Describes all points of interest, etc for the different features. Leaves little opportunity for map vendor to achieve artistic freedom. Developed for transport and traffic applications, but works for others.
In principle, no problem add attributes for pedstrian navigation. Content currently focussed on car navigation. Tremendous task to gather information, digitize paper maps and check the roads in reality. Costly effort, needs to be rectified in terms of cost. Teleatlas continously has 300 persons who drive round, check the maps. Webraska is using it in their WAP service.
You need an application to do the filtering, load data into application, filter out. If support distinction. Position and service are separated. Lots of information is needed for maps.
There are IPR implications on vectorizing bitmap. You have to make a deal with the national mapping agency.
We are a telecom company, but also an information provider. We develop yellow pages. Began work on mobile portal, Mobile Information Search.
The motivation is that there is much attractive information on the net. Terminals get richer every day. But that is not easy to utilize. The target service almost the same as information navigation. On the user side, it can be car navigation, iMode phone, PHS location services, or PDA with GPS.
(Kokono means here). Local information from the Internet. Server software comes from NTT, and sits in a proxy between the user and Interent. Mediation service. No particular location devices required. This solves problem of providing many different information resources. It costs a lot to provide the information.
At each search, adress and index of local services are displayed. External services are indexed (meta search). The information can be divided in plain text and databases. On plain text, the system can do indexing. Other services, can be searched with a metasearch.
Documents relevant in a certain distance from the user are displayed. Example of metasearch. Search results will be related to position on a map. Adressed with URI. Spatial document to search, and location data repository.
In the URI format, the user gives the latitude and lonngditude, and declares which geocoordinate system is used.
The search then is done by a selective collection web robot, using automatic location metadata generation. It collects documents that are location related. After it collect the documents, the automatic metadata generation takes place.
Location is based on extracting the adress (the ward and building address, since street adresses traditionally are not used in Japan, even though they have started to appear lately). The address is translated into coordinates, and encoded in XML.
The system creates a wrapper around the information and enables mutual conversion among the different formats.
There is no detemination of relevance, so it has no way of determining what an adess relates to. That is the tradeoff. Not analyzed where (in which areas of Japan) the information is relevant.
Started work in 1997. First position dependent info service with Internet component. Map is the most requested service, 38 %.
About 40% of all documents retrieved by the search engine contained adresses (they can be found in almost all of Japan, almost 30 % of all cities). When we plotted the distribution of documents on Japan, it was clear that big cities dominate but they are spread all over Japan. There is a clear relation between population and web pages. Tokyo dominates, but some places have more web pages. Like Nagano and Kyoto, and the island of Hokkaido (popular tourist destinations, Kyoto is also an important cultural location)..
Future plans include continued research, and a world version.
Q: How do you do recommendations?
A: We use a datamining-based filter.
Q: How do you determine shop names?
A: That is very difficult. We extract databases, yellow pages etc.
Traffic information is currently useful only when large accidents happen. Information is collected only from fixed sensors. Distribution is slow. It is difficult to get information.
We are now building a new system, based on cellphones. It can collect sensor information from cellphones, and aggregate information from many phones depending on how they move. For moving terminals, users input transportation data. The user moves from home to busstop and to train. They register the route before they travel. Server recieves and stores data from many terminals. When measuring the data, the user selects moving mode. Sensors in the terminal measure position and speed of terminals. Terminals send moving mode to server and position to server. Data is stored from many terminals. Recieves and collects data from many servers. Calculates traffic conditions, distributes to terminals. User can get specific traffic information while moving or leaving for the destination. But to realize such a system, a standard is needed.
You can send data in standard format. We have also created a processing and speed data processing algorithm. If the number of subscribers is large, computing power may be a problem.
Q: You could do interactive work with terminals, when you have a certain percentage you have as much information as you require. There was a US governement funded study that demonstrated this.
Q: Do you have a standalone system or can you combine with other systems? If it is a standalone system, there may be problems, like streets not covered by GPS, like users stopping or not reporting they change locomotion mode.
A: It is just an idea, we have not built it yet. When user changes mode, it is rather easy to determine.
Q: There has been trials in Germany, and one of the results was that serveice provider needs to query device (cell) to get information. You can turn off information that is not needed from other cells. You need devices to tell wether they are stuck or moving.
Q: If you hve lots of moving people, it is great surveillance. When someone is registred on a server, is there a unique ID? This would make a perfect surveillance system.
A: Privacy, yes. It may be a problem.
Q: There are ways around it. Unique anonymous ID. Assign a number that is randomly assigned, when you shut off it is reassigned. Wether consumer likes it or not, is another matter.
Route and navigation info services.
Metadata, is it enough to have meadata on one location? You may also need route information. Find out where the user is, which route is available to the destination.
Metadata on multiple locations will be required. Route navigation is a sequence of locations. Origin (start points), via points, destination. Location is a special case of a route. Navgation information is required, also guidance information that is not via points.
NVML, submitted to W3C. Navigate people from any point to anywhere. Get information from information navigation center. You can also add point of interetst data. Point of information center optional. NVML can describe sequences of locations.
Image of tour guide service. Select one item, find five route images. Route is composed. Overlaid on the map. Car navigation system, select guide by navigation system.
NVML, head part allows for the abstract definition of routes. In body, the latitude and longitude of points are defined. Define wether a point is on a route by using the <navi> tag. For each point, define information data. Also find point informtion for route. Navi and guide elements, enable you to recieve information about the route.
Fujitsu has constructed a NVML player and composer.
The background map is a bitap. The simulation illustrates how the user moves along a route, in car navigtion or by you as a pedestrian.
APIs are needed. You give the position to the API, it displays the route on the map.
Content can be styled differently using XSL, i.e. generate different views.
The editor allows you to insert points, and descriptions for points. System can automatically generate route data.
I am really representing three different organizations: Worldboard, Indiana University, and Information in place. The Worldboard concept originated with Jim Spohr at Apple. The idea is to present the world as a bullentin board, where people could put information.
Worldboard, creates a system that changes the way people percieve and think about information. Do not think about digital things, where to put it. Change the way people think about things and objects. Impact on design of systems. Thinking about how people will interact with this digial information.
What we have done is come up with system, which sits on top of the Internet. We deliver content in a unique way. Thinking about it in terms of contextualized information, tools and services. Look at places: They have longditude, latitude; proximity and how to associate things with it; third is a particular object in a specific location. Fourth is when you define a place in certain terms (this room is now my presentation room).
Viewer-independent. Have to respond to functions, augment reality. Compatible and complimentary to avoid fragmentation. New way for people to communicate.
System is not a single component.
Conceptualizations on how to use it: Look below the ground, see the pipes. Peering behind the wall before drilling a hole. Embedding in maps.
Trying to be device independent.
Key concept, channels or groups of information that users can subscribe to. Relates groups of information together. Different experiences for different groups of people. Customize experience as people move around. Can refer to documents on any server in the world. Multiple cannels simultaneously possible. Changing objects as they are coming through me.
This opens all kinds of possibilities to "sell the Brooklyn Bridge" (an American metaphor for fooling tourists by selling them the rights to a landmark). You can paste virtual advertisements into the physical world. Create virtual gameboards.
We are now working on a virtual navigation system for ships. You will be able to deliver it to many different devices. You could actually draw lines in the water. The system can display other ship when it detects them, let you see through fog.
Another possible use is handheld shopping information. Anyone could attach information to the product you are looking at.
Students can gather information, attach data to positions. Take a different view, for instance attach to a 3D- view. Working on travel product with Palm. It also becomes possible to produce digital documentaries to augment reality.
We used XML, customized it create a real object and make a wrapper, create a context around it. It is a type of position dependent system. Server decodes and makes the information usable. Working on RDF metadata format descriptions. Only patial functionality. Insert into HTML.
Create WXML object, the local server, takes file and parses it, registers in a portal search engine. Find what is there. Just store metadata. When going out to the Internet, you can get location services. Point people there. Uinfying resource. Optional step. Search the search engine to get information, query them, servers that have relevant info will send back.
Zone of influence, object has zone of influence near it depending on where it is relevant. Docments have relevance zones, too. Try to think about the experiential function, create an experience around the space. Proximity, location, bandwidth. Experiences determined by everything.
The system is standard based, and open source. We want it to be so simple average people can use it.
Q: Can you have many localized servers?
A: Yes. It is a distributed system, with a common coordinate system.
Going through the terminology again. Location is in the browsing environment.
Q: Possessor is called data controller in the data protection community.
At which point his computer hung and he had to reboot. Powerpoint...
Key issue is that there are lots of vertical systems. Makes it hard to get horizontal services in. We need convergence towards a standard architecture with key interfaces.
Privacy framework, on one hand we want subscriber control. But we also want end user integrity, but not override subscriber. Access control release when to release, i.e. when to pay for it. And authority access. A reflection is that anonymous access is not enough.
Suggested architecture with a location proxy that acts as a proxy towards any service that uses location information. No additional software in the server. Location server collects information. Sends to location service. Client-driven model, request. Or server driven. Problem is how it is coded into protocols.
Polled can be tracking applications. Police can use to track criminals. Both are needed.
The basis of this architecture is that the location server is used as proxy. Shields application from method and system. Provides a single point for operators, provisioning. Integrates with browsing paradigm.
Key points of interfaces. Location data format, common and open, e.g Open GIS. Formats must allow negotiation of supported or required format type and/or parameters (named formats). Extensible format, add and remove elements.
As a consequence, you can negotiatie format negotiation.
Location server and application server have interfaces. Access conctrol, privacy negotiation, data transfer eg using CC/PP. Separation of privacy negotation and data transfer is important.
User agent, has network side issues. Same protcols running. Use a network proxy. This gives device independence.
Cosistent user experience, user agent should be able to handle inband negotiation. Capability negotiation and transparency and methods.
Q: Server-initiated protocols and event thresholds?
A: Not looking at how to solve that.