> I think this is a very nice example, and will show the power of seeing > atom as RDF.
Henry: I hope it isn't too depressing to know that, at least for this individual, it really doesn't. To me, you've just sketched out a solution in search of a problem... there are far, far easier ways of getting the same results. Like, say, putting the geo and seismo data together in the entry to begin with. After all, absent a signing mechanism, merging two entries with the same atom:id is only going to get you in trouble. It'd be far simpler for the publisher of Feed A and Feed B to just do any merging on her own (she doesn't need a machine to deduce any relationships within her own data, after all) and produce a Feed C that saves everyone the trouble. > Should it merge these two entries or should it leave > them as separate? In my case, the later entry is ignored... existing entries are never updated once they're in the database. A different app would probably either (a) completely overwrite the old entry with the new one, or (b) declare them to be two distinct versions of the same entry. In any case, there's little pressing need to try and create a Frankenstein's Entry from the two. -- Roger Benningfield
