On 7 Feb 2005, at 00:09, Roy T. Fielding wrote:
On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote:* John Panzer <[EMAIL PROTECTED]> [2005-02-06 13:58-0800]
Since an entry is identified uniquely by its atom:id (though it can have
different states at different times);
As I understand the Web, the "REST" concepts that underpin HTTP are quite happy with their being multiple representations of the selfsame resource *at the time*.
Also at multiple times.
Yes, it's all about time, but also about resources. The entry is a resource, and that resource may have multiple representations at a single time (atom, rss1, rss2) and also over different times. A resource has a single state at one point in time, but may have different states over time (in some case they must have different states over time because that is the essence of what makes them a resource, just as a clock is expected to have different state). URIs identify resources, not necessarily singular states.
It is about resources, but the question is what the id resource identifies.
There are two things the id resource could identify:
a- the uri of the entry (rdf:about)
b- a uri related to the entry by the id relation (rdf:resource)
I find interpretation b to be the most powerful one, because it allows us to narrow the disagreement between both factions down to the properties of the id relation.
Here is how I model in rdf arrow notation the atom example [1]:
_entry |--title-> "Atom Powered Robots Run Amok" |--link--> <http://example.org/2003/12/13/atom03> |--id----> <vemmi://example.org/2003/32397> |-update-> "2003-12-13T18:30:02Z"^^xsd:dateTime
The differences this group has as to the interpretation of the id relation can be explained as follows: -those that like Bob Wyman and me-currently, believe that id is just a functional relation. Call this the [Functional Id] theory. -others like Roy Fielding and me-when-I-first-thought-of-the-issue, think of id as an equivalence relation (which I think just means that the relation is functional, symmetric and transitive). Call this the [Equivalence Id] theory.
Under the [Equivalence ID] theory, the above graph has the following graph as consequence.
<vemmi://example.org/2003/32397> |--title-> "Atom Powered Robots Run Amok" |--link--> <http://example.org/2003/12/13/atom03> |-update-> "2003-12-13T18:30:02Z"^^xsd:dateTime
The above conclusion cannot be drawn from the [Functional ID] theory.
Note that both theories:
- are expressed in terms of resources
- could easily be compatible: it would just require
distinguishing the [Equivalence ID] relation and the
[Functional ID] relation by naming them differently.Let us do so now:
[Functional ID] -> funcId
[Equivalence ID] -> equivIdFeeds are sliding window resources, but their representations do not slide -- they are fixed at a given point in time.
Yes, I agree. But the time component is only as important as you say if you emphasize http URIs for your id. But that will come out more clearly below.
If it is reasonable to say that, at any single point in time, only one representation of a given entry can appear in the feed's representation, then the only valid representation of a feed is one that does not contain any duplicate entry id's.
This is true only if you have the [Equivalence ID] interpretation of the id relation. (Ie you think of id as equivId.)
To give a more concrete example let us use the well understood http URIs for our ids, and let us disambiguate the two id types.
_entry |--title---> "Atom Powered Robots Run Amok" |--link--> <http://bblfish.net/2005/02/07/entry03/v2/entry.html> |--funcId--> <http://bblfish.net/2005/02/07/entry03/> |--equivId-> <http://bblfish.net/2005/02/07/entry03/v2/> |-update---> "2003-12-13T18:30:02Z"^^xsd:dateTime
The file system layout would be something like the following (taking root at 2005/02/07 to save space)
entry03 <-- a directory resource pointed to by the funcId uri entry03/v1 <-- a directory resource for the previous entry version entry03/v1/entry/xml <-- the first entry version of the xml entry03/v1/entry.html <-- the second entry version in html form entry03/v2 <-- a directory resource pointed to by the equivId uri entry03/v2/entry.xml <-- the second entry version in xml format entry03/v2/entry.html <-- the first entry version in html format
With the above file system layout it would therefore be completely feasible to have a feed that would correctly state at a precise time the following:
<feed>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://bblfish.net/2005/02/07/entry03/v1/entry.html"/>
<funcId>http://bblfish.net/2005/02/07/entry03/</id>
<equivId>http://bblfish.net/2005/02/07/entry03/v1/</id>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://bblfish.net/2005/02/07/entry03/v2/entry.html"/>
<funcId>http://bblfish.net/2005/02/07/entry03/</id>
<equivId>http://bblfish.net/2005/02/07/entry03/v2/</id>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</feed>There are indeed two versions of the entry at one point in time with the same funcIds specified above, but as you also rightly point out two *different* equivIds.
An atom:feed document is a representation of a single feed resource at a single point in time.
ok.
Aggregators do not consume feed resources -- they consume an iterative set of overlapping feed representations. Aggregators are therefore required by Atom to only include the "latest" version of an entry within their own resource representations.
Only if you reduce the toolset available by requiring no one use a funcId relation. Otherwise it is quite possible to have multiple versions of an entry in the same feed as I clearly showed above.
I believe that these requirements reflect the desires of most of the participants in this working group, so it seems to me that the question has been answered.
Now is the time to question this statement.
I would like to start by an obvious objections someone is bound to make to the example file system layout I described above, namely that it is much too complicated for most end users [2], and that most blog layouts will only have a simple, non versioned, layout. Something more like this:
2005/02/07/entry03 <-- a directory resource for the entry 2005/02/07/entry03/entry.xml <-- the xml version of the entry 2005/02/07/entry03/entry.html <-- the html version of the entry 2005/02/07/entry04/ <-- a directory resource for another entry 2005/02/07/entry04/entry.xml 2005/02/07/entry04/entry.html
If the id were to point to the
<http://bblfish.net/2005/02/07/entry03/>
resource, as one would be tempted to do, then this would clearly imply a [Equivalence ID] interpretation of id, and so of course having two differing entries with the same id in a feed document would be saying something contradictory and false.
This is an obvious intuition, that I myself followed for a long time.
But of course this does not take into account this groups very long and convoluted discussions concerning the Identity Constructs, and the discussions about what an id really should be: should it just be a String? A String that can be seen to be a URI, but should not be thought to be one? ... Many people have vocally tried to limit the URIs allowed for an id to the set of URIs that are *not* URLs. In fact the default example given in the spec does not use a URL but some 'vemmi' URI.
Non URL URIs such as 'vemmi' URIs are needed to create a non temporal identity of an entry that allows even simple file system layouts such as the one just shown to be given an id that makes sense in the [Functional ID] interpretation.
Here is how the feed can be composed of such entries without
this raising any special problem.
<feed>...
<entry>
<title>Atom-Powered Robots Really Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<funcId>vemmi://example.org/2003/32397</id>
<updated>2005-02-07T09:30:02Z</updated>
</entry>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<funcId>vemmi://example.org/2003/32397</id>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</feed>Since entries here described are just versions of the <vemmi://example.org/2003/32397> atemporal entry.
So without trying to work out or guess what the changing desires of this working group are (I myself moved from one side to the other on this issue), I think we should rather try to decide on by weighing as Bob Wyman did, the advantages of each.
And if this still does not allow one to choose one should perhaps just allow both.
Henry Story
Ps. If you do read this please send me a postcard, or short e-mail :-)
Cheers,
Roy T. Fielding <http://roy.gbiv.com/> Chief Scientist, Day Software <http://www.day.com/>
[1] _entry is a blank node as indicated by the leading '_'
The graph is a simplified version of a full model for purposed
of focusing on the current problem
The atom example is the one available here:
<http://atompub.org/2005/01/27/draft-ietf-atompub-format -05.html#rfc.section.1.2>
or here <http://tinyurl.com/58z6g>
[2] though I wonder really how much weight arguments like this should have on IETF (Internet *Engineering* Task Force) groups, where we are already in the process of writing a huge spec, that requires understanding if HTTP, XML etc, none of which are that simple...
