On 6 Jul 2006, at 02:37, Elias Torres wrote:
9. I'm not sure why we are forcing order by atom:updated. This gives
no room to server-side or client requested ordering.
+1
atom:updated is not enough for a client to synchronize with a server
without having to retrieve every "page" of the collection feed,
because atom:updated might not be changed while the entry has ben
modified.
In case the client can do a GET to the entry IRI just before editing
it, it's OK, but that's not the case during offline editing...
I definitely see your problem with it. I wasn't going as far as
talking
about synchronization, but you are right. Is synchronization part
of the
scope of the spec? I bet the WG/Gang/Crew is not too interested in
solving that problem.
I would say that synchronization is covered. If the updated time
stamp is not modified then that means that there is no "significant"
change. And so there is nothing to update.
1. Detour through AtomOwl
-------------------------
I'll make a slight detour through Atom Owl [1] for a more precise
demonstration.
(There are some new elements in this demonstration by the way. I have
never been able to make it this clear before, as we have only
recently resolved some problems that help make this case. )
In AtomOwl the above is expressed by:
[] cifp:productProperty ( :updated :id );
a owl:InverseFunctionalProperty .
That means that if we have the two entries written in N3 as
_:e1 a :Entry;
:title "My first Entry"^:text
:id <tag:eg.com,2006/e1>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime.
_:e2 a :Entry;
:title "My First Entry"^:text
:id <tag:eg.com,2006/e1>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime.
Then since the :id and :updated time stamp of both are the same we
conclude that
_:e1 owl:sameAs _:e2 .
and so after smushing the graph:
[] a :Entry;
:title "My first Entry"^:text ;
:title "My First Entry"^:text ;
:id <tag:eg.com,2006/e1>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime.
which is the same as
[] a :Entry;
:title [ :text "My first Entry" ];
:title [ :text "My First Entry" ];
:id <tag:eg.com,2006/e1>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime.
Let us name the two anonymous title object above:
_:t1 :text "My first Entry" .
_:t2 :text "My First Entry" .
our entry can then be written:
[] a :Entry;
:title _:t1;
:title _:t2 .
now since :title is a owl:FunctionalProperty we have
_:t1 owl:sameAs _:t2 .
ie:
[] a :Entry;
:title [ :text "My first Entry";
:text "My First Entry" ] .
which is believe it or not, ok!
:text is an inverse functional property, and atom :Content objects
have very weakly
defined identity relations. (ie. it is not character for character
identity).
So if someone changes an old entry without changing :updated, there
is not need to synchronise anything since you are dealing with
exactly the same (vaguely defined) thing.
2. Limitations on Atom Content
------------------------------
This vaguely defined thing that is an atom content, does have some
restrictions and limitations that are in part defined by usage and
will clearly be by law.
The protocol clearly specifies one type of restriction: namely that
entries should be ordered by their :updated time stamp. So people who
make updates to entries without changing their :updated time stamp
will not get their entries synchronized (since they are declaring
them to not have changed!).
By law: I am ready to bet that if your bank puts up an atom feed with
information about your bank account information, then removes money
from your account but does not specify an :updated time stamp, and
furthermore does this in a recurring way that shows intent to
deceive, they will be held liable for lying to their clients. And
lawyers will be delighted to help some money flow in the other
direction.
I am sure there are other constraints. We cannot put everything into
words. With our ontology we can create a framework to help constrain
things lightly.
Henry Story
[1] http://bblfish.net/work/atom-owl/2006-06-06/
I have just updated it, after noticing some things that had not
been properly changed.
