Re: Person identity
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).
Re: Person identity
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/39.html Cheers, Danny. -- http://dannyayers.com
Re: Broken RELAX NG Grammar in Appendix B of draft-06
I noticed another bug in the RNG. The collected RNG is missing a '?'
after atomIcon:
atomSourceFeed =
element atom:source-feed {
atomCommonAttributes,
( atomTitle
atomUpdated
atomLink+
atomIcon
should be:
atomSourceFeed =
element atom:source-feed {
atomCommonAttributes,
( atomTitle
atomUpdated
atomLink+
atomIcon?
--
Dave
Re: Person identity
Thomas Broyer wrote: As I already said, this would greatly help storing feeds efficiently in databases or object graphs. Any comment? -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
Minor error in DigSig section
In other words, the presence of an element with the namespace IRI http://www.w3.org/2000/09/xmldsig#; Namespace IRI, is that a find-replace-o? -- Dave
Re: Person identity
On Sat, 19 Mar 2005 11:55:06 +, Bill de hÓra [EMAIL PROTECTED] 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
Re: Broken RELAX NG Grammar in Appendix B of draft-06
David Powell wrote: Two more things I've just noticed: PersonConstructs aren't currently allowing extension elements. anyForeignAttribute and anyForeignElement are currently not used anywhere. Proposal for test procedure: - please publish an updated RNC file somewhere (on atomsub.org?) - those who already produce experimental atom-06 feeds, please check them with that RNC (my test feeds are http://greenbytes.de/tech/webdav/webdav.atom and http://greenbytes.de/tech/webdav/webdav-ietf.atom) Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Editorial: source-feed source
Graham wrote: Every single Atom keyword apart from this new one is a single non-hyphenated word. This one sticks out horribly. Proposal: Rename atom:source-feed to atom:source Sounds good to me. I picked PubSub's deployed name for clarity, and to avoid confusion with the atom:source element we used to have. Long term, atom:source is nicer. Robert Sayre
Re: Broken RELAX NG Grammar in Appendix B of draft-06
David Powell wrote: PersonConstructs aren't currently allowing extension elements. anyForeignAttribute and anyForeignElement are currently not used anywhere. The second point reflects a problem with the draft. I noticed this while writing it, but figured the WG needed to spot it. The atom:entry element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. Ok, but does that imply foreign content is not allowed elsewhere? I suggest the WG did not intend for that to be the case, the sentence from 6.4 more accurately reflects WG opinion: Atom allows foreign markup anywhere in an Atom document. Child elements of atom:entry and atom:feed are considered metadata elements, and are described below. Child elements of Person Constructs are considered to apply to the construct. The role of other foreign markup is undefined by this specification. My personal view was that Person constructs should not define the meaning of foreign content, but the WG clearly favored it. Robert Sayre
Re: s/url/web/
+1 to the just pick something and ship it position On Mar 18, 2005, at 2:44 AM, Dan Brickley wrote: * Bjoern Hoehrmann [EMAIL PROTECTED] [2005-03-18 11:13+0100] * Tim Bray wrote: There are a couple of places where we use uri in the markup, specifically the atom:uri element (3.2.2) and the uri attribute of atom:generator (4.2.5). In both cases they're not actually URIs, they're IRIs, so the name is WRONG, except for nobody knows what an IRI is so renaming them iri would be confusing, and anyhow everyone thinks of URLs not *RIs, but naming them url would be wrong too, so why don't we actually change them to say what they're there for not what their syntax is and use web in both cases? -Tim We can call those at or about or internet but certainly not web. While we're at it, we can relive 10-15 years of URN vs URI debates on the Atom list instead of shipping product. Are you appealing to some notion of 'online' versus 'offline' resource? A spec could be cited from the formal Atom spec? Such distinctions are notoriously hard to maintain... If you want to add an implicit (and imho illadviced) notion of 'URI dereferencability' into the spec, it'd be good to see candidate text for inclusion, rather than doing it via attribute/element name choice. Note that the deferencability of identifiers changes over time, as infrastructure is deployed (or rots away); eg. DOIs, gopher:, java: URIs... Dan -- Mark Nottingham http://www.mnot.net/
