Subject: Person "identity"

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 18 Mar 2005 16:23:06 +0100 (CET)

Hi there,

It seems something's missing about authors and contributors...

This is allowed:
<entry>
<author><name>Thomas Broyer</name></author>
<contributors>
<contributor><name>Thomas Broyer</name></contributor></name>
...
</entry>

as well as:
<contributors>
<contributor><name>Thomas Broyer</name></contributor>
<contributor><name>Thomas Broyer</name></contributor>
</contributors>

or even (less obvious):
<contributors>
<contributor><name>Thomas Broyer</name></contributor>
<contributor><name>Broyer, Thomas</name></contributor>
<contributor><name>T. Broyer</name></contributor>
</contributors>

or
<contributors>
<contributor>
  <name>Thomas Broyer</name>
  <email>[email-masked]</email>
</contributor>
<contributor>
  <name>Thomas Broyer</name>
  <email>[email-masked]</email>
</contributor>
<contributor>
  <name>Thomas Broyer</name>
  <email>[email-masked]</email>
</contributors>

There's no way in Atom to indentify persons as the same person or just
homonyms!

We also can't store a feed/entry _efficiently_ in a relational database or
an object graph.
There's no way for a processor to tell its user which other entries (in the
same feed or even in other feeds!) have been authored or contributed by the
same person (think about the "by the same author" in printed books).

PacePersonRef would have solved part of the problem (identifying other
entries authored or contributed by someone in the same feed; but not in any
feed).

I propose adding an optional atom:id element to the Person construct
content model, with the following rules (to be reworded before adding into
the spec):
 a) There MUST NOT exists more than one contributor with the same id in an
entry of feed
 b) There MUST NOT exists a contributor with the same id as the author in
an entry or feed
 c) Each Person construct (in a feed) refering to the same
person/organization/etc. SHOULD be identical (same value for atom:name,
atom:id, atom:email and atom:uri; and if, e.g., atom:email is given, it
SHOULD appear in each of these Person construct)
 d) Person constructs refering to different persons/organizations/etc.
SHOULD use different atom:name values all over the feed/entry
 e) atom:id SHOULD be provided if known but MUST NOT be generated
automatically "just to provide one" or be given without the actual
person/organization/etc. aknowledgement (as it is a _globally_ unique
identifier).

The main impact is the validation of the above rules, otherwise, the
impact is rather reduced.

As I already said, this would greatly help storing feeds efficiently in
databases or object graphs.

Any comment?

-- 
Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Fri, 18 Mar 2005 08:56:33 -0700

On Friday, March 18, 2005, at 08:23  AM, Thomas Broyer wrote:
> content model,
If it's not too late, I wouldn't be opposed to this, but I'm not sure I 
agree entirely with the specific rules.

> with the following rules (to be reworded before adding into
> the spec):
+1 as long as this doesn't mean that you can't have duplicate IDs in a 
single entry or at the feed level, but that the same ID CAN exist in 
different entries, or at the feed level AND in entries.  I imagine this 
is what you mean, but just to be sure it's clear...

>  b) There MUST NOT exists a contributor with the same id as the author 
+1 with the same condition as above

> SHOULD appear in each of these Person construct)
I'm not sure I'd agree with this for a few reasons:

1) A person acting in a different role as the author of a particular 
entry, for example, might want to use a different email address, URI, 
etc.  If we specify that that person SHOULD have a different atom:id 
for their different roles if that role would affect the appropriate 
values for the other Person construct children, then okay.

2) I don't think we should require (or virtually require) that each 
Person construct sharing an ID contain the same set of child elements.  
But we could say that the values of any child elements that ARE 
included SHOULD be identical.

> SHOULD use different atom:name values all over the feed/entry
-1.  What if two people named John Smith contribute an entry to the 
same feed?  Does one have to alter their name?  Having a different ID, 
or one having an ID and the other not having one should be how the 
distinction is made.

