Generalized Metadata in your Palm

Syncing with Ad-Hoc Metadata

This solution adds the user fields to the XML record for styling, but leaves them in the note field for synchronization. In other words, the user-field values are read-only; to change the Palm record, you have to edit the note field. The publication process for this system is summarized in Figure 3.

Figure 3: Publishing from the Palm with XML

[Link to open this graphic in a separate page]

PilotManager talks to the Palm and uses the SyncXmlDB conduit to read and write an XML representation of the date book (there are analogous conduits for the address book, memos, and todos). The resulting XML document can be transformed to produce web pages.

Is There a Better Way?

In the spring of 2002, several nearly simultaneous events occurred that made me reconsider the metadata solution for my palm:

1. I found an RDF application ([Circle and Arrow Diagrams]) that was compelling enough to interest me in learning RDF.
2. Consequently, I discovered [N3], a simple text representation of RDF rules.
3. I found that I had an ever growing collection of ad-hoc user field names (hotel, phone, uri, hoteluri, class, type, …). RDF seemed like it would provide a mechanism for me to identify the semantics of these fields with a little more rigor. (I'm not sure that was particularly necessary, but it seemed like “a good thing”.)
4. The ability to do circle and arrow diagrams easily inspired me to revisit some projects that I'd had on the back burner for a long time. One of those was a little family genealogy. It occurred to me almost immediately that what I wanted was the ability to store these genealogical relationships in the same place where I store all the other data about people in my life, in my address book.
5. I actually rely on two sources of information about people: my Palm and my [BBDB] database in Emacs. Keeping these sources in sync is a bit painful, and I hadn't done it in a while. RDF seemed to promise the ability to deal with these two data sources more semantically which also seemed like a good thing.
6. Trying to sync my BBDB and my Palm always reminds me of another irritating limitation of the Palm address book: you can only have one address per individual. It would be nice to be able to have multiple Palm records and associate them together.
7. Some of the individuals in my address book are related to each other so they have, for example, different work phones but the same home phone and the same home address. It would be nice if I could avoid duplicating the information that's the same. In particular, the RDF tool [CWM] would allow me to write inference rules: if “‘A’ is the significant other of ‘B’ then ‘A’ has the same home address as ‘B’” (not a universal truth, but true for my address book).

Using RDF on the Palm

The first change was the move to RDF instead of my ad-hoc user fields.

If I had access to the source code for the Palm applications, or if I was writing my own applications, I'd probably create some kind of form that made it easy to construct the RDF statements. I can imagine various sorts of pull-down menus with context-sensitive default values that would make adding the metadata quite easy.

However, my goal is to integrate RDF directly into the existing Palm applications, so I really can't extend the user interfaces: the RDF will have to be written by hand in the notes field of each entry. These applications are neither RDF- nor XML-aware so some serialization syntax will have to be used.

Data entry on a PDA is somewhat tedious. There's strong motivation to minimize the amount of typing required to add metadata to an entry. Furthermore, the XML serialization(s) of RDF are fairly verbose, so some sort of abbreviated syntax that uses relatively few markup characters is required to make the authoring task practical on a Palm.

Enter N3. N3 is a simplified syntax designed for ease of authoring. It's perfect for this application, is supported by a number of tools, and can be automatically converted to an XML serialization when necessary.

Using N3

Most RDF statements that you'll want to make about an entry in your PDA are fairly simple. In fact, the vast majority will simply associate a property value with the current entry. In N3, entries and properties are represented by QNames. Property values can either be other entries or string literals¹.

For example, let's say we have a date book entry for the conference identified as “db:extreme2002” and we want to set the “p:phone” property of that entry to “514.285.1450”. In N3, we could express that as follows:

db:extreme2002 p:phone "514.285.1450" .

While that's short and easier to type than the equivalent XML representation, further reflection reveals that we could simplify things even further for this application. Remember that our N3 statements will have to be parsed out of the note field, so it's OK if they're not quite proper N3 as long as they can easily be turned into proper N3 by the program that parses the note field. With that in mind, the following rules can be applied:

1. Observe that we're setting this property in the entry for the conference, so we shouldn't need to explicitly identify the conference for each property that we want to set. We can leave off the leading identifier and just start with the property value.
2. Periods are hard to see on the PDA screen, so we establish the rule that every statement must fit on a single line and then we can infer the period.
3. Property values are either other entries (identified by a QName) or they are string literals, so we establish the rule that quotes are optional around a value unless that value contains a colon.
4. On those uncommon occasions where you want to enter a more complex N3 expression, we adopt the final rule that if a line begins with a double quote, we discard the leading double quote and treat the rest of the line as literal N3 markup. This allows for multi-line entries and other complexities that would otherwise be impossible to express.

With these rules in place, our entry is simply:

p:phone 514.285.1450

Storing the hotel phone number is a literal translation of the old system into RDF, but it doesn't take advantage of any of the new power we have available. It's not the phone number association that's really important, it's the association with the hotel that we want to capture. So, if the hotel is identified by “ab:wyndham-montreal”, a better entry is:

p:hotel ab:wyndham-montreal

That raises the question, if it hadn't occurred before, of how to associate unique identifiers with an entry. We provide that facility with one more convention. The value associated with the property “:id” is taken to be the identifier. So, if we want to be able to refer to the Wyndham Montreal hotel as “ab:wyndham-montreal”, we'll have to have the following N3 statement in its entry:

:id wyndham-montreal

Similarly, our entry for the conference would have to include

:id extreme2002

if we want to refer to it with that identifier. If you don't need to point to an entry, you don't have to give it an identifier.

Storing N3 in each Entry

Now that we know what N3 statements to write, two questions remain: how do we store them in the note field, and how do we deal with any “prologue” material needed in the N3 format. In the preceding discussion, we ignored the fact that the N3 file needs a prolog to associate prefixes with URIs and make general statements.

In answer to the first question, we simply use the identifier “rdf:” in the note field. If “rdf:” appears on a line by itself in the note field, every following line up to the first blank line is taken to be an N3 statement.

Figure 4

[Link to open this graphic in a separate page]

This example identifies the location, URI, and hotel associated with the conference.

Storing N3 “Headers”

The header data associates namespaces with prefixes. It's also the place where you'll put any inference rules or other global statements.

Ideally, I think I'd store these values in a memo, but the current conduit syncing system doesn't give a conduit access to data from other databases in any practical, reliable way, so I adopted a different convention: I store the information in the note field of an event with the description “‘database’ N3 Header”. For example, I have a date book entry with the description “DateBook N3 Header” on Jan 2, 2020. When the N3 data is extracted, the memo field for that entry is always placed at the top of the file. Similar entries in the other databases provide the equivalent functionality.

Syncing with RDF

Syncing with the new RDF system is mostly the same as before. What's new is the generation of N3 and RDF versions of each of the Palm database and the use of CWM to expand inferences. The publication process for this system is summarized in Figure 5.

Figure 5: Publishing from the Palm with XML and RDF

[Link to open this graphic in a separate page]

PilotManager talks to the Palm and uses the SyncXml{AB,DB,MB,TB} conduits to read and write an XML representation of the various databases. The result is a set of XML documents: the XML representation of the database, the N3 file derived from the database, and an RDF representation of the database. These files are fed through cwm to produce a unified RDF document that is subsequently styled.

Other Ontologies

I've also used QNames from a number of other namespaces in this paper. The system described in this paper uses six namespaces in addition to my ontology namespace. These are really just URIs used as RDF identifiers: