Garmin Geko 201 and RDF

GPS/Geo, Python, RDF, RDF/XML, Release

Note: This post originated outside of the weblog, but I figured it really belongs here, and it makes it easier to find.

Following in the footsteps of Matt Biddulph, I acquired a Garmin Geko 201 GPS unit, wanting to annotate my digital photographs with location information.

Matt also wrote a Python script to extract the tracklogs and waypoints from the unit and turn them into RDF statements.

I tried it out, and found I had to overcome some dependency problems, as well as do a little tweaking to get all the information I wanted.

Dependencies

The following dependencies applied to the script on my almost clean Redhat 9 laptop installation with Python 2.2.2:

  1. PyGarmin, which itself doesn’t have any dependencies. It did however need a little patching (diff for garmin.py) to keep Python from complaining.
  2. Redland, with Python interface.

The libraries should be installed in reverse order…

Waypoints tweaking

To keep my version of Python (2.2.2) from crashing, I had to fix some import statements in the original version of Matt’s garmin2rdf.py. Also, a variable name clash was resolved.

Now being able to output an RDF model, I noticed the waypoints only had a property (dc:title) for the name given to it in the unit, but no indication of the symbol used (such as a house, an airport or a building icon). I figured it would be nice to be able to use that information as well, and decided to map each symbol to a Wordnet term, through the use of the Wordnet 1.6 vocabulary namespace.

The Garmin Protocol Specification defines a number of symbols, but the Geko 201 only has a subset of these (and two additional symbols not defined in the specification).

Each numeric symbol ID is mapped to a string identifier such as sym_airport, which in turn (for the Geko 201 symbols only, it’s not easy to create a sensible mapping) is mapped to a Wordnet noun, indicating which type of place is marked. This also fits in nicely with the spacenamespace effort.

When outputting the RDF model, each waypoint is assigned an rdf:type of the wordnet term if found. If no term is found, the string identifier is output as the literal object of a http://hackdiary.com/ns/gps#symbol property, and if no string identifer is found, the symbol ID is output as a literal object of a http://hackdiary.com/ns/gps#symbolid property.

Waypoint symbol mapping

Some of the symbols used relates to verbs, but places need to be identified by nouns. The mapping below doesn’t seem perfect, comments and suggestions are welcomed, especially regarding what to call a place with information (as well as the two special Geko 201 symbols, 8255 and 8256, a closed and an open box)…

Symbol ID String identifier Wordnet term
0 sym_anchor Harbour-1
6 sym_dollar Bank-4
7 sym_fish Fishery-1
8 sym_fuel Gas_station-1
10 sym_house Home-1
11 sym_knife Restaurant-1
14 sym_skull Danger_zone-1
18 sym_wpt_dot Train_station-1
19 sym_wreck Wreck-4
150 sym_boat_ramp Lake-1
151 sym_camp Campground-1
152 sym_restrooms Restroom-1
155 sym_phone Telephone-1
156 sym_1st_aid Hospital-1
157 sym_info Information-2
159 sym_park Park-1
160 sym_picnic Park-2
161 sym_scenic Sight-2
162 sym_skiing Mountain-1
163 sym_swimming Beach-1
170 sym_car Parking_lot-1
171 sym_deer Zoo-1
173 sym_lodging Lodging-1
175 sym_trail_head Spot-1
178 sym_flag Place-1
8197 sym_golf Golf_course-1
8234 sym_building Building-1
8255 sym_8255 Place-1
8256 sym_8256 Place-1
16384 sym_airport Airport-1
16395 sym_parachute Amusement_park-1

Files

Thanks

… to mattb and danbri for making this possible.

Round-tripping RDF/iCal

Python, RDF, Vocabularies

Note: This post originated outside of the weblog, but I figured it really belongs here, and it makes it easier to find.

The goal of this action is to automate verification tests for the RDFIG Calendar Task force, located in http://www.w3.org/2002/12/cal/test/ — both ways, from and to RDF, to and from iCal.

Running cwm

cwm requires a somewhat late version of Python, and installing RPMs for RH9 doesn’t work on RH7.1, so Python 2.2.3 was rebuilt from source. Next, some symbolic links were made from /bin and /usr/bin to the installed binary in /usr/local/bin, and the $PYTHONPATH environment variable was set to point to the /usr/local/lib/python2.2 directory as well as the current and parent directory, for non-standard modules (and programs with hardcoded references) such as llyn and retest: {{{$PYTHONPATH=/usr/local/lib/python2.2:.:..}}}.

The regression tester retest.py was then successfully tested with regression.n3 and the animal and animal-1 files.

Files

The following files from /cal/ were modified:

Changes and status

After changing/fixing toIcal.py to output original prodid and correct LAST-MODIFIED, and stripping X-properties and SEQUENCE keywords from input, the following test case now passes:

Then, stripping METHOD from .ics files gets the following tests to pass:

That leaves the following issues:

