Ghosts in the Semantic Web Machine

mc schraefel,* Alun Preece+, Nick Gibbins,* Steve Harris* Ian Millard*
*Electronics and Computer Science, University of Southampton,
+Computing Science Department, University of Aberdeen
{mc, nmg, swh, icm02r } @ ecs.soton.ac.uk, apreece @ csd.abdn.ac.uk

Abstract

in this paper we present the concept of a ghost, a lightweight container that holds pointers to RDF resources (such as RDF vCards or FOAF) which represent the person associated with the ghost. The goal of the ghost approach is to provide a light weight jumping off point into the various bodies of metadata associated with an individual, which in turn can connect to various Semantic Web services in a local context.

Introduction

In this position paper, we describe the concept of a ghost, an RDF wrapper of a set of pointers to other RDF resources which represent a person. The ghost is therefore available to services that can trawl the resources pointed to within the ghost and f rom there, match those findings with appropriate customized services. In the following sections, we present a ghost schema, an example of a ghost in RDF, and a scenario to contextualize ghost use. We conclude with some questions for future work.

Ghost Overview

AS an RDF wrapper to other RDF resources, the ghost provides a lightweight "jumping off point" into the various bodies of metadata associated with an individual, which in turn connect to various Semantic Web services in local contexts. The shared meaning available through the RDF Schemas and OWL/DAML ontologies allow reasonably reliable reuse of existing services. We imagine a set of related ghost service. Ghost hunters at different sites can interrogate the ghost to look for properties of interest/relevance to the available services in that environment. Ghost machines can help a person create a ghost that will have its own url (we can imagine ghost namespaces so that anyone can create a ghost machine)

The motivation for ghosts has been especially to support physical-digital connections: a person going from one location to another, where services at those sites can provide customized support to a person, based on knowledge about that person from their g host. The use of a ghost means that a person does not have to create an identity for each location.

Ghost Schemas and Example Ghosts

Proposed Schema

Example Ghost

 


<?xml version='1.0'?>
<rdf:RDF 
 xmlns:ghost="http://ghost.aktors.org/1.0/"
 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>

  <ghost:Ghost rdf:about="">
    <ghost:nickname>apreece</ghost:nickname>
    <ghost:hasDescription>
      <ghost:Description>
        <ghost:locator rdf:resource="http://www.csd.abdn.ac.uk/~apreece/foaf.rdf" />
        <ghost:identifier rdf:resource="http://www.csd.abdn.ac.uk/~apreece/foaf.rdf" />
        <ghost:ontology rdf:resource="http://xmlns.com/foaf/0.1/"/>
      </ghost:Description>
    </ghost:hasDescription>
    <ghost:hasDescription>
      <ghost:Description>
        <ghost:locator rdf:resource="http://www.csd.abdn.ac.uk/~apreece/index.rdf" />
        <ghost:identifier rdf:resource="http://www.csd.abdn.ac.uk/~apreece" />
        <ghost:ontology rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0"/>
      </ghost:Description>
    </ghost:hasDescription>
    <ghost:hasDescription>
      <ghost:Description>
        <ghost:locator rdf:resource="http://www.csd.abdn.ac.uk/research/akt/people_rdf.php?id=5" />
        <ghost:identifier rdf:resource="http://www.aktors.org/scripts/abdn_people.dome#apreece.csd.abdn.ac.uk" />
        <ghost:ontology rdf:resource="http://www.aktors.org/ontology/portal"/>
      </ghost:Description>
    </ghost:hasDescription>
 </ghost:Ghost>
</rdf:RDF>

Bootstrapping Ghosts

Any rdf source that describes attributes of a person would be appropriate to be part of the ghost. However, not everyone has used FOAF-o-matic, and there mayn't be much info there about person attributes in a FOAF form that could be used to describe a per son's preferences, useful for customizing location-based contexts.

WhatILike

To help bootstrap the rdf in the world, and the ghosts concept, the ghosts can leverage the WhatILike service, a page simply dedicated to collecting preferences on a variety of topic s. WhatILike is a point and click set of pick lists on a web page which produces rdf as an output, for example



