Creating an Ontology From the Data
If you look at datadump.rdf
with a text editor, you'll see namespace declarations like this:
You'll also see rdf:type
elements with a value of file:outlook/entries
as their rdf:resource
attribute value. A URL
beginning with file:
needs at least two slashes after it, so use your text editor to do a
global replacement that adds two slashes after the string file:
Now, SWOOP can create a simple ontology from your data dump. Start it, and pick Load/Ontology from the File menu.
You're not really loading an ontology, but instead the RDF file that you pulled from
D2RQ: datadump.rdf. It might take a few minutes, so to speed this up you could edit down the
datadump.rdf file to only include the data from one record of each database. SWOOP builds an ontology out of the properties that it sees, so it only needs to see one example of each property.
After you've loaded the data file, immediately click Save As from the File menu and save the file as
Look at both datadump.rdf and postSwoop.rdf with a text editor.
Although you didn't do anything to the datadump.rdf "ontology" that you loaded, SWOOP added
OWL declarations to postSwoop.rdf for all the properties it found, like the following:
The Entity references &eudora;
are standing in for the strings
to make the
values proper URLs, which RDF requires for identifiers. Now you can use SWOOP to
enhance the ontology so that SPARQL queries against the combined databases can do things that SQL couldn't do to the
MySQL versions of the databases. We'll start by adding something to the ontology that says that the
column of the eudora
database's entries table is equivalent to the
column of the outlook
database's entries table.
Select the Property Tree tab in the lower left of SWOOP and click on “entries_workState.” If you click the RDF/XML tab
near the top, you'll see an RDF/XML representation of this property's declaration, which looks like the
DatatypeProperty declarations above. Among other things, this shows that this property is part
of the file://eudora namespace.
By using SWOOP, you don't have to deal with RDF/XML, so click the Concise Format tab to return to the display that is
easier to read and interact with. Click on Add next to "Equivalent to:," select "entries_businessState" on the
Specify Property dialog box that appears, and click the Add button, and then the Cancel button to show that you're
done with the Specify Property dialog box (see Figure 1). You'll see "entries_businessState" appear under "Equivalent to:" on the
main pane, but it's not official until you click the Apply Changes button at the bottom. Save the edited ontology by
picking Save from the File menu or by pressing Ctrl+S.
Figure 1. Using Swoop: After you indicate that the entries_businessState
property is equivalent to entries_workState, the EquivalentProperty section of the information for
entries_workState reflects your change.
If you search for "equivalent" in postSwoop.rdf
, you'll see how SWOOP saved this; it changed
RDF/XML representations of OWL statements are not difficult to read, but they are verbose, which is why a tool like SWOOP makes editing them much easier.
For a more thorough job of integrating the two databases, you also define eudora:entries_firstName
as equal to outlook:entries_firstName, eudora:entries_lastName as equal to
outlook:entries_lastName, and many other equivalencies. The more relationships you can identify between the two databases, the more tightly they'll be integrated. The Bobby Fisher use case works better if you define at least these two.
To make it possible to find all of Alfred Adams' phone numbers, regardless of which ones we have stored for him, we
want to indicate that all the phone properties have some semantics in common. To do this, create a new phone property
and then make all other phone properties subproperties of that. Click the Add P button with a yellow "P" at the left
of the SWOOP workspace to display the New Entity dialog box. Set the Property Type to OWL Datatype Property, because
phone numbers are simple strings. Set subProperty-of to None, which is the first choice, because our new property
isn't a subproperty of any other. Based on the URIs that D2RQ generated from my address book, I replaced the default
Logical URI on the dialog box with http://localhost/entries/phone. I left the other fields blank. Click the dialog box's Add & Close button, and "phone" appears at the bottom of the Property Tree. If it doesn't appear, you can click Remove and start again.
After you add this new property, make sure it's selected, and then click Add next to "Superproperty of." OWL has no
"superproperty" property—when you tell SWOOP that entries:phone is a superproperty of
outlook:entries_homePhone, it stores outlook:entries_homePhone as a
subproperty of entries:phone. It's faster in the SWOOP interface to indicate that
entries:phone is a superproperty of 15 other properties than it is to go to each of those 15
and mark it as a subproperty of entries:phone. In the Specify Property dialog box,
Ctrl-click lets you select multiple properties as subproperties of the new phone property. Select the following, and
then click Add to include them in the main window and then click Cancel when you're finished with the Specify Property
dialog box. You'll see "entries_otherPhone" twice on the list, once from each of the Eudora and Outlook namespaces.
Click Apply Changes and save your work.
To let Pellet discover that Bobby Fischer and Robert L. Fischer are the same person, you've already done half the
work by adding new information about the emap:entries_email1 and
omap:entries_email2Address property bridges in the mapping file. We need to have the ontology
specify that the properties used for personal email addresses are inverse functional properties, which means that
only one instance of a class can have a particular email1 value. This way, an email1 value of "firstname.lastname@example.org" for
both Bobby and Robert means that they're the same person.
When using OWL DL, a property that is an inverse functional property must be an object property, not a datatype
property (that is, a URL and not a string, which is why we tweaked the mapping file for this entry the way we did).
Select "entries_email1" in the Property Tree tab and then click Add next to Attributes at the bottom of the main pane.
Select Inverse Functional and the Yes button on the Specify Property Attribute dialog box, and then click Apply
Changes at the bottom of the main pane and save your work. Follow these same steps to designate "entries_email2Address"
as an inverse functional property, and then define "entries_email2Address" as an entries_email1
to be equivalent following the same steps that you used to define the equivalent property pairs earlier.