test/querymeetings.ics, test/20030423mtg.ics, test/20030416geomtg.ics, test/20030410querymtg.ics
A trailing whitespace in TZNAME for DAYLIGHT (stripped by toIcal.py).
test/gkexample.ics, test/MozexportAsCalendar.ics
Missing CALSCALE:GREGORIAN on input (always generated by toIcal.py).
test/openingHours.ics
Missing PRODID on input (thus extraneous prodid, version and calscale generated by toIcal.py).
test/cal01.ics
Unknown (to toIcal) properties like attendee, organiser etc.
test/bus-hrs.ics
Unknown (to toIcal) properties transp and class.

seeAlso

Names in FOAF

FOAF, RDFS, Vocabularies

Note: This post originated outside of the weblog, but I figured it really belongs here, and it makes it easier to find.

This document is continuing its life at NamesInFoaf – join the discussion there…

Executive summary

Let’s keep foaf:name, dump the rest of the existing name-related properties, and create a new set of classes for sortable and searchable personal names, suitable for world-wide deployment.

The issue

Back in 2000, DanC raised the issue of names in FoaF, and in February of 2003 it resurfaced and finally got its very own Bugzilla issue, #7.

This proposal attempts to resolve this issue by considering the following aspects:

  • Current usage.
  • The right thing to do ™.
  • Documentation and vocabulary.
  • Migration strategies.

Issues not covered here (non-exhaustive)

  • Actual capitalization of property identifiers, the homePage vs. home_page debate.
  • Nicknames as used on IRC etc. – the foaf:nick property.
  • Character encoding issues regarding non-ASCII names – left to syntax/encoding specifications.

Current status

As of this writing, the FoaF namespace document contains the following name-related properties (with usage counts from Libby’s stats page for FoaF properties / eikeon’s Properties by Popularity):

name (2355/4951)
A name for some thing.
firstName (151/284) and firstname (3)
The first name of a person.
givenname (16/17)
The given name of some person.
surname (229/331)
The surname of some person.
family_name (0/0)
The family_name of some person.

Not defined in the schema, but used according to the stats is lastName (17/0).

As suggested by these stats, most documents describing the FoaF vocabulary only mention the foaf:name property, including Edd Dumbhill’s introduction to FoaF, although Leigh Dodd’s FoaF-a-matic uses foaf:firstName and foaf:surname, probably accounting for most occurrencies of those properties.

Representing names

The Dublin Core Metadata Initiative has published a great note on representing people’s names in Dublin Core. This must-read note covers the problem in detail, offering approaches and examples of the variation of names across languages and cultures.

Summarizing, it turns out that the concepts of “first name”, “last name” and even “family name” apply to only a small subset of the worlds population, and even within cultures with those notions there are exceptions to the rules, e.g. the Danish royal family that only has first names.

Also, names are used in various situations in which the requirements for a name differ – sometimes an informal variation of a person’s “first” name is used (nickname), e.g. “Jack” instead of “John”, and sometimes the same name is expressed differently across cultures and languages.

Goals and usage scenarios

This proposal tries to establish a “standard” for expressing names, that makes it possible to use these expressions for the following purposes, taking into account the above issues:

  • Sorting.
  • Displaying.
  • Searching, also by components of a name, e.g. family name.

The right thing to do ™

According to the Dublin Core note, it “is unlikely that there will be agreement on a single common way of representing names”. As such, four methods are proposed:

  1. Use existing scheme.
  2. Adopt a naming authority.
  3. Adopt existing guidelines.
  4. Roll your own.

The first option is possible, but certainly not desirable, while the second option is impossible, since there’s no global registry of names and no consensus.

The third and fourth options seem to be more interesting in light of the purpose of FoaF and the current issue, and a combination appears to be the best solution to encompass the three purposes outlined above.

Sortable and searchable names

One approach to having a sortable name property would be to add a single property containing a literal value of the name in a format that’s suitable for sorting in the usual way, i.e. “Doe, John Allan van, Jr.”. Though, should someone want to sort by another order, all is lost.

Combining the requirement for searching by individual name components with the requirement for multipurpose sorting, however, leads to another approach – explicit composite names.

So, instead of having properties like foaf:firstName (i.e. literal properties with a rdfs:domain of foaf:Person, indicating a position of the component), a single property foaf:sortName is added, containg a sequence of items – the actual name components, ordered by requested (default) sort order.

Example:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Person>
<foaf:sortName rdf:parseType="Resource">
<rdf:li><foaf:FamilyName rdf:value="Doe"/></rdf:li>
<rdf:li><foaf:GivenName rdf:value="John"/></rdf:li>
<rdf:li><foaf:GivenName rdf:value="Allan"/></rdf:li>
<rdf:li><foaf:ArticularName rdf:value="van"/></rdf:li>
<rdf:li><foaf:HonorificTitle rdf:value="Jr."/></rdf:li>
<rdf:li><foaf:HonorificTitle rdf:value="Mr."/></rdf:li>
</foaf:sortName>
</foaf:Person>
</rdf:RDF>

