Ciaio Paolo,

> Looks like we might be able have some parts of the aggregator up
> and running by the conference time. We won't be able to
> participate (unless we win some money within the next few days),
> but I guess this is not going to be a big problem.

This is great - any URLs to look at already?

...

> The first one is the usage of TopicRolls. They are basically a
> way to syndicate lists of types and topics and can be used in
> several different ways. We have thought of a couple of them, but
> most probably other will follow, maybe moving away from OPML
> which is the format which we are currently using.

It would be great to see TopicRolls appearing in a fashion comparable to blogrolls (especially with tools like blogrolling.com to help).
Personally I'd run a mile from OPML -
see http://dannyayers.com/archives/001119.html

[snip re. types]
I'll be interested in seeing what you've come up with for this. Your remark "...we introduced Types as a way to create
relations between posts..." does make me wonder though - ThreadsML offers a way of creating relations between posts using an existing framework for expressing relations, even if you didn't find ThreadsML the language suitable you could still use the relationship framework (RDF). The ENT idea I can see as a neat way of introducing an important bit of semantics into RSS 2.0 (something else I'd run a mile from ;-) but extending this idea further really does sound like there might be wheel-reinvention going on. I hope & trust you'll convince me otherwise ;-)

Cheers,
Danny.

Matt wrote in /m6:
> One thing I haven't come across so far is any
> explanation about why the previous initiative fell
> short. Can anyone summarise? Are there any lessons
> to be learned? Have we?

I'd say it was nothing more than lack of a consistent push on my part, my attention being pulled back to QuickTopic core features. I think the participants were in agreement about the fundamental issues. Divergences happened around details, and there was a little defocusing around tangential issues and applications.

I'm even more confident now that with enough attention and agreement on (and focus on) the problem we're trying to solve, we can create an extremely useful standard here.

I like quite a few things I read in the ENT spec, especially the pragmatic approach revealed in lines like these:
===
The goals of ENT are to:
1. be as simple to implement as possible
2. represent topics sufficiently that they be useful in enabling smart aggregators (e.g. filtering, recombining feeds, etc...)
--
It is our position that the chief reason for the lack of widespread support of the existing standards is their perceived complexity. [To this I'd add the secondary result of lack of software library support. Has this changed recently?]
--
By using a namespace, non-ENT compliant RSS aggregators may safely ignore the ENT elements and attributes and the topic information contained within them.
===

I'm not yet up on RSS 2.0 (and BTW I'm certainly not the most qualified to push in any particular technical direction here.) Thinking about immediate applicability (a big boost for momentum), can anyone comment on current support for RSS 2.0 in software libraries, and in applications like RSS aggregators?

> I like quite a few things I read in the ENT spec, especially the
> pragmatic approach revealed in lines like these:

I agree - this aspect is impressive.

But:
===
> It is our position that the chief reason for the lack of
> widespread support of the existing standards is their perceived
> complexity.
===

I reckon this analysis probably is spot on, but shouldn't the appropriate response be an attempt to change the perception, rather than creating a new standard - doesn't this just add to the (real) complexity? (I could be wrong, see below)

> [To this I'd add the secondary result of lack of
> software library support. Has this changed recently?]

A few people are trying to directly address the issue, but I don't think there have been any major revolutions, though the attention Movable Type's been getting is probably significant.

===
> By using a namespace, non-ENT compliant RSS aggregators may
> safely ignore the ENT elements and attributes and the topic
> information contained within them.
> ===

If you compare an RSS 1.0 feed with and RSS 2.0 feed, the scariest part for a newcomer is probably the use of namespaces in 1.0. Perhaps their use in places like ENT will sweeten this - so that a side effect of RSS 2.0 + ENT might be greater willingness to consider the RDF framework...

> I'm not yet up on RSS 2.0 (and BTW I'm certainly not the most
> qualified to push in any particular technical direction here.)
> Thinking about immediate applicability (a big boost for
> momentum), can anyone comment on current support for RSS 2.0 in
> software libraries, and in applications like RSS aggregators?

I think it can be checked somewhere around syndic8.com, but I think support for basic RSS 2.0 syndication/viewing is fairly universal (it varies little from the previous Userland specs). I don't know what the situation is regarding namespace-identified extensions (like ENT), though I'm fairly confident that 'rare' would be a good estimate.

Cheers,
Danny.

I should add the following to my enquiry about RSS 2.0, just to balance the issue. As the ENT spec mentions, we're always trying to balance simplicity and flexibility. The flexibility of RDF-based 1.0 was what sold me on that approach, but the likelihood of success is, I still think, greatly dictated by the availability of software libraries (in popular languages) for reading and writing it.

So I'll reiterate: what libraries are now available for reading/writing RDF (or specifically RSS 1.0)?

Looks like your post crossed mine on the wire, Danny. Thanks.

