On 8 Feb 2005, at 01:49, Roy T. Fielding wrote:
On Feb 7, 2005, at 5:15 AM, Henry Story wrote:This is true only if you have the [Equivalence ID] interpretation of the id relation. (Ie you think of id as equivId.)
Yes, and to make myself perfectly clear, that means functional ID, as you call it, would conflict with the design of Atom and any reasonable design of a system wherein the things being identified are allowed to be updated over time.
I wonder if you read the rest of my message...
Yes, though it seems to me that you swapped the meanings of funcId and equivId somewhere between your definitions and your example, so I lost interest.
Well I just looked very carefully again at the mail and though I found plenty of places I could have expressed myself better, I did not see any swapping as such take place.
I gave an example that did not conflict with a reasonable design.
On the contrary, you gave an example in which a feed contained two entries with the same id
the same funcId to be clear, but two equivIds. It is equivIds that are the ones you are thinking of, and that have the limitations you mention: there cannot be two entries in a feed document that have the same equivId but that are in any other way different, on pain of the document being self contradictory. Hence I did not make a document with two equivId entries.
What I wished to show is that you are correct about equivIds, but that another type of id exists (funcIds) that are less strict and that don't have the same consequence. There can be more than one entry in the same feed document with the same functId and with differing content, without there being any contradiction.
(where id here is defined as meaning the author intends this entry to supplant any prior entries with the same id). It is not reasonable to include more than one entry with the same id within the same feed representation, since all entry representations in the feed representation must validly represent the state of the feed at the time that the feed representation was generated (otherwise, it is not a feed representation at all -- it is an archive, history, ... whatever).
Worse!: A document with two entries with the same equivId but different content is inconsistent. It is not an archive, history or anything else.
Let me proove this. Consider the following example I used at the end of my lengthy post, but with the funcId replaced by equivIds.
<feed>...
<entry>
<title>Atom-Powered Robots Really Run Amok!</title>
<equivId>vemmi://example.org/2003/32397</equivId>
<updated>2005-02-07T09:30:02Z</updated>
</entry>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<equivId>vemmi://example.org/2003/32397</equivId>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</feed>Now let me model this again in arrow notation because it is relatively easy to understand and to visualise (I could do it in prose too, but would be certain to loose your attention before the first sentence)
_feed |-entry->_e1 | |--title-> "Atom-Powered Robots Really Run Amok!" | |--equivId-> <vemmi://example.org/2003/32397> | |--updated-> "2005-02-07T09:30:02Z" |-entry->_e2 |--title-> "Atom-Powered Robots Run Amok" |--equivId-> <vemmi://example.org/2003/32397> |--updated-> "2003-12-13T18:30:02Z"
because equivId is an equivalence relation [1], it is reflexive [2] and so for all Entry or Feed objects ef, ef equivId ef. The above graph therefore entails [3] the graph:
_feed |-entry-> <vemmi://example.org/2003/32397> | |--title-> "Atom-Powered Robots Really Run Amok!" | |--equivId-> <vemmi://example.org/2003/32397> | |--updated-> "2005-02-07T09:30:02Z" |-entry-> <vemmi://example.org/2003/32397> |--title-> "Atom-Powered Robots Run Amok" |--equivId-> <vemmi://example.org/2003/32397> |--updated-> "2003-12-13T18:30:02Z"
We can simplify the graph by removing the superfluous equivId statements.
_feed |-entry-> <vemmi://example.org/2003/32397> | |--title-> "Atom-Powered Robots Really Run Amok!" | |--updated-> "2005-02-07T09:30:02Z" |-entry-> <vemmi://example.org/2003/32397> |--title-> "Atom-Powered Robots Run Amok" |--updated-> "2003-12-13T18:30:02Z"
And now we since the two groups of entries are speaking about the same resource <vemmi://example.org/2003/32397> we can compact the graph down to
_feed |-entry-> <vemmi://example.org/2003/32397> |--title-> "Atom-Powered Robots Really Run Amok!" |--title-> "Atom-Powered Robots Run Amok" |--updated-> "2003-12-13T18:30:02Z" |--updated-> "2005-02-07T09:30:02Z"
Now the problem is that our ontology [4] imposes a restriction on the number of titles and update dates an entry can have. The limitation is: they can only have one. The above assigns them two of each. So if we combine the above graph with the ontology which it is loaded with we have our contradiction. We cannot proceed.
If instead of having equivId in the above xml you have funcId then the first entailment is not possible, and so we don't have a contradiction. These are just very different concepts, though they can both correctly be thought of as identifiers.
This whole discussion presumes that it is not desirable to send all versions of all entries as part of the feed; i.e., the author specifically intends old versions of an entry to never appear in later versions of the feed. If you don't agree with that presumption, then I think you are talking about something other than what most bloggers call a feed.
What I am interested in, as a feed reader, is an automatic way of getting to know about the changes to content that occur on a site.
Sometimes I will be interested in the history of changes, sometimes
not. Some services will be interested in providing me with the history
of changes others not.
FuncId allows people to send just the latest version of their site if they wish, or the full list of changes. What is the correct thing to send will depend on the usage of the feed. Why impose an unnecessary limitation? Certainly we are not such slaves to the past that we limit what we do for the sole reason that our ancestors did it that way.
So, please, stop trying to make a real system fit an artificial model of graph theory that isn't even capable of describing the Web. Fix your model instead.
Do you have a good paper that proves your incredibly strong statement above? I would be happy to understand this position, as it would save me a lot of time.
Okay, but only if you promise not to extend this discussion on the atom list -- take it elsewhere if you wish to puncture my opinion -- atom should be allowed to progress in peace without invoking the defenders of RDF universality.
<http://www.w3.org/TR/rdf-mt/#intro>:
Well I don't want to go into a side discussion on such a topic. I think all I need to point out is that I have been using extremely simple mathematical concepts to do with binary relations [1][2][3] that are very easy to understand. The concept of symmetry, transitivity and reflexivity are taught in France to children age 13. It is clearly within the grasp of any engineer. As with most great ideas, it is the simplicity and clarity of their foundations that enable them to go so far.
By the way I very much enjoyed reading your thesis. [5]
Cheers,
Roy T. Fielding <http://roy.gbiv.com/> Chief Scientist, Day Software <http://www.day.com/>
Henry Story http://bblfish.net/blog/
[1] http://en.wikipedia.org/wiki/Equivalence [2] http://en.wikipedia.org/wiki/Reflexive_relation [3] http://en.wikipedia.org/wiki/Entailment [4] see http://www.intertwingly.net/wiki/pie/AtomOWL but it is also clear from the syntax that these restrictions apply [5] http://www.bblfish.net/blog/page1.html#10
