Category Archives: Vocabularies

Semantic Web terms

FOAF Explorer update

FOAF Explorer, RDF, Vocabularies

It has bothered me for a while, that the FOAF Explorer wasn’t able to handle duplicate statements. It would either repeat the entire property/value pair, or in some situations “just” show the values next to each other without whitespace or other separators in between.

That last issue really isn’t fixed yet, but at least it now only happens with different values – I managed to remove duplicate statements with some crude PHP hacking.

I was already doing a parse and custom (re-)serialise with Redland/Raptor (the PHP source is available) before passing it on to the XSLT, so it was “just” a matter of making sure the same statement wasn’t serialised twice.

Since part of the point of reserialising was to group statements by subject, I had an index in the form of an array of statements per subject. Even though it can be optimized, I simply added a loop to check for the presence of the current predicate/object pair:

$found=0; 
  $os=librdf_node_to_string($object); 
  reset($Nodes[$node]); 
  while(!$found && list(,$pso)=each($Nodes[$node])) { 
    $p=key($pso); 
    list($s,$o)=current($pso); 
    $found=($p==$predicate && librdf_node_to_string($o)==$os); 
  }

It works (try it!), and while the entire FE processing should now take longer, it actually helps somewhat that the XSLT doesn’t have to cope with too much…

While I was at it, I added support for the use of XFN as an RDF vocabulary, with the namespace http://gmpg.org/xfn/1#. It is now treated the same way as the Relationship vocabulary and the Trust vocabulary, which means that it’s handled as if all the properties are rdfs:subPropertyOf foaf:knows. It’s not perfect, the display could use some collapsing, but it works (try it!).

Oh, almost forgot: Also added support for the Quaffing vocabulary by Leigh Dodds.

If only FE really knew about rdfs:subPropertyOf…

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.