Re: atom:modified indicates temporal ORDER not version....
I just found an excellent article on the subject of identity: http://plato.stanford.edu/entries/identity/ It is heavy reading. But it does give an excellent overview of the subject. I can't say that I managed in a couple of hours to fully digest all the information in there. Henry On 22 May 2005, at 02:51, Robert Sayre wrote: On 5/21/05, Henry Story [EMAIL PROTECTED] wrote: On 22 May 2005, at 02:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non- identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Gee, Henry, maybe you should draw us a UML diagram to explain all this. Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. This has nothing to do with versioning. What does atom:id have to do with temporal ordering? Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 22/5/05 7:49 AM, Robert Sayre [EMAIL PROTECTED] wrote: Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. This has nothing to do with versioning. What does atom:id have to do with temporal ordering? It is used to select the members of the set which is to be temporally ordered. It's not used in the ordering itself, of course. In other words - if we have a set of entries, all with the same atom:id, then atom:modified can be used to temporally order them. This is particularly pertinent to those subsets which are defined by the entries having the same atom:updated values. e.
RE: atom:modified indicates temporal ORDER not version....
Robert Sayre wrote: What does atom:id have to do with temporal ordering? Absolutely nothing. Atom:id is used to identify sets of entry instances which, according to the Atom specification, should be considered the same entry. Sets composed of instances of the same entry can then be divided into subsets that share a common atom:updated value. After such a division into subsets, some of the subsets may contain multiple elements which cannot be temporally ordered given the current Atom spec draft. atom:modified provides a means to temporally order the elements of sets which contain multiple elements that share common atom:id and atom:updated values. I believe this was communicated when I wrote: Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. bob wyman
Re: atom:modified indicates temporal ORDER not version....
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: What does atom:id have to do with temporal ordering? Absolutely nothing. Atom:id is used to identify sets of entry instances which, according to the Atom specification, should be considered the same entry. Sets composed of instances of the same entry can then be divided into subsets that share a common atom:updated value. After such a division into subsets, some of the subsets may contain multiple elements which cannot be temporally ordered given the current Atom spec draft. atom:modified provides a means to temporally order the elements of sets which contain multiple elements that share common atom:id and atom:updated values. I believe this was communicated when I wrote: Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. No, that's not what you communicated. How can I temporally order atom entries with different IDs but the same atom:updated value? atom:id and atom:modified are completely unrelated. I don't know what the problem is, but the answer is atom:modified! Robert Sayre
RE: atom:modified indicates temporal ORDER not version....
I wrote: I believe this was communicated when I wrote: Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. Robert Sayre wrote: No, that's not what you communicated. How can I temporally order atom entries with different IDs but the same atom:updated value? atom:id and atom:modified are completely unrelated. I don't know what the problem is, but the answer is atom:modified! Robert, it is clear that your disdain for the current discussions has driven you to the point where you are no longer even reading the posts to which you respond. This is not productive. I have said *nothing* about the temporal ordering of atom entries with different IDs. I have only written about the problem of providing temporal ordering of atom entries that share the same atom:id and atom:updated values. I repeat (with a few added words to make it even more clear): Atom should support atom:modified to permit the temporal-ordering of members of sets whose members share the same atom:id and atom:updated values. bob wyman
Re: atom:modified indicates temporal ORDER not version....
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: I wrote: I believe this was communicated when I wrote: Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. Robert Sayre wrote: No, that's not what you communicated. How can I temporally order atom entries with different IDs but the same atom:updated value? atom:id and atom:modified are completely unrelated. I don't know what the problem is, but the answer is atom:modified! Robert, it is clear that your disdain for the current discussions has driven you to the point where you are no longer even reading the posts to which you respond. This is not productive. I have said *nothing* about the temporal ordering of atom entries with different IDs. I have only written about the problem of providing temporal ordering of atom entries that share the same atom:id and atom:updated values. I repeat (with a few added words to make it even more clear): Atom should support atom:modified to permit the temporal-ordering of members of sets whose members share the same atom:id and atom:updated values. So, it's about disambiguating versions of an entry, right? Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: So, it's about disambiguating versions of an entry, right? No. It has nothing to do with versions or even variants. I have explained that on numerous occasions. The denial of relevance to the issue of version is even in the title of this thread. Read: atom:modified indicates temporal ORDER not version... Clearly, you either aren't reading what you're responding to or you simply don't understand what is written Temporal order of what? They are all the same entry, so what is it you are temporally ordering? Why is this a new problem that only arises when we allow multiple IDs in the same feed? Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 22 May 2005, at 01:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: So, it's about disambiguating versions of an entry, right? No. It has nothing to do with versions or even variants. I have explained that on numerous occasions. The denial of relevance to the issue of version is even in the title of this thread. Read: atom:modified indicates temporal ORDER not version... Clearly, you either aren't reading what you're responding to or you simply don't understand what is written Temporal order of what? They are all the same entry, so what is it you are temporally ordering? You are temporally ordering states of the entry. Or if you think of the id as the resource for which the entry.../ entry text is a representation, then you are ordering the representations sequentially/temporally. Why is this a new problem that only arises when we allow multiple IDs in the same feed? I don't think this is a problem that only arises when we allow multiple ids in the same feed. Henry Robert Sayre
RE: atom:modified indicates temporal ORDER not version....
Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non-identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... Why is this a new problem that only arises when we allow multiple IDs in the same feed? I have been pointing out these issues since long before the issue of multiple IDs (multiple instances) recently regained attention. The issue exists even without duplicate id support but is particularly critical once we support multiple instances of an entry in a single feed document. In the absence of duplicate id support, a reader can infer the temporal order of entries by simply noticing the order in which the entry instances were read from a feed document. (If duplicate ids are prohibited, then if you have read two entry instances which share a common atom:id, they must have been read from different instances of feeds and at different times. Thus, you can infer in some cases that the temporal ordering of the entry instances approximates the temporal ordering of the read operations which retrieved the entry instances. ) However, if you permit multiple instances of an entry in a single feed document then it is possible that you will read multiple entries whose temporal order cannot be inferred. (Note: Order of appearance in a feed does not imply any inter-entry order and thus cannot be used to infer or discover the temporal ordering of entries.) Thus, this issue *is* related to the multiple ID issue in that the problem is exacerbated by permitting multiple instances of a single entry in a single feed document. Whether or not it is relevant in other contexts is largely irrelevant since it appears that addressing the issue in one context will resolve it in other contexts as well. bob wyman
Re: atom:modified indicates temporal ORDER not version....
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non-identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 22 May 2005, at 02:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non- identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Henry Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 5/21/05, Henry Story [EMAIL PROTECTED] wrote: On 22 May 2005, at 02:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non- identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Gee, Henry, maybe you should draw us a UML diagram to explain all this. Robert Sayre
