I would like to add a big +1 for the suggestions given by Dan Brickley in this thread [1]. Those changes are I believe more important than the ones I was suggesting.
If we tidy up the spec as suggested so that the property email and uri are clearly intended to be inverse functional, i.e. one such property uniquely identifies a single Person, then it is very easy to extend the Person construct with non atom namespaces elements, be they foaf, vCard or RFC 2798 elements transformed into a schema.
That is we need to focus first on making what we have be clearly and correctly extensible. At a later date we can always, as with RSS1.0, specify the more popular extension elements.
So my list of priorities ordered by weight:
[100] Dan Brickley's suggestions.
[2�] Perhaps change the name of the Person construct to a more general Agent
construct
[20] Remove limitation restricting the inverse functional email and uri
properties to 1
Do we need a Pace for Dan Brickley's suggestion?
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11872.html
On 4 Jan 2005, at 19:27, Brett Lindsley wrote:
I appreciate the interesting discussion although I do appologize for not having sufficient time to keep up with the thread. I think we all have some motion toward a less constraining Person construct with the ability to have more detail (phone number, alternate e-mails, or whatever). Having spent a lot of time with SyncML, (RDF/XML) vCard was the first to pop into my head [1]. Since I am not an authority on the alternatives, I hope the experts can propose something better.
Brett Lindsley, Motorola Labs
[1] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/
On 4 Jan 2005, at 19:27, Walter Underwood wrote:
Why not use inetOrgPerson (RFC 2798)? That should provide the easiest mapping to and from most directories.
vCard seems to be a serialization format for directory information, not a data model, so that doesn't really help decide what elements should be in Atom.
