On Fri, 7 Jan 2005 16:39:41 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: > > On Friday, January 7, 2005, at 03:53 PM, Danny Ayers wrote: > > On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy > > <[EMAIL PROTECTED]> wrote: > >> Could you give an example of something useful that a real world > >> application would be enabled to do? > > > > Off the top of my head, how about categorizing entries by their > > properties. > > I don't understand. Could I get some example XML, and if the XML > doesn't make it obvious, an explanation of how RDF makes this possible > where it's not possible lacking RDF?
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. > > But being able to mix extensions in a predictable fashion is generally > > nice to have. Last time I looked my own RSS 1.0 feed was using terms > > from 9 namespaces (mostly through the FOAF output plugin). I could > > merge with lots of other peoples RSS 1.0 feeds and be sure all the > > same information would still be available. If it wasn't mapped to a > > common model (through the structure) I wouldn't even know how to > > merge. > > Again, I don't understand. When you talk of merging feeds, do you mean > making a feed out of entries from separate feeds (but where the entries > themselves are not altered), or merging the entries themselves, where > sometimes the feeds contain different instances of the same entries, > resulting in entries containing more data than exists in any one feed? > Either way, what information might become unavailable in the process? > Maybe once I understand the foregoing, I'll also understand "mapped to > a common model (through the structure)". There is a predictable way of being able to combine *any* two RDF/XML documents, whatever vocabularies are used. XML alone doesn't provide this. > >>> It's also one less job (per extension) for every single developer > >>> that > >>> wishes to support extensions. This particular part of their code > >>> would > >>> only have to be written once. > >> > >> Off the top of my head, I can't imagine how this would impact the > >> amount of code required in an application. Could you elaborate? > > > > Ok, say x,y come from one extension (geo) and magnitude another > > (seismo). The client receives something like this: > > > > <entry> > > <geo:x>10.1</geo:x> > > <geo:y>57.3</geo:y> > > <seismo:magnitude>7</seismo:magnitude> > > </entry> > > > > a bit of code could pick these values up with characters[] in SAX or a > > text node in DOM or whatever XOM sees, but the thing is both geo and > > seismo are following the same structure > > > > but if geo and seismo did things a little differently: > > > > <entry> > > <geo:coords x="10.1" y="57.3" /> > > <e:magnitude>7</e:magnitude> > > </entry> > > > > a bit of code could pick the magnitude value up as before, but the > > coords would need different handling - SAX would have to go poking in > > attributes, DOM would need a getAttribute(), XOM would - ok, I've no > > idea, but I expect something different. > > > Let me see if I've got this right: you're saying that by standardizing > on putting data in element content vs. in attributes, the code would > only have to support getting values from element content, and not have > to bother with getting attributes? Having typed that sentence, it > seems I must be missing something, because the following pseudocode > snippets seem only trivially different to me: > > geox = GetElementContent("/geo:x"); > geoy = GetElementContent("/geo:y"); > magnitude = GetElementContent("/seismo:magnitude"); > > geox = GetAttribute("/geo:coords/@x"); > geox = GetAttribute("/geo:coords/@y"); > magnitude = GetElementContent("/seismo:magnitude"); Yes, trivially different, two extra lines of code. Potentially for every developer, for every extension. > I'm assuming the client knows something about the geo and seismo > extensions--otherwise, I can't imagine what the client would be doing > with the extension elements anyway (beyond ignoring it, storing it in > an "unknown extension" table, or passing it through to some other > application). The 'what to do with unknown extensions' question is something that makes a lot more sense if you have commited to the full RDF model. For example, your system might have a piece of data stored: <entry> ... <xxx:wibble>John Smith</xxx:wibble> </entry> You might later pick up the statement: <xxx:wibble> <owl:sameAs rdf:resource="http://purl.org/atom/ns#contributor"; /> </xxx:wibble> So your system would know to list anything marked xxx:wibble along with the other contributors. Cheers, Danny. -- http://dannyayers.com