I wonder: regarding software libraries, is there a big leap from supporting the namespace extension of RSS 2.0 for ENT to supporting RDF in general? (I think you implied that there isn't).

Hi Danny,

[Note: I started drafting this message before the last flurry of posts by Danny & Steve - I think it's contents are still pretty relevant]
> [snip re. types]
> I'll be interested in seeing what you've come up with for
> this. Your remark "...we introduced Types as a way to create
> relations between posts..." does make me wonder though -
> ThreadsML offers a way of creating relations between posts
> using an existing framework for expressing relations, even if
> you didn't find ThreadsML the language suitable you could
> still use the relationship framework (RDF). The ENT idea I
> can see as a neat way of introducing an important bit of
> semantics into RSS 2.0 (something else I'd run a mile from
> ;-) but extending this idea further really does sound like
> there might be wheel-reinvention going on. I hope & trust
> you'll convince me otherwise ;-)
>

I can see where you are coming from, it's a concern for us too. But I don't think there is too much to be worried about.

My view is that RDF is a great way of doing things as long as it is wrapped with 1st rate tool support and matched with applications that warrant it. So far as I can tell both of those are near to non-existant right now and RDF remains primarily the domain of "those people who are interested in RDF and think it is a good idea," with a few exceptions.
Back when Paolo and I were tossing this idea around we carefully thought over "are we re-inventing RDF" and came to the answer: "no." ENT is, by comparison, pretty simple/limited compared to RDF. But right now I think simplicity is more valuable than power. We are still in the early stages of building the semantic web and, really, the applications we have don't *need* RDF's power right now. We think ENT is "just good enough" to launch a raft of exciting applications.

I fully expect though, that those applications will grow too big for ENT and simple "hard-wired" standards like it. But this demand will, perhaps, lead to an awakening about RDF. It's time will have come because there will be applications that justify it's complexity & the perceived benefits of those applications will be enough to overcome the inertia involved in getting started with it. And, hopefully, by that time the RDF folks will have delivered much more solidly on the tools front ;)

In short my belief is that simple, focused, standards now will pave the way for the adoption of more powerful standards later. Also, as I have stated before[1], I don't think that RDF will really hit a home run until OWL is ready for prime-time.

Regards,

Matt

[1] http://matt.blogs.it/2003/04/08.html#a856

> Looks like your post crossed mine on the wire, Danny. Thanks.

heh, and again.

> I wonder: regarding software libraries, is there a big leap from
> supporting the namespace extension of RSS 2.0 for ENT to
> supporting RDF in general? (I think you implied that there
> isn't).

Aah, scratch any implication to be found along those lines. The point I was trying to make was that what probably scares most potential RSS 1.0 users away is the ugly syntax of RDF/XML, which usually begins with lots of namespace declarations, and features prefixed:elements and even the rare prefixed:attributes all over the place. These are actually artifacts of XML not RDF, it's just that they don't appear in RSS 2.0, until you add extensions.

To support RDF in general, you would really be talking about supporting the model. This could be a big leap. I guess it depends a lot on how people are modelling things already - e.g. if their RDBMS tables are fairly well normalised then it should refactor without too many tears.

Cheers,
Danny.

Edited by author 04-14-2003 12:10 PM
Would it be practical for someone to write a library that's specific to a particular RDF usage (like proposed ThreadsML) that doesn't cover RDF generally?

Also, a major concern is that an implementation doesn't break existing tools that might use it effectively.

As an example that covers both of these items, it seems that lots of RSS aggregators support RSS 1.0. [I'd really like a table of popular aggregators and their support. Here's one: http://blogspace.com/rss/readers
]

It's my understanding that any extension that's based on RSS 1.0 would not break existing apps that support RSS 1.0. True?

Edited by author 04-14-2003 01:17 PM
Libraries supporting RSS 1.0:

Perl: http://perl-rss.sourceforge.net/
PHP example, not library: http://www.sitepoint.com/article/560/1
Java: Jena:
  preview 2 released: http://www.hpl.hp.com/semweb/jena2.htm
  RSS 1.0 parsing: http://www-uk.hpl.hp.com/people/bwm/rdf/jena/rssinjena.htm

I'll update this post as I find more. I couldn't find one for c-sharp. Any other favorites?

Nothing would break, that's true. The namespacing does that trick - same as in 2.0, actually. The question, however, is whether any
existing RSS aggregators actually aggregate 1.0 as RDF, i.e. by parsing it into triples, or building an RDF database, and then querying that database for the display. As far as I know, none do. They just parse 1.0 as if it were 2.0, by simple XML handling, or even RegExps.

The ramifications of this are quite plain: extensions are ignored unless the software is set up to see them, rather than the ideal situation where the data is thrown into an RDF soup, and it's just a matter of using a different query to get at it. It's this soup-ability that gives RDF the edge, imho, if only the documentation was there. Shelley Power's new book should help a lot.


On Monday, April 14, 2003, at 06:00 PM, QT - Steve Yost wrote:

>
< replied-to message removed by QT >

Ben, thanks -- this sheds a lot of light on the issue for me.

The situation sounds very good to me. It sounds like app writers were able to conform to reading RSS 1.0 fairly simply, without writing themselves into a corner -- they can add more semantic processing if they wish later (presumably by rewriting non-user-visible layers, or using libraries when they're available). Meanwhile, content producers can produce whatever richness they're motivated to. The great bottom line is that the spec becomes a non-issue in bridging the two, leaving it to the market to determine that.

It sounds like Shelly Power's book will be good to help understand RDF. Hopefully it will motivate people to write software libraries. Oversimplifying, RDF needs its James Clark.

Good morning everyone - late night on the West Coast - but now I've caught with all the traffic.

Here's my replies to all the subjects:

- by definition - interest in ThreadsML is back - thanks to this
interchange.

- I think we can keep discussion of ENTs relevance to ThreadsML going, but it's obviously a tertiary importance to the core issues of each:

 - Matt and Paolo have just announced ENT - so they're heads down trying to get a new kind of aggregator released - their next tasks will be to evangelize ENT to the other aggregator tool vendors, all the while keeping a mind open to what's possible

 - TopicRolls and the concept of "clouds" are a clear way to bridge between any and all implementation using ENT today and any RDF - semantically inclined functionality and frameworks - moving forward. The key is end-user's investments in building their "digital lifestyles" around these new sort of software tools, and I think TopicRolls and Clouds are exactly appropriate places for transitioning forward - if and when that is required.
- that said - I've fascinated in the pure functionality of what ThreadsML can enable.

 - but as usual, for us to take any conceptual discussion forward, get it implemented and then place that functionality into the hands of end-users - is the key goal
 - so to that ends I proposed that the ThreadsML efforts be "flowed" through ENT
 - this might BOTH get us to our goals (see below) AND keep the channels open moving forward

==============

That said - here's what I think would be most powerful.

 - it's clear tome that RDF-RSS is a religious matter - and especially since this week is Passover, which then naturally leads to Easter, in the spirit of Jesus, and to avoid any Bosnia's, Iran-Iraq, African genocide, terrorist incidents or major rolling of the tanks - I think we should all be especially careful not to let this discussion end-up in some religious dispute. Each to his use. Vive le defrance!

 - it's clear to me that RDF DOES now have momentum - and that the ball is in Danny's, OSAF, the W3C, T B-L and the rest of those (notice I didn't say REST-ful ones :-) folks - to put their money where their mouth are...... (I for one am pretty excited about the possibilities!)

 - and I'd venture to bet that these RDF folks are probably pretty busy doing just that

 - and Matt and Paolo are pretty busy too

 - so then it falls onto the shoulders of the message board folks - symbolically represented by Steve - to try and see if there's some overlap/cross-over possibilities between what ThreadsML is today as defined as a RDF framework - and what can be done with good-old simple, hardwired framework that it is - RSS/ENT.

  - also just as clearly is the goal to keep 100% backwards compatibility so all those aggregators keep on rocking the end-user's worlds, and keep on providing new areas of functionality to humans. This is key. So that's another reason why namespaces - as they're implemented in RSS 2.0 makes sense. Nobody here wants to break anything, and if we're to leverage all those aggregators and aggregators users - this is also a requirement.
 - as I implied above - the REAL goal would be to get ThreadsML to work with BOTH an RDF/RSS1.0 AND a ENT/RSS2.0 implementation scheme. THAT would really rock the house, make all parties happy and...... nullify any potential religious warfare.

Does that make sense?

- Marc

BTW Our (Broadband Mechanics) goal is to create new kinds of front-ends and new kinds of aggregators - that would pull in Threads from iVillage, Slashdot, QuickTopic and all sorts of message boards into one place - in other words message/thread aggregation.

Venturing into this area naively I thought 'all' we needed was an: - open data structure
 - open API that all tools would adopt (post, read, etc.)

But clearly we're all poised to go beyond that. I just wanna make sure the simple goal of aggregating messages happens - so we can do for messages, what RSS/RDF did for news feeds.

That's the overall goal - new functionality for humans - NOW!

GREAT!

This (I think confirms my theory that we (collectively) could move forward implementing something new like ThreadsML - BOTH RDF/RSS1.0 AND ENT/RSS2.0.
Correct?

And that TopicRolls and Clouds (as ingeniously designed by Matt and Paolo) can be a bridge between these two implementation worlds.

Correct?

- Marc

>
< replied-to message removed by QT >

Edited by author 04-14-2003 01:33 PM
Sure sounds like the best possible outcome, Marc. I need to learn more about the diffs and similarities between RDF/RSS1.0 and ENT/RSS2.0. A little homework for me.

Matt - just acknowledging you have a good point, I'm not 100% convinced, but then we can't be 100% certain of anything anyway ;-)


< replied-to message removed by QT >