> person/organization/etc. aknowledgement (as it is a _globally_ unique
+1.

---

From: Henry Story <[email-masked]>
Date: Sat, 19 Mar 2005 09:47:17 +0100

I like this - even though I disagree with the constraints - as it 
follows
nicely on the parallel I developed in the Madonna example [1]
between personal identity and entry identity.

Clearly if the same atom:id were to be used then we are identifying the
id that appears in an entry and the id that would appear in the Person
construct.

But I have argued that the relation between an entry and the relation
of atom:id is a functional one, ie:
   - that an entry can only have one atom:id relation to an id construct
   - that an id construct can have many 1/atom:id (the inverse relation)
     relations to Entry constructs.

This makes sense: entries can change over time and we wish to be able
to capture this fact logically. Entries as they appear in an Atom feed
are time-stamped objects. Each of these time stamped objects with the
same id is a different version of the same timeless entry.

This could be equally true of the Person construct and its relation
to the atom:id that identifies it. But in that case we have to allow,
as with entries, that things can change. So that one could have a
Person construct with the same id and yet different properties (people 
change
their e-mail address over time, live in different places, etc) In the 
atom case
this is at present not very useful, since there are not many other 
properties,
and since we do not time stamp, as we do with entries, the Person
constructs. But this would have to be a consequence of using the same
atom:id tag as we use in the entry. And so consequently the proposed
restriction (c) is incompatible with the atom:id name.

It is important to notice that there are two relations (at least) that
relate temporally changing objects like Persons and Entries to their
ids:
   (1) a relation that relates a temporal part of the person to the id
   (2) a relation that relates the unchanging mereological sum [2] of 
these
      parts to the id.

(2) may be an inverse functional relation, ie:
	- there is only one such object related to the id construct in such a 
way.
     - there may be more than one id that identifies the same person.

  (2) is closer to the relation the foaf [3] folks have used to
   identify the Person and agent objects. And (2) is also closer to
   the intent of your restriction (c). Given the popularity of foaf,
   people may be inclined to associate the atom:Person construct with the
   foaf:Person.

Note also that these are two different but non exclusive relations. The
unchanging Person that is Tim Bray, the 4 dimensional object that exists
from a certain conception moment to a certain death moment (assuming he
is mortal), has many temporal parts, one or more of which may be reading
this sentence. The 4 dimensional unchanging object has a relation to Tim
Bray's social security number. But so of course do the temporal parts
mentioned above. If we have two different descriptions of this 4 
dimensional
object then we can merge these descriptions and still say something 
true.
This is not true of any of the temporal parts. One of the temporal parts
reading the above sentence may be scratching his head in Vancouver and 
the
other may be flying over California, and it would be wrong to merge the 
two
and say that they were both in Vancouver and over California.

So in conclusion either:
   - you have to drop (c)
   - or you have to give the relation a name other than atom:id

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg13618.html
[2] http://plato.stanford.edu/entries/mereology/
[3] http://xmlns.com/foaf/0.1/

---

From: Danny Ayers <[email-masked]>
Date: Sat, 19 Mar 2005 12:39:20 +0100

The use cases are good, and even before you start looking at the
relationship between entries and people there are limits to what you
can do with the author/contributor constructs.

This general issue has had 4+ years of hammering in theory and
practical deployment around FOAF, which is been successfully used in
RSS 1.0 feeds. This kind of data can be stored/queried reasonably
efficiently in databases.

There's a write-up "Identifying things in FOAF":

http://rdfweb.org/mt/foaflog/archives/000039.html

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 19 Mar 2005 11:55:06 +0000

> databases or object graphs.

-1. The WG shouldn't contemplate standardizing identity management at 
this time.

This is a complex problem domain, even in closed systems. Feed format 
specs are not the right place to try and deal with it. Extend Atom with 
FOAF instead if you really need these capabilities in the near term.

cheers
Bill

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 19 Mar 2005 14:58:08 +0100

> -1. The WG shouldn't contemplate standardizing identity management at 

Yes, it could be pinned out until the next Atom version.

> FOAF instead if you really need these capabilities in the near term.

I can't disagree, but the Atom spec don't say anything about having the 
same person as the author and contributor, or multiple times as 
contributor to the same entry, and this is quite "bizarre", isn't it? 
There could be a line in the spec suggesting a person to appear only 
once per entry, even if we can't enforce it at a syntax level.

And let's use a FOAF extension until something is added to Atom in a 
future version.

-- 
Thomas Broyer

---

From: Danny Ayers <[email-masked]>
Date: Sat, 19 Mar 2005 15:02:06 +0100

On Sat, 19 Mar 2005 11:55:06 +0000, Bill de hÓra <[email-masked]> wrote:

Extend Atom with
> FOAF instead if you really need these capabilities in the near term.

Yep, given the timescales involved, that sounds like a good pragmatic solution.

Even if Atom doesn't support it, and feeds don't use the extension,
your own database can implement something like FOAF "smushing" based
on properties of entries. If you find two entries with an author
(foaf:name) "Bill de h&#211;ra" associated (directly or indirectly)
with URI (foaf:homepage) http://www.dehora.net/journal/ then chances
are it's the same person.

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 19 Mar 2005 15:25:24 +0100

> Yep, given the timescales involved, that sounds like a good pragmatic solution.

+1, as said in another mail.

> are it's the same person.

Well actually I was thinking about creating a "unified feed API" (in 
.NET, but could be ported to other languages) and trying to reduce 
memory footprint by reusing Person objects, as well as providing 
relations (bidi-arcs) between a Person and the Entries he/she has 
authored or contributed.

End of discussion, until next Atom version ;o)

-- 
Thomas Broyer

---

From: Danny Ayers <[email-masked]>
Date: Sun, 20 Mar 2005 13:31:28 +0100

> relations (bidi-arcs) between a Person and the Entries he/she has

Yep, I don't see why not. Irrespective of memory etc, this would seem
(IMHO) the best approach to Atom Persons if you're programming with
objects.

The Atom model is only specified through prose and the implications of
syntax constraints, but I'm sure there's enough to start a "unified
API". I personally believe the best approach to this is through a
unified machine-readable model, specified in RDF/OWL. This is
more-or-less the approach to Atom being taken by Henry Story in BlogEd
(Java) and Mark Nottingham for Sparta (Python).

> End of discussion, until next Atom version ;o)

But only the beginning of implementation!

Cheers,
Danny.

Early OWL model draft: http://semtext.org/atom/

Henry's refactoring/implementation:
http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html

Mark's sparta notes:
http://www.mnot.net/blog/2005/03/17/sparta

-- 

http://dannyayers.com