In the early days of the Web, we were thrilled when we could find addresses and phone numbers of commercial establishments. As more sophisticated Web sites started using databases behind the scenes, we came to expect a page that included all the addresses for each branch of a chain in our city or neighborhood. When Mapquest came along, we were delighted that we could click a button and see the location for each of these shops on a map. Then came the Web 2.0 idea of the mashup; at a click of a single button, we could see all the Starbucks in a zip code all at once.

These mashups are great if you're looking for one kind of thing (coffee shops, hotels, gyms) and come from one source (especially when that source is an amalgamator like Citysearch or even Google). But suppose you're moving to an unfamiliar city; you'd like to see a map with all the subway stations, gyms, organic supermarkets, art-house movie theaters, and, yes, coffee shops so you can figure out where you'd like to live, preferably each type in a distinctive color or icon to distinguish it from the others, providing a real integrated picture of the neighborhood.

There are a couple of ways to do this with common Web 2.0 approaches today. You could do a map mashup of each kind of thing you want to see and display all those maps on the screen at once. This gets you the information you need, but you might be at risk of whiplash turning your head so much from one map to another.

You could spend some time bookmarking all these things in your favorite mapping application so that they're all on a single map. But the idea of a mashup is that the information should be available from feeds - like the RSS feeds we've become familiar with for our news. That way, whenever Starbucks opens a new shop or a neighborhood announces an open-studios event or another real estate listing is posted, your mashup will update with it. When we can merge information from multiple feeds and organize the results - that's what we call a Semantic Mashup.

The first step is to turn all of your data sources into feeds that can be mashed up. RDF is the ultimate mashup language; it provides a simple way to express information from spreadsheets, databases, Web pages, XML files, and, yes, even native RDF/XML files, allowing them to be merged into a single graph structure.

If you have unfettered access to the database behind a Web page, you can treat it as RDF using an RDF database wrapper like D2RQ, but since we usually want to mash up information from other sources, and most security administrators don't provide global access to their database, another approach is needed. Enter the W3C Working Draft.

RDFa lets Web site developers make an HTML page do double duty as a presentation page (the usual role of HTML) and as a machine-readable source of structured data in RDF. As a simple example, consider the following excerpt from the Los Angeles Metro Rail Web page, with a few minor modifications to embed RDF data in with the HTML display:

<p><font size="2"><div name="rlhv" id="rlhv">
   <link rel="rdf:type" href="[LAMetro:RedlineStation]"/>
     <meta property="rdfs:label">Hollywood/Vine</meta> <br/>
     <a href="../../about_us/metroart/images/pict_mrlhv.jpg">Station Image</a>
     <b><br/>

     </b><meta property="geo:address">6250 Hollywood Bl.<br/>
Los Angeles 90038 <br/></meta>
60 Park/Ride Lot Spaces (Parking Fee)<br/>
     <a href="../../projects_plans/bikeway_planning/images/bike_rack_mrhv.jpg">18
Bike Rack Spaces</a></div></font></p>

The extra <div ...>, <link ... >, and <meta ...> tags mark up the HTML page to include a few simple facts; something called "rlhv" has type "RedlineStation," label "Hollywood/Vine," and the address "6250 Hollywood Bl. Los Angeles 90038." Most of this information was already available in the Web page (including the name "rlhv"!); the markup just links it together in a consistent way. The extra markup makes no difference to HTML viewers (like the browser); the page displays in the same way.

The Web Ontology Language was built on top of RDF to let us describe how we want to combine information from multiple sources together. Types in RDF (like "RedlineStation," in this example) are called Classes in OWL, and typed individuals (like "rlhv" above) are members of one or more classes. Information from different sources will have different types, and so appear as members of different classes; the Red Line page describes members of the class RedLineStation, the Blue Line page describes members of the class BlueLineStation, and so on. We define a new class for anything else we can find, a class for gyms, amusement parks, organic supermarkets.

