* Tim Bray <[EMAIL PROTECTED]> [2005-01-04 07:38-0800] > > > On Jan 4, 2005, at 1:39 AM, Henry Story wrote: > > > > >I was just looking closely at the atom:Person class [1] and found some > >pretty arbitrary limitations: > > - why should a Person only have one e-mail address? > > - why should a Person only have one associated url?
(s/url/uri/) > It does seem to me that this will make an implementor's life a little > easier. -Tim So long as these Person-descriptions aren't expected to be complete, it seems a reasonable approach. The atom:uri (homepage or weblog) is a reasonable place to go rummaging for more info about the identified Person. While I like the RSS1 flexibility to include more details inline (eg. foaf:workplaceHomepage, for aggregating feeds by employer), it's perfectly reasonable to partition the work differently, and push the flexibility off to other document formats. >From an RDF perspective, it would be good to be able to consider the Atom:Person 'uri' and 'email' constructs to be "inverse functional properties"[1]. This is a guarantee that, properly used, these fields should identify "at most one thing" that has any given uri, or any given email. In other words, given any value that has correctly appeared as an Atom:Person url or email, there should be no more than one thing it could possibly be the url or email of. This makes it much easier on aggregators, but to possible annoyance of folks who have communal mailboxes and homepages. Revisiting [3.2: Person Constructs] of http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-03.txt 3.2.3 "atom:email" introduces a redundancy, since 3.2.2 "atom:uri" allows for mailto: URIs. Being able to pick out an email address without doing URL analysis seems worthwhile enough that the redundancy has value. But perhaps a note on this would help: a rough proposal: 3.2.2 NOTE: Although mailto: and other messaging-related URIs are technical in-scope for 3.2.3, the atom:email element SHOULD be used for a Person's email address, instead of using mailto: URIs in the atom:uri element. (Worth noting also that the spec also currently allows two emails to be stored, one as a mailto: in atom:uri, the other as atom:email. But you can't legislate against everything...). If atom:uri and/or atom:email could be used to unambiguously pick out some individual atom:Person, I'd be perfectly happy with the limited inline descriptions Atom allows, particular since namespace'd extensions are permissible. I'm not sure on the current definitions though - "a URI associated with" is loose enough that (for eg.) both Martin and myself could use <atom:uri>http://www.w3.org/</atom:uri> without violating the spec. It's the nature of the association that's key. If the association can be specified as uniquely identifying, then aggregators can go rummage around that URI for more FOAF, vCard, XFN etc to flesh out the sparse inline description. At the moment FOAF has two properties somewhat akin to atom:uri, the foaf:homepage and foaf:weblog properties. I've often wondered about a common superproperty (since distinguishing homepages from weblogs is tricky anyway) but just couldn't think of a good name. The simplest fix I can think to propose at the moment is: 3.2.2 s/a URI associated with/a URI uniquely associated with/ ...though I fear "uniquely" might need some more definition, along lines of "Any URI used as the value of an atom:uri element MUST be a URI of a single identifiable entity (Person, corporation or similar entity)." (I make the word "of" do a lot of work here; in FOAF we say "weblog of", "homepage of" which may or may not be close to this WG's thinking). cheers, Dan [1] OWL/RDF jargon. See http://rdfweb.org/mt/foaflog/archives/2003/07/10/12.05.33/ for fairly detailed walk-thru of how this is used in FOAF for identification-via-description.
