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.

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).

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)?

> 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 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?

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.

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.

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.

The basic idea is to start showing some practical applications of the protocol in order to have others thinking and possibly implementing.

There are a few interesting things that can be discussed about ENT, besides the protocol.

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.

The other front is on the aggregator side. Once we start collecting posts and organizing them according to topics, there's something more to do than simply sorting posts using topics. This is why we introduced Types as a way to create relations between posts.

In other words, if a post contains these topics:

• places:San Francisco, Gradisca d'Isonzo, London, Somewhere in Sweden
• people:Marc Canter, Ben Hammersley, Paolo Valdemarin, Matt Mower
• companies:Broadband Mechanic, Evectors, Novissio

We could create relations between all these and all the other ones already existing in a directory, thus allowing to navigate trough posts in a completly new way (btw: this is what our aggregator will ultimately do).

But the kind of relations that can be created between topics and types is still to be completly explored and could probably create some very interesting results, especially if applied to existing archives.

On Sunday, April 13, 2003, at 10:03 PM, QT - Marc Canter wrote:

> sounds like a plan - I'm trying to get either Matt or Paolo to
> show up.
> this is during your mail bot session?

Yes, precisely. There's much intertwingley goodness to be had when you start treating email, and mailing lists specifically, as
just-more-data. I'd wager that in total there is a great deal more meaningful signal in the collected listservs and majordomos of the world than the web. The more technical or complex a subject, it seems to me, the more it gravitates towards old school mailing lists, and the further it retreats from the web. Why this is I'm not sure, but
releasing the trapped knowledge in all those old list archives seems a very noble cause. And to do that, we need something like ThreadsML.
Or I might be talking cobblers. Anyone?

sounds like a plan - I'm trying to get either Matt or Paolo to show up.
this is during your mail bot session?

>
< replied-to message removed by QT >

I can do one better than that. I'm speaking there on this very sort of thing. I'm planning on talking about ThreadsML (and now ENT). Perhaps making it into more of a discussion type affair would be good? Also attending are some Latent Semantic Indexing people, and the guys from Waypath, so we might be able to touch on a great deal of good stuff regarding fitting threads into ontologies, and representing such.
Personally I think retrofitting existing content into an ontology is the Really Big Problem we're going to have to face sooner rather than later. Might as well start talking about it.

On Friday, April 11, 2003, at 07:54 PM, QT - Marc Canter wrote:
>
> I also suggested a BOAF at ENTCON (Dr. Weinberger is into it) -
> anybody else interested in attending?
>
> - Marc
> =================
>
> ThreadsML never picked up sufficient steam, but I believe that
> it or something like it is needed more than ever. a BOAF at
> Emerging Tech sounds like a great idea. Count me in.
>
>
> -- David W.

Hi folks,

I was feeling pretty ill yesterday when Marc pointed me to this thread so I'm just catching up. Also I missed ThreadML before so it's a 106 messages I'm reading!

From what I can see though ThreadML seems to be a good idea and, if it's based upon RSS, an idea whose time has come.

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?

Regards,

Matt

p.s. The ENT spec URL should be

http://www.purl.org/NET/ENT/1.0/

which is it's permanent URL. The URL via my blog is where the document lives right now but the above PURL will always point at the latest version of the spec.

wow 2 mentions of Blue Oxen in one day - quite a day for them.

I'd like to point to Matt and Paolo's new ENT spec:

http://matt.blogs.it/specs/ENT/1.0/

as much as I'd like to see RDF succeed, it's still pretty daunting and complicated - despite the W3C's upcoming efforts at education.

ENT is an RSS extension and something any software developer can add in very quickly. It would also be 100% compatible with any paralell RDF or XTM efforts. That's KEY!

I propose that "we" use ENT as a mechanism for flowing threads through. It would take an alteration of the current ThreadsML spec - but something well worth it.

- Marc

>
< replied-to message removed by QT >

Cool.

I'm funneling David's reply - and mine - via this email - onto the QuickTopic site.

This would be ONE example of how a ThreadsML might provide cool new functionality.

I used today - as the day that Matt and Paolo shipped the first draft of ENT (East News Topic)

http://matt.blogs.it/specs/ENT/1.0/

as I believe THAT is how ThreadML will get implemented! 'cause without categorizing and flowing threads into ontologies or facet maps - what's the point?

I also suggested a BOAF at ENTCON (Dr. Weinberger is into it) - anybody else interested in attending?

- Marc
=================

ThreadsML never picked up sufficient steam, but I believe that it or something like it is needed more than ever. a BOAF at Emerging Tech sounds like a great idea. Count me in.


-- David W.

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

>
< replied-to message removed by QT >

re. QT : nifty footwork!

re. ThreadsML

Although I have some reservations about the spec in its current form, it certainly would be great to see some smarter applications appear!
Steve Cayzer has been working in the Semantic Blogging domain recently, and has surveyed what's out there - I'm cc'ing him in the hope he has comments re. ThreadsML.

My main reservation: personally I think the ThreadsML tries to do too much in one place, and runs the risk of the semantics being spread thin (if you see what I mean ;-) In particular I think the cataloguing terms (Topic, hasTopics, categoryOf etc) could be better defined separately from the thread terms (Post, agreesWith, commentsOn etc). The overlap between these two sets and other schema (e.g. the RSS taxo module, the ClaimMaker vocab) could make mixing messy.

Having said that, the way ThreadsML stands in its current form is probably already pretty close to the sweet spot for well-defined/easily-used. If there's a general hubbub of approval to the spec as it stands, I'll happily go with the flow and do what I can to support it in whatever apps I work on.
(just a random thought - I wonder if the Topic side could be linked to the RDF representation of Topic Maps work...that could pull in a whole community...)

btw, there seems to be loads of structured discussion related discussion, see for example :
http://collab.blueoxen.net/cgi-bin/wiki.pl

Evidence that it's an idea who's time has come, perhaps?

Cheers,
Danny.






< replied-to message removed by QT >

Edited by author 04-11-2003 01:17 PM
As far as I know, the effort stands at the proposal you referred to, Marc (http://www.quicktopic.com/7/H/rhSrjkWgjnvRq). Can we get agreement on that? If so, it may be just a matter of specifying that more formally and taking the proposal to a larger group for approval. Can someone say how that's normally done, at least for reference later?

This is good timing for me, becuase once I get QT Pro released (a few weeks from now), I want to implement ThreadsML in QuickTopic. Once the standard is in place, there are lots of possibilities -- one I'm thinking of is providing very flexible viewing of any thread through XSL.

Thanks for resurrecting this, Marc. I'd let it lay idle for awhile while working on other things.

Whoops, the proposal is here: http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66