[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Semantics of Entry





On 12 Jun 2004, at 10:34, Danny Ayers wrote:

Henry Story wrote:

tag:fish.net,2004-05-20:e1
                    |------isa---------> DannyEntry
                    |------title-------> content1: "great day"
                    |------content-----> content2: "I love sunni daze"
                    |------content-----> content3: "I love sunni days"
                    |------created-----> 20 May 2004, 8 am
                    |------modified----> 20 May 2004, 4 pm


The problem with this theory is that we now no longer know which of content2 or content3 is the latest one (No cheating and guessing that because one has a 3 in the name it is likely to be after the one that has 2 in the name)


At that point I believe Atom differs - it doesn't add new statements, it modifies existing ones (hence the 'modified' date).

Atom modifies Entries. We are modeling the Atom Feed using RDF statements conforming to an OWL description. So it is up to us how we interpret the "modified" predicate.


Once content=content3 has been declared, content2 is flushed from the universe.

In the model I propose I can also flush old entry states, if I no longer want to keep them in the database. I will then have a less historically complete view of the feed, but I will still have a truthful one.


Ok, older versions can be preserved, but they don't have to be, they aren't really an essential part of the model.

Maybe it might be more accurate to step outside the local Atom model and consider each entry as an ordered list, but given that few applications make use of the diffs it seems unnecessary.

To tell the truth I think perhaps both models (with or without EntryState) are valid models of Atom. In fact there is probably a simple mapping from the new model to the original, non State class containing, model.


One advantage of the EntryState class is that it allows you to parse an atom feed into triples and just append the triples to the end of your database without having to go through any triples deletion procedure, which can be quite expensive. It also should make merging two versions of a feed very simple.

But it may be that this is a need that is specific only to a subset of applications.


Cheers,
Danny.

http://dannyayers.com


Thanks for the feedback.


Henry
http://bblfish.net/