Saturday, January 8, 2005, 9:59:12 AM, you wrote:
> Say your system is aggregating material from two sensors, and you get > the following, one from each: > <entry> > <id>http://123</id> > <date>2005-02-02</date> > <geo:x>10.1</geo:x> > <geo:y>57.3</geo:y> > </entry> > <entry> > <id>http://123</id> > <date>2005-02-03</date> > <seismo:magnitude>7</seismo:magnitude> > </entry> > It isn't clear how these should be merged - does the entry with the > later date replace the earlier one? The (presumably) desired behaviour > is for the geo+seismo properties all to appear as elements under > (properties of) the entry. Mapping syntax to a model can help decide > what to do *in the general case* rather than per-extension. As it > happens, RSS/RDF would only go part of the way with something like > this - you'd get the desired merged entry, but with two dates. I think that reason that RDF is only helping partially here is that you have a simplified model of an entry that is actually only modelling the state of an entry at a point in time, when actually entries are expected to vary over time and have multiple instances. This is fine, it is a useful simplification; models are supposed to be simplifications. But you can't then expect to merge two different instances of the entry under this model using simple RDF graph merging, because the model is an over-simplification. Eg: If you merged: <entry> <id>http://123</id> <date>2005-02-03</date> <seismo:magnitude>7</seismo:magnitude> </entry> and <entry> <id>http://123</id> <date>2005-02-04</date> <seismo:magnitude>7.5</seismo:magnitude> </entry> ... you would get: <entry> <id>http://123</id> <date>2005-02-03</date> <date>2005-02-04</date> <seismo:magnitude>7.5</seismo:magnitude> <seismo:magnitude>7</seismo:magnitude> </entry> Not very useful. A solution for RDF-based applications wanting to merge incoming RSS and get a consistent RDF model is to either have special application-level merging logic that knows about the simplification that has been made; or to have a model where instances of an entry are modelled explicitly. If the instances have ids, then you can allow for both posting new instances of entries, and annotating existing instances with extra information. Its a tradeoff between flexibility and complexity. -- Dave
