Subject: arbitrary limitations in Person

From: Henry Story <[email-masked]>
Date: Tue, 4 Jan 2005 10:39:40 +0100

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?

It seems to me that one should follow the principle: only impose  
limitations that are proven to be necessary. Here they seem both  
unnecessary and counterintuitive.

Henry

[1]  
http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- 
format-03.txt

---

From: Eric Scheid <[email-masked]>
Date: Tue, 04 Jan 2005 21:04:49 +1100

>  - why should a Person only have one associated url?

any objections to using atom:link here?

(other than generic objections to atom:link, that is)

e.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 04 Jan 2005 21:50:47 +0900

I was asking myself the same questions when I was recently reading
the atom format spec.

Regards,     Martin.

format-03.txt

---

From: Brett Lindsley <[email-masked]>
Date: Tue, 04 Jan 2005 08:03:52 -0600

A while ago I wrote a Pace (but I can't seem to find it, maybe I didn't 
finish
it, it was a while ago...) on using a vCard for the Person. vCards are 
pretty
common and have some XML formats that would fit in to the current spec.
Any interest?

Brett Lindsley, Motorola Labs

---

From: Henry Story <[email-masked]>
Date: Tue, 4 Jan 2005 16:06:12 +0100

I think that the simplicity of atom:Person is fine. I have not checked 
this out carefully, but it should be possible to map it quite easily to 
foaf:Agent[1]. If one specified the following mappings:
      - atom:Person is a subclass of foaf:Agent
      - atom:uri is a super property of foaf:weblog
	 - atom:email is the sub property as foaf:mbox

then we can have an atom segment represented in triples as

_someEntry  --- isa ---> <atom:Entry>
    |----------author---> _somePerson  ---isa-------><atom:Person>
    |                        |------------isa-------><foaf:Person>
   ...                       |-----atom:name-------->"John 
Doe"^^xsd:String
                             
|-----atom:email-------><mailto:[email-masked]>
                             |-----foaf:gender------>"male"^^xsd:String
                             
|----foaf:aimChatID---->"aim:johndoe"^^xsd:String

so I think this translates into the following Atom xml

<entry>
    ....
    <author>
       <name>John Doe</name>
       <email>[email-masked]</email>
       <foaf:gender>male</foaf:gender>
       <foaf:aimChatID>aim:johndoe</foaf:aimChatID>
    </author>
    ....
</entry>

In fact there is a little hitch in the mapping between atom:email and 
foaf:mbox that I have just noticed. foaf:mbox has as object a mailto 
uri. Perhaps this would be a good idea for a improvement to the spec?

Henry Story

[1] http://xmlns.com/foaf/0.1/#term_Agent (In fact I think that we 
should use Agent instead of Person, as it is quite possible that 
robots, or multi-person organizations be creating blog entries or 
feeds.

On 4 Jan 2005, at 15:03, Brett Lindsley wrote:

>
> A while ago I wrote a Pace (but I can't seem to find it, maybe I 
> didn't finish

---

From: Henry Story <[email-masked]>
Date: Tue, 4 Jan 2005 16:31:53 +0100

Oh. I should have mentioned how I see this being able to relate to 
vcards. There is an rdf ontology for vcards on SchemaWeb [1]. It is a 
little odd because it assigns names, addresses and other properties to 
vcards instead of to people. But it would be easy to
add a property from a foaf:Person to a vcard named vcard, that would 
then contain all that info, something like

                             
|----foaf:aimChatID---->"aim:johndoe"^^xsd:String
                             |----xxx:vcard--------->_avcard 
---isa----><vcard:vCard>
                                                        
|---vcard:familyName-->"Doe"
                                                        ...

If you draw me a diagram as above with a good vcard ontology that you 
like, I'll go through the process of step by step showing how one can 
get to an atom xml format
from first principles.

Henry Story

[1] http://www.schemaweb.info/schema/SchemaDetails.aspx?id=215

On 4 Jan 2005, at 16:06, Henry Story wrote:

> this out carefully, but it should be possible to map it quite easily 
> to foaf:Agent[1]. If one specified the following mappings:
>> it, it was a while ago...) on using a vCard for the Person. vCards 
>> are pretty

