Some personal notes on where FOAF and Portable Contacts meet.
- a common core addressbook fields should be shared with Portable Contacts / vCard
- W3C I18N input needed for dealing with names in a way that work for every Web user
- the core of PortableContacts is more interesting than some of the OpenSocial detail ("turnOffs")
IMHO the FOAF spec should ...
- map all fields to those in PC where a match exists
- specify a core of PC that is matchable; and make sure the spec makes the match explicit.
- for movies, for eg., we would want a way to represent URIs rather than strings
- where old FOAF name fields are being cleaned up, choose PC names where possible
Second level of interop is the OpenSocial fields:
aboutMe, bodyType, currentLocation, drinker, ethnicity, fashion, happiestWhen, humor, livingArrangement, lookingFor, profileSong, profileVideo, relationshipStatus, religion, romance, scaredOf, sexualOrientation, smoker, and status.
- identify which bits of the PC spec make assumptions about verification / provenance, eg. "relationships MUST have been bi-directionally confirmed"
- explore use of GRDDL for Portable Contacts ns
FOAF isn't supposed to be 'the' addressbook schema, so I'm happy if we can just pick up and use a common core shared with Portable Contacts and vCard, with some input from W3C 18N on best practice for naming fields. The emphasis of FOAF is more around decentralisation and arbitrary extensibility for diverse domains using RDF technology (RDFa, SPARQL etc).
Future directions for FOAF should include coverage for cultural heritage data (eg. VIAF from Libraries; Europeana, museums etc.), and ensure some basic naming fields for data from those communities. Also more emphasis on trust (signed data, openid, foaf+ssl), groups etc. built on the basic core plus the extensibility of the SemWeb technology stack.
See also 2004 paper from Joseph Smarr re FOAF and privacy.