16may2002 Conversation In which rss, rdf, weblogs are covered a litt.e ==== snips of conversations: [i'm not sure about the ethics of publishing conversations like this on the web, but i figure IRC is relatively public anyway and I've snipped out the irrelevent stuff] ¥benhammersley has joined #etcon mattw: hello ben benhammersley: hey Matt mattw: which session are you in? benhammersley: DaveWiner mattw: aha. are you keeping notes? mattw: (i want to be in all 3 sessions. i'm trying to collect notes from the other two) benhammersley: trying to - hard to synthesise the point mattw: heh benhammersley: Rael is : http://www.oreillynet.com/~rael/ ¥jillzilla supposes that probably doesn't mean "Dave is gibbering like a rhesus monkey." mattw: wicked, cheers benhammersley: jillzilla: are you in the room jillzilla: No, so I'll have to take your word on the gibber level. mattw: the point i'd make if i were there: instead of everything building tools to operate in weblog-space, there needs to be a tool that simply scrapes and makes the individual posts available in a machine readable format. this is cory's thing about keeping the avenues open. a kind of blog post clearinghouse. one step downstream from indexing posts at a search engine or at daypop. would anyone care to say that for me? wkearney: sure, it's one I've railed about since last winter. benhammersley: I will mattw: ta. the aggregate of blogspace is really really useful. it just needs hooks. bitsko: that's the RSS 1.0 content module, no? wkearney: and this myopia about RDF is just so ridiculous. mattw: rss, good point mattw: it's an extended weblogs.com ping in face mattw: fact, even bitsko: otoh, I think blog messages should just be available at URLs in machine readable format. leavign RSS just as notification ¥mouthbeff has joined #etcon mattw: yes. hang on, i've got a post about that... bitsko: it's almost that way now, except for the scraping wkearney: quite right, what's missing from some popular environments is the machine interfaces. wkearney: pulling stuff outta scraped html loses an enormous amount of context. mattw: lazy evaluation of push: http://interconnected.org/home/2002_04_28_archive.shtml#76114966 mattw: the posts should all be *virtually* available for processing. doesn't mean the resources can't be stored on the individual servers. wkearney: as does consumption of said extracted data. using it outside of a machine interface means the source has no idea or way to help improve the quality of the data provided or made additionally available. ¥qmacro has joined #etcon mattw: that's the semantic web problem, right? wkearney: a simple sort of thing embedded within pages/items would go a long way to helping machine to machine aggregation and intelligence building. wkearney: it's indeed a 'semantic web' problem but it's also (tossing a word grenade...) a metadata problem. bitsko: and then we delve into the REST vs. XML-RPC debate... wkearney: no, not really. it's not a matter of either/or. wkearney: it's a matter of just HAVING a decent infrastructure given consideration at all. mattw: i wonder whether it would help to conceive of weblogs in different ways? like, a chronological trail through www-space, or a filtered History file. wkearney: or better to be prepared to use machine interfaces to that data and pivot across different perpspectives based on what facet is useful at a given instant. bitsko: a "thread" in the "threads of life" sense, occasionally crossing paths with others mattw: both comments: yes, absolutely mattw: there are multiple trails: an individual weblog is just one slice mattw: but there are *all* these ideas wkearney: items matter, when they were created, matters, when they where created matters, how as well. and an efffort I wkearney: I've pushed for a while is where. mattw: and no hooks at any point before the html templates get rendered (or at least, not consistently across diff weblog publishers) wkearney: I'm not as concerned with how to render them into HTML. I'm more interested in how to avoid butchering their underlying metadata that get's LOST when rendering. mattw: okay, so premise: it's going to be *really* hard to work to hook into weblog publishers, scrape some sites, understand various uses & versions of rss. there needs to be one system that does that and makes it available to others. wkearney: ahem, syndic8.com is one step in that direction. mattw: which is perfect, that's precisely the kind of work that needs to be done: mattw: not relying on a not-yet-adapted standard weblog format wkearney: just getting people to use proper XML in agreed formats has been quite a challenging process. wkearney: just getting the so-called standards people truly document what's valid element contents is really a problem. wkearney: and getting the developers of the tools to own up to the fact they don't have "it all figured out" is another. ¥burtonator has left #etcon ¥benhammersley has left #etcon mattw: really good point qmacro: will we (they) ever have it all figured out, in a constantly changing and evolving landscape? wkearney: so my feeling is that until the developers of these tools stop and actually listen to people it's going to continue to be quite a mess. mattw: what was said yesterday about the properties tech has to have to be widely adapted is relevent here mattw: it's partially a tool developers thing mattw: it's partially got to have a benefit for users, so it's a tool like a comments system, or stats, that people *want* to have and can be grafted on afterwards bitsko: not entirely. sometimes people really do not "get" why simple abstract things work so well, like wikis wkearney: while that "sounds good" there's some subtle problems that have prevented things from getting smarter. wkearney: exactly like wikis, exactly like a lot of things. wkearney: the most subtle of which is developer resistance to a larger "good idea". wkearney: it's not that the "good idea" is wrong. wkearney: it's usually because their own tools can't be made to do it that way without serious rearchitecting. wkearney: thus we find some developers railing against semantic web ideas. bitsko: developer resistance in that sense often comes from developer's not "getting" the simple things either. developer's are the worst at overengineering mattw: *oh* yeah wkearney: not because they're bad ideas, but because their tools upchuck when trying to handle said data. bitsko: yes, exactly wkearney: no, it's not overengineering. wkearney: it's recognizing the better idea isn't something their tool can handle. thus the idea is attacked. wkearney: there is overengineering on the part of some specification designers. wkearney: but it's not as ridiculous as the developer resistance to trying to use them. bitsko: right, in that sense. I was thinking more of the developers who maybe almost "get" the right idea, but then can't keep it simple mattw: this is my problem with the various weblog standards mattw: yes there needs to be common ground mattw: but more important than that wkearney: look at a simple use of XML in XML-RPC. The XML protocol completely supports internationalized data. But XML-RPC is hamstring with ASCII data. bitsko: and any attempts to correct that....... wkearney: why? because the tools used have a very poor grip on charsets. mattw: is to create a framework where common ground can arise. we're not even close to that yet, but still get bogged down in arguments about how to store post category names in a resource document. bitsko: not true. *most* tools have no problem with it wkearney: oh really? you're talking to someone how knows RSS syndication really well. wkearney: I can cite facts otherwise. wkearney: the point, however, isnt' to assassinate certain products. wkearney: the point is to get developers to revisit what the specs truly state and to improve the level of compliance with those standards. wkearney: what happens along the way is the spec is revealed to be defective and also needs to be improved. wkearney: the tragedy is the developers tend to view this as some sort of victory, laying claim to some sort of technical higher ground. how utterly stupid. qmacro: (possibly dumb) Q: is there a single place where these basic ideas, these axioms, that should be as salt to a recipe, are stated and described in simple enough terms for developers to 'get'? bitsko: but there seems to be lack of cluefullness in doing so. I've been watching the recent "new XML-RPC" spec discussion, and really wonder what it is the people are trying to accomplish. wkearney: are the developers willing to recognize their least common denominator status is as equally arrogant as the overly academic standards writers? qmacro: as a relative outsider with only a bit of knowledge, and a potential developer, I can see there's talk of simple atomic idea stuff that people should 'get' but I can't put my finger on what it is... Perhaps that is part of the problem? bitsko: (and of course, deathly afraid of suggesting anything positive to help) wkearney: +1 wkearney: and when you see a developer railing about how some other idea is "bad" take a close look at how poorly that developers environment is at handling the so-called problem. wkearney: you find the truth very quickly. bitsko: qmacro: no, often it takes months or years for the essence to filter down. REST is a good example, it "clicked" for me the first time Mark Baker presented it, but the essence has taken almost two years to filter out, and it's clear that it is still not there yet ¥burtonator has joined #etcon wkearney: that said, the specs aren't challenged because they're often written in such an obfuscated fashion that nobody's capable of truly implementing them. wkearney: soap vs rest vs rpc is a non-starter. who cares? qmacro: bitsko: ok, and I guess by the time the 'click' has filtered through, the horse has already bolted wkearney: and the barn's done burnt down. ¥qmacro assumed REST was just an illustrative example of a more general thing bitsko: early RFCs are very easy to read on very complex topics. I don't think it's "spec'ese" so much as inherent complexity wkearney: mainly because the troublemaker that was afraid to admit being unable to ride the horse decided it was better to set the barn on fire instead. bitsko: i.e. SOAP *is* complex for what it's doing. ¥rgibson has joined #etcon wkearney: some of the stuff is truly complicated and can't be described as easily as *some* portion of the RFCs. bitsko: it's not that the spec is so complex wkearney: SOAP is complex for what the examples claim to do. When you scale up a bit it's got things that keep pace. bitsko: RDF, on the other hand, is simple, but has a very complex spec wkearney: yes, exactly right vis a vis RDF. wkearney: but look at how dublin core is equally ambiguous! wkearney: the hassles come when you try to pin some of these folks down on *facts* about the specs. they just don't seem to have it as figured out as is truly needed. bitsko: true wkearney: what strikes me about a lot of this is that people are making up all sorts of excuses instead of making attempts. bitsko: or Stop Energy wkearney: and when the attempts that do get tried don't work the developers themselves refuse to evolve it. mouthbeff: unread ¥bitsko thinks undread is probably more correct wkearney: look closely at who's generating the stop energy. bitsko: I'd prefer not wkearney: is it the critics or the developers afraid to admit weakness? bitsko: everybody defends what they're familiar with wkearney: that's also the excuse used to say "but the customers aren't asking for feature X" when they really mean "our environment is totally unable to implement feature X without tremendous re-engineering"? ¥bitsko is probably missing some of the subtext ¥Morbus has joined #etcon wkearney: defending something without understanding it is often just as bad as not understanding the alternatives. mouthbeff: I wish that the cc project was live so that I could generate an open content license for Boing Boing wkearney: and to posit arguments that dismisss the alternatives while *knowing* your foundations are weak is despicable. ¥Morbus has left #etcon wkearney: to claim "feature X is bad" and supporting it with what seem like valid claims when the truth is that you can wkearney: can't hope to deliver "feature X" is nothing other than deception. wkearney: FUD in the worst sense. ¥bitsko is sure he's missing the subtext now wkearney: yes, and I'm hesitant to go on full-auto here. wkearney: the collateral damage would be problematic. wkearney: anyway, getting the various environments to appreciate and implement alternative interfaces to the core data is how this conversation got started. wkearney: tying up the real data behind poorly implemented HTML rendering is a problem that deserves some attention. ¥Morbus has joined #etcon bitsko: absolutement wkearney: if anything, something utterly trivial like programmatic access to google results is a perfect example.