This approach has the advantage of being able to specify exactly the properties that are relevant to the person, and at the same time yielding enough information for sorting and searching. It should be noted that it is not a requirement that it is possible (automagically) to construct a display name from the sortable components, but all components should be present.

Using classes instead of properties has the additional advantage of making it possible to easily assert statements about the individual components, should this be desired, perhaps for indicating exactly which family member the name component is derived from.

Display names

Most people have a single prefered form of their name, that they use to present themselves with. This is the name that most likely occurs on the persons homepage or in citations, and the name that fits well within the current definition of the foaf:name property.

This name is for informational purposes only, it should not be used as an identifying property or for anything but human consumption.

Sticking to foaf:name may seem like going with the “use existing scheme” approach, but the purpose and existing use coincides nicely, and quite a few existing systems use just a single property for this (or use a couple, and only handle “western” names).

Example:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Person>
<foaf:name>Mr. John Allan van Doe, Jr.</foaf:name>
</foaf:Person>
</rdf:RDF>

Cross-cultural issues

Expressing a name, sortable or displayable, for use in multiple cultures can be done by means of language tags (
xml:lang attributes) on the literal name components – so far there exists no conventions for distinquishing between cultures, but languages seem to some extent to cover the same concepts…

Example:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Person xml:lang="en">
<foaf:name xml:lang="de">Herr John Allan van Doe, Jr.</foaf:name>
<foaf:name>Mr. John Allan van Doe, Jr.</foaf:name>
<foaf:name xml:lang="zh">Mr. van Doe Jr. John Allan</foaf:name>
<foaf:sortName rdf:parseType="Resource">
<rdf:li><foaf:FamilyName rdf:value="Doe"/></rdf:li>
<rdf:li><foaf:ArticularName rdf:value="van"/></rdf:li>
<rdf:li><foaf:GivenName rdf:value="John"/></rdf:li>
<rdf:li><foaf:GivenName rdf:value="Allan"/></rdf:li>
<rdf:li><foaf:HonorificTitle rdf:value="Jr."/></rdf:li>
<rdf:li><foaf:HonorificTitle rdf:value="Mr."/></rdf:li>
</foaf:sortName>
<foaf:sortName xml:lang="zh" rdf:parseType="Resource">
<rdf:li><foaf:GivenName rdf:value="John"/></rdf:li>
<rdf:li><foaf:GivenName rdf:value="Allan"/></rdf:li>
<rdf:li><foaf:HonorificTitle rdf:value="Jr."/></rdf:li>
<rdf:li><foaf:ArticularName rdf:value="van"/></rdf:li>
<rdf:li><foaf:FamilyName rdf:value="Doe"/></rdf:li>
<rdf:li><foaf:HonorificTitle rdf:value="Mr."/></rdf:li>
</foaf:sortName>
</foaf:Person>
</rdf:RDF>

Note that the classes for the name components do not change across cultures, only the order used for sorting (maybe) and display (sometimes). Thus, classes like firstName and lastName no longer makes sense.

Also, languages should not be mixed together into one sequence, separate sets of components should be provided for each desired language. Perhaps at some point it will be possible to “translate” sequences from one language/culture to another, based on a set of rules.

Vocabulary definitions

A possible set of definitions for use in the FoaF namespace document:

[RDFS Explorer] Names in FoaF Schema.

Please note that RDFS doesn’t seem to provide the necessary means for restricting the contents of the foaf:CompositeName class’s elements (to a set of name and title components, or derivatives), and OWL is not grokked sufficiently by this author yet.

These definitions are meant to replace the current namespace definitions of foaf:title, foaf:name, foaf:firstName, foaf:givenname, foaf:surname and foaf:family_name.

Caveats

Missing from the “deprecated” list is foaf:nick, which is currently used primarily for IRC nicks, as intended and described in the namespace document.

A foaf:NickName class would likely lead to confusion and is probably not as relevant for sorting/searching, and as such the concept of “informal” names is not covered here – it is however possible to use the informal name in the foaf:name property.

Migration strategies

The current situation is not far from what is desired, the foaf:name property is almost exclusively used as outlined above, and it is by far the most often name-related property used (not counting foaf:nick and foaf:title, the last of which is used even more?!?).

The existing name component properties are used to some extent, but with the help of the various scutter-systems around, it shouldn’t be too hard to track down the early adopters and have them change the use to match the above suggestion.

Also, the current FoaF creation tools, most notably the FoaF-a-Matic, should be changed as soon as possible (is currently under revision, so a change like this seems to be quite possible), and the various display tools (foafnaut, web view, rdfweb and FoaF Explorer) should be extended to make use of the sortable names.

HOW-TO/FAQ

So, my name is a traditional western one, Morten Frederiksen – what should my foaf:sortName look like?
Depending on preference, a good bet would be a foaf:FamilyName, a foaf:GivenName and perhaps a foaf:HonorificTitle, in that order.
I’m an American with a middle name, but there’s no MiddleName class?
Your middle name is most likely a given name, perhaps a family name or derived from (one of) your parents – use the corresponding class instead.