Now we can use OWL to describe how we want to combine these things together. If we want to combine information about all the metro lines, we define a new class in OWL called LAMetroStation and make each of the line classes (BluelineStation, RedlineStation, etc.) subclasses of it. We can do the same for any other classes we've defined for gyms, amusement parks, organic supermarkets, whatever. We can express this class/subclass structure in RDF/XML as follows:

   <owl:Class rdf:about="#LALocale"/>
   <owl:Class rdf:about="#Entertainment">
     <rdfs:subClassOf rdf:resource="#LALocale"/>
   </owl:Class>
   <owl:Class rdf:about="#LAMetro">
     <rdfs:subClassOf rdf:resource="#LALocale"/>
   </owl:Class>
   <owl:Class rdf:about="#Fitness">
     <rdfs:subClassOf rdf:resource="#LALocale"/>
   </owl:Class>
   <owl:Class rdf:ID="GoldLineStation">
     <rdfs:subClassOf rdf:resource="#LAMetro"/>
   </owl:Class>
   <owl:Class rdf:ID="GreenLineStation">
     <rdfs:subClassOf rdf:resource="#LAMetro"/>
   </owl:Class>
   <owl:Class rdf:ID="BlueLineStation">
     <rdfs:subClassOf rdf:resource="#LAMetro"/>
   </owl:Class>
   <owl:Class rdf:ID="RedLineStation">
     <rdfs:subClassOf rdf:resource="#LAMetro"/>
   </owl:Class>
   <owl:Class rdf:ID="Cinema">
     <rdfs:subClassOf rdf:resource="#Entertainment"/>
   </owl:Class>
   <owl:Class rdf:ID="Gym">
     <rdfs:subClassOf rdf:resource="#Fitness"/>
   </owl:Class>
   <owl:Class rdf:ID="Pool">
     <rdfs:subClassOf rdf:resource="#Fitness"/>
   </owl:Class>
   <owl:Class rdf:ID="Yoga">
     <rdfs:subClassOf rdf:resource="#Fitness"/>
   </owl:Class>
   <owl:Class rdf:ID="AmusementPark">
     <rdfs:subClassOf rdf:resource="#Entertainment"/>
   </owl:Class>
   <owl:Class rdf:ID="Theater">
      <rdfs:subClassOf rdf:resource="#Entertainment"/>
   </owl:Class>
   <owl:Class rdf:ID="ConcertHall">
     <rdfs:subClassOf rdf:resource="#Entertainment"/>
   </owl:Class>

This is easier to see in outline form (as shown in an RDF visualization tool like TopBraid Composer, see Figure 1).

The meaning of subClassOf in OWL is very simple; it just means that all the members of BlueLineStation, RedLineStation, etc. are also members of LAMetro, and that all the members of LAMetro, Fitness, or Entertainment in turn are members of the top class, LALocale. So to display all the metro stations, you just query for members of LAMetro; to display all the places of interest in L.A., you query for members of LALocale. Send the results off to a display API like GoogleMaps and you get a screenshot, that looks like Figure 2.

Just as class structures in object-oriented programming help you to organize your program code, class structures in OWL let you organize your data. You can display your mashup to include information at any level of the tree.

But OWL goes far beyond simply amalgamating information through subclasses; you can also specify constraints on your information. For example, we could say something like "All members of BlueLineStation are restricted to have http://www.topquadrant.com/images/icons/bluetrain.gif as an icon." In OWL/RDF this looks like:

<owl:Class rdf:about="#BlueLineStation">
   <rdfs:subClassOf>
     <owl:Restriction>
     <owl:hasValue>http://www.topquadrant.com/images/icons/
bluetrain.gif</owl:hasValue>
     <owl:onProperty rdf:resource="http://www.topquadrant.com/
maps/mapModel.owl#hasIcon"/>
   <rdfs:subClassOf>
   </owl:Class>

When we do the same for the other classes (redtrain.gif for RedLineStation, ferriswheel.gif for AmusementPark), this lets OWL set icons according to the class an instance belongs to. We send that to the mapping API as before, and we get a map with different kinds of places indicated by appropriate icons, as shown in Figure 3.

This same approach can be used to customize any part of the mashup that the API can handle, what information appears when you hover over an icon or what URL you visit when you click through a bubble.

There's no reason to limit this kind of mashup to maps; the same approach works just as we ll for any way you might want to display data, calendars, spreadsheets, org charts, pie charts, and PERT charts. There's not even any reason to limit your mashup to a single one of these modes; after all, concert halls have performance schedules, train stations have timetables, and people in your organization attend meetings that take place at particular places and times. OWL provides a wide range of modeling capabilities that let you combine information from multiple sources in your filters. Following the map example, display the location of all the amusement parks, but use a special icon for the ones you've visited, and put the date you visited them on the hover label.

This paints a pretty rosy picture of how you can build powerful semantic mashups with standards-compliant, readily available tools. But there's a bit of rain on this parade - a pre-requisite for all this mashing up is that the data be available in RDF - and who wants to do all that work? My data is in a database, or a spreadsheet, or HTML, or XML, or... Do I have to transfer it to yet another format? And especially RDFa - who's going to do all that marking up just to make their data easier for other people to use?

Well, fortunately for semantic mashups (and indeed, fortunately for the Web, since this is how the Web came into being in the first place), the Web is full of exhibitionists. The only reason their data is on the Web in the first place is to show it off. And the more people who have their data available in RDF, the more valuable it is to have your data available that way too for semantic mashups like the ones we describe here. This is the sort of network effect that brought the Web into being. TopQuadrant is doing its part to start this bootstrap by providing semantic mashup tools; you can get in the game by making your own data available in RDF.