<rdf:RDF xmlns:rdfs='&rdfs;' xmlns:rdf='&rdf;' xmlns:wil='&wil;' xmlns:foaf='&foaf;'>
<rdf:Resource rdf:about="mailto:steve@totl.net">
	<foaf:name>Steve Harris</foaf:name>
	<foaf:givenName>Steve</foaf:givenName>
 
	<foaf:familyName>Harris</foaf:familyName>
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Movies/Genres/Action/" />
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Literature/Genres/Cyberpunk/" />
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Literature/Genres/Humorous_Fiction/" />
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Literature/Genres/Travel_and_Adventure/" />
	<wil:likes rdf:resource="http://www.dmoz.org/Recreation/Autos/Makes_and_Models/Ferrari/" />
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Movies/Genres/Classic/" />
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Movies/Genres/Comedy/" />
 
	<wil:likes rdf:resource="http://www.dmoz.org/Arts/Movies/Genres/Organized_Crime/" />
	<wil:has rdf:resource="http://www.dmoz.org/Recreation/Autos/Makes_and_Models/Fiat/" />
	<wil:has rdf:resource="http://www.dmoz.org/Computers/Software/Operating_Systems/Linux/" />
	<wil:has rdf:resource="http://www.dmoz.org/Computers/Software/Operating_Systems/Mac_OS/System_Software/Mac_OS_X/" />
	<wil:has rdf:resource="http://www.dmoz.org/Computers/Mobile_Computing/EPOC_Devices/" />
	<wil:has rdf:resource="http://www.dmoz.org/Arts/Music/Instruments/Stringed/Guitar/" />
	<wil:has rdf:resource="http://www.dmoz.org/Arts/Music/Instruments/Electronic/Theremin/" />
	<wil:has rdf:resource="http://www.dmoz.org/Arts/Music/Instruments/Stringed/Bass/" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/mobile_phone" />
 
	<wil:has rdf:resource="http://www.whatilike.org/gadget/pda" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/mp3_player" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/digital_camera" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/laptop" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/gps" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/multitool" />
	<wil:has rdf:resource="http://www.whatilike.org/gadget/games_console" />
	<wil:does rdf:resource="http://www.dmoz.org/Arts/Music/Instruments/Electronic/MIDI_Controllers/" />
	<wil:does rdf:resource="http://www.dmoz.org/Arts/Music/Instruments/Stringed/Guitar/" />
 
	<wil:does rdf:resource="http://www.dmoz.org/Arts/Music/Instruments/Electronic/Theremin/" />
</rdf:Resource>
</rdf:RDF>

Ghost Machines: Rolling Your Own Ghosts

As long as a ghost complies to the ghost schema, anyone can create a ghost. We imagine, however, that sites which particularly wish to take advantage of ghosts will offer a ghost machine service. Such a service will ask visitors if they already have a gho st or any RDF resource. It may then offer them the opportunity to add to the ghost by pointing to additional services like FOAF-o-matic, WhatILike or an RDF vCard service.

At Southampton, we are drafting a ghost machine wizard to help visitors create ghosts: the wizard will first attempt to find appropriate RDF about the person from, in our case for UK academic visitors, the akt triplestore. If nothing comes up, they will be sent to a version of Foaf-o-matic and then onto the WhatILike generators. As we find other FOAF-esque generators, we can make u se of those services, too, as appropriate.

Context of Use

The idea is that a person will be able to make their ghosts available to receptive physical locations which can trawl through the ghost's RDF pointers for data the site can use to match up to appropriate services in that environment.

As an example, at the University of Aberdeen there is a family of RDF-based services that provide information for visitors to the "Granite city". These services are harnessed together into an agent-based planner called GraniteNights that is designed to offer a visitor a complete plan for an evening out in Aberdeen, covering restaurants, cinema show s and, of course, pubs. Each of the services can, however, also be accessed separately. Use of common ontologies and schemas wherever possible allows the services to link to and from the metadata referenced by a Ghost.