---

From: Tim Bray <[email-masked]>
Date: Tue, 04 Jan 2005 07:38:27 -0800

>   - why should a Person only have one associated url?

It does seem to me that this will make an implementor's life a little 
easier.  -Tim

---

From: Dan Brickley <[email-masked]>
Date: Tue, 4 Jan 2005 11:28:07 -0500

* Tim Bray <[email-masked]> [2005-01-04 07:38-0800]
> >  - 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 

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.

---

From: Walter Underwood <[email-masked]>
Date: Tue, 04 Jan 2005 08:22:08 -0800

--On January 4, 2005 7:38:27 AM -0800 Tim Bray <[email-masked]> wrote:
> It does seem to me that this will make an implementor's life a little easier.  -Tim

Easier when reading the format, but harder when writing. The user or editor
will need to make selections from a richer (probably LDAP/X.500) record
to reduce it to this limited format.

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.

Using inetOrgPerson also supports:

 - corporate authors (published by Hewlett-Packard)
 - Japanese names (givenname/familyname)
 - nicknames ("Babs Jensen" for "Barbara Jensen")
 - certificates
 - postal addresses

Last time I was involved in LDAP, inetOrgPerson was widely used: Microsoft,
Novell, Netscape/Sun/iPlanet/whatever, and so on.

Tim: want to run this by the directory gurus at Sun and get their input?

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 4 Jan 2005 08:40:17 -0800

At 7:38 AM -0800 1/4/05, Tim Bray wrote:
>>I was just looking closely at the atom:Person class [1] and found 
>>some pretty arbitrary limitations:

But only a little, yet it restricts very common things that people 
have. Let's get rid of the restriction.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Brett Lindsley <[email-masked]>
Date: Tue, 04 Jan 2005 12:27:22 -0600

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.

[1] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/

Henry Story wrote:

>> I think that the simplicity of atom:Person is fine. I have not 
>> checked this out carefully, but it should be possible to map it quite 
>> easily to foaf:Agent[1]. If one specified the following mappings:
>> robots, or multi-person organizations be creating blog entries or feeds.
>>

---

From: Henry Story <[email-masked]>
Date: Wed, 5 Jan 2005 09:38:12 +0100

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.
>

---

From: Scott Wilson <[email-masked]>
Date: Wed, 5 Jan 2005 09:21:59 +0000

There are plenty of schemas for person data:

- FOAF
- VCARD
- HR-XML
- InetOrgPerson
- EduPerson
- IMSEnterprisePerson
- IMSLearnerInformation/BS-8788
- ... etc ...

Of all these, FOAF would seem to me to be closest in intent and 
audience to Atom (even though it does make some odd vocab choices in 
some places, overall I'm a big fan). I worked on the last two, for my 
sins!

However, rather than turn Atom into an identity spec, I would advise an 
approach supporting the absolute minimum of identity information within 
the core spec while allowing the introduction of more detailed 
information where required from other schemas.

So, keep the restrictions as they are, but make sure the practice of 
including appropriately namespaced elements from FOAF is understood as 
being a valid way of extending Atom.

I think this echoes what Henry posted earlier on this topic.

- Scott

=========
Scott Wilson
Centre For Educational Technology Interoperability Standards (CETIS)
Web: http://www.cetis.ac.uk
Atom: http://www.cetis.,ac.uk/news.atom
Foaf: http://www.cetis.ac.uk/members/scott/foaf.rdf

On 4 Jan 2005, at 18:27, Brett Lindsley wrote:

> not having sufficient
> time to keep up with the thread.  I think we all have some motion 
> toward a less constraining
> pop into my head [1]. Since I am not an authority on the alternatives, 
> I hope the experts