On 8 Jan 2005, at 16:47, Roger B. wrote:
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 result
Which result? I showed many different things...
0) I had previously already shown that one can see Atom to be RDF, without any
syntax changes.
1) I showed that seeing Atom as RDF makes it easy to structure atom extensions.
It gives us a framework for making intelligent extension decisions.
2) I showed also how one could use the rdf graph information and owl information
to make decisions on how to merge some information and make deductions on
that information.
3) I also showed how one could have nonsensical yet well formed xml, and how
thinking in terms of ontologies (very similar to class diagrams in OO
programming) made this much more apparent.
Clearly there is nothing complicated about 0) above. For those that don't care about RDF, ie: most simple aggregators at first, they won't need anything more than a simple xml parser. For them there is nothing to it. They can just ignore anything that is outside the atom namespace.
I think for the rest of the points above the argument is pretty much the same. If you don't want to create extensions, having a framework with which to do them won't be of any interest to you. But for those who do it makes a *huge* difference. For those that don't care to reason about the data the structure made available by rdf is not of great interest. But that does not make it not useful to others.
You can look at the web with a black and white browser, and not care about color tags in your html. That was not a reason for excluding color tags from the spec.
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.
I can't at the same time show how you can do deductions and also show how one sets up a trust network, and everything else that entails in one e-mail...
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 BlogEd I do (b) and what you do. IE. I never change an entry in the database and I would declare them to be different version of each other. Ie: I have two entries pointing to the same EntryID, which is exactly what the spec says.
In any case, there's little pressing need to try and create a Frankenstein's Entry from the two.
I don't think you understood what I was trying to say in my mail there. Perhaps I was not clear.
I showed how one could use machine readable information to deduce that the two entries should not be merged. This deduction could be done by a machine using that data of course or simply hardcoded by a human programmer who wrote the storage layer. That is indeed the correct behavior and it is the one that your program exhibits (it throws one entry away, but what you do with your data is completely up to you)
The "Frankenstein Entry" was in relation to this graph:
_f1 ---is a---> <Feed>
|----head----> ....
|----entry---> _e1 --is a---> <Entry>
|----id-----> <http://123>
|---date----> "2005-02-02T13:05:04"^^xsd:dateTime
|---geo:x--->"10.1"
|---geo:y--->"57.3"in particular this subgraph:
_e1 --is a---> <Entry>
|----id-----> <http://123>
|---date----> "2005-02-02T13:05:04"^^xsd:dateTime
|---geo:x--->"10.1"
|---geo:y--->"57.3"which corresponds to the xml
<entry> <id>http://123</id> <date>2005-02-02</date> <geo:x>10.1</geo:x> <geo:y>57.3</geo:y> </entry>
Here our RDF model (or Tim Bray's intuition) would say that the geo:x and geo:y
properties are properties of _e1. That means that _e1 has to be some thing of type Geographical Position. _e1 would then be a thing of type Entry and of type Geographical Position. Which is a bit of a messy kind of thing. In particular since the id property of this thing is functional you would have a completely different Geo/Entry depending on what the id was. This is clearly very different from what we take the geo:x and geo:y properties to be referring to.
-- Roger Benningfield