For example, a visitor - let's call him Nigel - arrives in Aberdeen. Signing into the Computing Science Department, Nigel docks his iButton into a reader, and is thus identified to the local Aberdeen Ghost processing a gent (or Ghost Machine). The agent retrieves Nigel's Ghost, and traverses the links to extract as much useful information as it's programmed to understand. Two of the things it's looking for are cuisines and beers Nigel likes, in order to gather restauran t and pub recommendations from the GraniteNights services. It finds that Nigel has previously used the WhatILike service to specify he likes Chinese cuisine (an instance of cuisine types from the standard Agentcities restaurant ontology [copy available at http://www.csd.abdn.ac.uk/research/AgentCities/ontologies/restaurant-v4]) and uses this to identify several Chinese restaurants. It then uses Nigel's FO AF data to identify who he knows in Aberdeen, and emails a suggestion to these people that they may all like to take Nigel out for a meal at one of the identified restaurants.

Visitors to the University of Southampton on the other hand, may find their ghosts trolled for information about their research interests in order to match them with appropriate people known to be on campus at the same time and with interests in the same areas. Agents can likewise send notices to these people, alerting them to the visitor. The visitor, on accessing one of Southampton's interactive displays may find a list of people and associated projects, with proposed meeting times, and directions to ap propriate meeting spots.

Ghost Rationale: reuse and co-reference

In the example given above, the local Ghost-processing agent is free to decide how much of the linked metadata is useful in calling upon re-usable services in the local context. A Ghost-processing agent at a different site is likely to make different choi ces. Of course, it is the use of common RDFS/OWL/DAML ontologies that make the services re-usable in the first place - the Ghost just pulls the disparate sources of metadata together.

A particular advantage of the Ghost is that the RDF resources that get added to a ghost can be held at multiple sites; they're simply coordinated by one ghost. Perhaps just as critically in FOAF terms, the ghost isn't the person, it's a person's surrogate and in the world of FOAF can have a url not just a uri, making it easy to point to, and supporting reuse of foaf/RDF in multiple contexts.

Thus a ghost is a pragmatic fix to the (very hard) problem of recognizing that two descriptions on the SW relate to the same person. The ghost eliminates the hard work of resolution by explicitly identifying the various metadata sources that are representative of the same. This approach also avoids getting bogged down with overly-strict OWL-style sameAs assertions. For example, a person's vCard is *not* owl:sameAs that person's FOAF, but they are both representative aspects of the "real" person. So, with ghosts, we have a mechanism to enable us to explore the interesting possibilities to be considered with the fusion of the various metadata sources that make up a person, and by extension make up members of communities.

Questions and Future Work

Within the local context of the AKT project, as a testbed for the concept, we are keen to integrate ghosts into a visitors system (like Southampton's Signa ge project) that will enable visitors, before arrival at a participating campus, to create a ghost for use during their visit, to provide them with customized services, and which they can reuse at other sites, physical or virtual.

Multiple Ghosts and Ghost Filters Ghost reuse also raises the question of ghost versions. For various contexts, a person may wish to have specific ghost instances in order to offer some separation of data available to different services. Converse ly, some services may want to do develop ghost filters: someone who has an archive of information may wish to "attract" the right ghosts and keep out the wrong ones (as in the context of age limits and access to dodgy material).

Both ghosts and filers raise questions about privacy in the way the ghost-linked information is used. Some things (e.g. where people are from) are appropriate for semi-public display (on a big plasma screen in an office hallway: "Welcome Nigel! Hope you h ad a good trip from Southampton") while others are perhaps more personal ("Enjoy a Guiness in the pub tonight"). This may just be up to the local ghost-processor to decide; after all, the person concerned has already published the info on the public SW, b ut it seems meta-metadata on the use of particular ontology elements may be needed.

Semantics On the operational level, we need to assess what exactly are the semantic of a ghost:hasDescription property. Does this assert that the thing id'd by the ghost:identifier property is in some (perhaps soft) sense the "same individual as" the things pointed at by the other ghost:identifier properties in the same ghost? The ghost-processor may need to use some rules/heuristics to sort out these distinctions.

Likewise, the different sources pointed at by a single ghost may contradict each other - due to human error, outdatedness, multiple personalities. How does a ghost-processing agent cope with these contradictions?

Conclusion

In this paper we've presented the concept of a ghost as a collection of pointers to RDF resources which can represent a person for access by Semantic Web services. We have described a schema for a ghost, an example instance of a ghost, and a scenario o f use for ghosts.

We see the ghost as a lightweight, potentially robust way to identify multiple sources of information on various aspects of a person for use by a variety of services in physical/digital contexts. While we see such a container as an enabler for context-based services, the ghost also foregrounds concerns for privacy - potentially making it too easy to collate data about a single person. We look forward to discussing the concept further.

Acknowledgements

The Ghost concept had its genesis at the AKT Workshop, Edinburgh, June28-July2 2004. We are particularly grateful to Hugh Glaser for his feedbac k.

Notes

iButton. An iButton is a small (5p sized) device which holds a unique id. An iButton's id is read by docking the button into an iButton reader. In the AKT group, we have been experimenting with iButtons as a cheap (approx �1) solution to identify users to physical devices being deployed around campuses.

Ghosts in the Semantic Web Machine?