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/
On 18 Mar 2005, at 16:23, Thomas Broyer wrote:
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).
