* 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:urihttp://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.
