[foaf-dev] FOAF spec next revision

Dan Brickley danbri at danbri.org
Tue Dec 1 16:23:47 CET 2009

On Tue, Dec 1, 2009 at 3:44 PM, Melvin Carvalho
<melvincarvalho at gmail.com> wrote:
> HI All
> I was talking to Libby recently about the FOAF revision coming up and she
> asked me to share with the list a spreadsheet I've been working on.
> It's regarding alignment of FOAF, VCard, Portable Contacts (PoCo) [1] etc.
> It's mainly taken from the list Harry made, but I've had a quick stab at
> adding some elements.
> The sheet is editable and you can add comments on a per row basis, so please
> feel free:
> http://tables.googlelabs.com/DataSource?dsrcid=93156/93156

Thanks for sending this round :)

> Libby suggested that we try and identify on the list, some 'easy wins',
> which perhaps Dan would take into consideration, for the next revision
> (which i understand will be relatively minor)

Yes, the goal here is initially to exercise all the 'moving parts' in
the spec regeneration process, since our toolchain got pretty rusty.
And our brains are also part of that rusty toolchain, so I'd rather
not make any huge changes in this rev.

Just chatting with Libby about the way to handle this and I'm
suggesting we check in drafts as _tmp_editors_live_version.html or
similar, exclude it with robots.txt from the search engines and put
'not to be cited' blahblah in the headers. There are bound to be
mistakes and erm opportunities so I'd like to get the drafting more
visible. Sound like a plan?

Re addressbook stuff, I hope to track / map the core of Portable
Contacts as well as can be managed while fitting with our existing
class/property model, but maybe not in this rev...

See detailed comments below re your suggestions



> We have some inconsistency of naming in the name field: givenname,
> family_name, fullName (and in vcard) given-name
> I would suggest aligning to PoCo the following fields
> givenname -> givenName
> family_name -> familyName

works for me. I'd leave the old in for reference, with some form of
deprecation or at least pointing to the preferred form.

Same consideration re first/last ... for people with datasets that use
those archaic forms, it is quite useful for there to be RDF properties
named directly first/last, ... otherwise we end up forcing them to
guess a mapping to given/family...

> And as a maybe
> title -> honorificPrefix

that one's quite wordy, but it has benefit of not clashing with
dc:title, so we could more easily put DC properties in the same
namespace scope without that clash. So I'd support adding the new, and
leaving the old property with some mild encouragement to people to
migrate. Comments welcomed on this one. I think Graham Higgins
(+cc:'d) had some feedback on this stuff from trying to model bits of
parliament, where people have all kinds of fancy extras to their
names. Graham, do you have a pointer to any summary of your
requirements / issues?



More information about the foaf-dev mailing list