Let's go with that thought and see what RSS does for us, keeping our goals in mind: a format for saving an entire thread of messages from one of several kinds of discussion apps, with the ability to import it into another discussion app.

There are the runtime goals (what the standard accomplishes for users of the apps that support it), and the adoption goals (the standard is more useful as more apps adopt it).

RSS has a great adoption advantage in already existing and being supported by several interesting (albeit syndication-oriented) apps.

My hesitation is the runtime goal -- i.e. what RSS is intended for. Syndication is about periodically gathering summaries of the latest items from one publishing node and publishing them within another.

But people use RSS for other things (probably following the same reasoning we're using here: it's out there and it works), and that's one thing that caused the push to RSS 1.0, using RDF instead of a DTD, as Edd explains here: http://www.oreillynet.com/pub/a/network/20...zine/rss_intro.html.

Edd's article helps me in another area too: my big concern about crafting a DTD is how to allow for extensibility and how to carefully choose which items are optional. RDF allows that more flexibly it seems, at the cost of introducing a new meta-level of description. Aaron, were you a part of the decision making regarding the move to RDF? What were the considerations?

---

OK, now let's flip and ask from the other side: if we were to create a DTD, is it feasible to produce a DTD that's flexible enough? Can DTDs be extensible? That's where your XML expertise is needed, if you'll allow the thought experiment of a non-RSS solution for a moment.

You know, I always work best with an example. Aaron, can you (or Dan Brickley, who's joining us -- welcome, Dan!) do a stab at an RSS example of, let's say, part of this thread?

You'll of course make some assumptions in mapping, so don't treat it as a formal proposal. I'd mostly like to get a better idea of how you use RDF to be flexible.

If you want to do it, say so first so you don't both spend your time on it (unless you want to of course -- it'd be interesting to see the variations).

First, yes, I was part of the decision to use RDF. The questions were whether there was the software base to support it (a major pro for RDF is the fact that Mozilla supports it natively), the benefits it gave us, etc. At the time I played Devil's Advocate and tried to convince them not to use RDF. (Needless to say, I wasn't too convincing.) Since we adopted RDF, I've begun to like it more and more, and now I am a member of the W3C's RDF Core Working Group.

DTDs are not really extensible. There are many "hacks" to add extensibility onto them, but they were designed in a time where one organization published a schema and you followed it... or else! Since then we have XML Schemas and Namespaces, which allow the freedom and extensibility that most applications. So yes, you'd certainly be able to build the threading standard out of XML Schemas and Namespaces, but XML Schemas are rather complicated, and I haven't been able to really study them so I can't help you too much there.

One of the big benefits of RDF in a threading scenario, is how it provides distributed and decentralized power in a very easy-to-use way. Because it's all based upon URIs, it would be easy for someone else to make their own feed which referred back to a URI in someone else's as its parent. So, in other words, they could respond on their site to a discussion on someone elses. This would allow other people to easily join in on a discussion in a decentralized manner. Obviously, the format could still maintain privacy, etc. through other means.

I'll start in on an RSS model of this discussion -- it shouldn't be too hard.

Edited by author 07-24-2001 11:58 AM
Here's a short example. You'll have to imagine that there are more items (one for each message posted). Let me know if things don't make sense:


<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:c="http://purl.org/rss/1.0/modules/content/"
  xmlns="http://purl.org/rss/1.0/">


<channel rdf:about="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq.rss">
  <title>Threading Standard (JOHO)</title>
  <link>http://www.quicktopic.com/7/H/rhSrjkWgjnvRq</link>;
  <items>
   <rdf:Seq>
   <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p20.20" />
   <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p19.19" />
   <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p18.18" />
   </rdf:Seq>
  </items>
</channel>

<item rdf:about="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p20.20">
  <title>Steve Yost: Threading Standard (JOHO)</title>
  <link>http://www.quicktopic.com/7/H/rhSrjkWgjnvR...0</link>;
  <dc:date>2001-07-24T5:29Z</dc:date>
  <c:items><rdf:Bag><rdf:li><c:item>
  <c:format rdf:resource="http://www.isi.edu/in-notes/iana/assignmen...dia-types/text/html" />
  <rdf:value><![CDATA[
You know, I always work best with an example. Aaron, can you (or Dan Brickley, who's joining us -- welcome, Dan!) do a stab at an RSS example of, let's say, part of this thread?<br />
<br />
You'll of course make some assumptions in mapping, so don't treat it as a formal proposal. I'd mostly like to get a better idea of how you use RDF to be flexible.<br />
<br />
If you want to do it, say so first so you don't both spend your time on it (unless you want to of course -- it'd be interesting to see the variations).<br />]]>
   </content:item></rdf:li></rdf:Bag></content:items>
   <thr:parents>
    <rdf:Bag>
     <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p19.19" />
    </rdf:Bag>
   </thr:parents>
</item>

...

</rdf:RDF>


Hmm, QuickTopic seems to have lost the spacing... but you get the idea.

> One of the big benefits of RDF in a threading scenario, is how
Did you mean RSS?

> Because it's all based upon URIs, it would be
> easy for someone else to make their own feed which referred back
> to a URI in someone else's as its parent.

That's a really interesting capability, but not part of what we're initially after. Of course we should think forward, but balance that with the immediate task at hand: importing and exporting of entire threads between apps. Which reminds me, there was something in one of Edd's papers about a 15-item limit. Is that true and applicable here?

BTW, to me "feeds" implies dynamically changing threads. We need to deal with discussions that may be long-finished. But there *is* also the question of what happens on successive imports (see previous messages): Should matching by the importing app eliminate duplicates? Should the exporting app be able to export certain date/time ranges? The answers needn't be in the standard itself (which is a format standard), but they should be considered in the assumed usages.

> I'll start in on an RSS model of this discussion -- it shouldn't
> be too hard.

Great! I look forward to it.

No, I really meant RDF. It's a benefit RSS gets too, since its based on RDF.

The 15-item limit is no longer true. It was an artifact of Netscape Netcenter, which has been deprecated.

Feed is just the generic term for an RSS file.

Duplicates can generally be easily recognized by their URI, and eliminated. Time ranges sound like an interesting feature, but I wouldn't say they're mandatory.

And I've posted the RSS version below.

Excellent, Aaron -- your example really helps. Looks like we're just about done!

Seriously (not that the above isn't necessarily true), you now have my full attention about its applicability. I'm convinced I should read up thoroughly on RDF and RSS to tow my end of the conversation. I'll be away for two weeks, probably disconnected. Can you recommend a set of pages to read?

I have a rusty familiarity with XML, even designed a DTD (pre-namespaces) about 4 years ago. I have only a cursory understanding of namespaces and RDF.

One small question about your example: when bringing it up in IE, it complained:
Reference to undeclared namespace prefix: 'thr'. Line 31, Position 14
<thr:parents>

Is thr a new namespace you're positing for this usage?

> Can you recommend a set of pages to read?

Well, for RDF and the Semantic Web, I'm all too eager to suggest my own:
http://logicerror.com/semanticWeb

For RSS, the spec is probably your best bet, but some of the
resources at:

http://blogspace.com/rss/resources

might be useful, although many are out of date.

> One small question about your example: when bringing it up in
> IE, it complained:

Oops, there should be a:

xmlns:thr="http://purl.org/rss/1.0/modules/threading/"

up with the namespaces.

Edited by author 07-24-2001 01:37 PM
Now that I've understood your RDF, I'm going backstage to remove the formatting that makes this page so wide (the bane of these web boards -- I could parse every message searching for long words and do the wrapping, but I'm concerned that would impact scalability too much).

(And you'll note that the spacing comes back. Quick Topic preserves the spaces, but your browser doesn't when it sees a pre tag, and QT doesn't mess with anything inside pre tags.)

Given Aaron's RDF example, let me ask an obvious/dumb question. I think we want to have thought through a default set of metadata about the thread itself as an object. E.g., a thread may be owned, may be open or closed, may have start and end dates, etc. RDF enables that list of metadata to be extended, but I assume (in the form of a question) that we want to propose a default list. Yes? No? Huh?

Yeah, for our format it's probably good to propose a required list of metadata. We can say that metadata that meets this standard is a "ThreXML file" or something.

Oops. Before where I said semanticWeb readings, I meant to point to:

http://logicerror.com/semanticWeb-long

As an exercise, I've gone ahead and implemented RSS following the example you gave, Aaron. You can see the rss by just tacking .rss onto the end of any QT URL. For example this topic:

http://www.quicktopic.com/7/H/rhSrjkWgjnvRq.rss

If you're using IE, you should should see the nice collapsible XML representation.

It currently ignores any message ranges you provide and always gives the entire list -- that can be easily fixed. I'm not sure it always does the right thing in the CDATA sections. Feel free to create your own topic and try to break that.

I also ignored the thr: section because I'm not sure your example conveys the meaning of "parent" that we want. Wouldn't it refer to a parent thread, where the current thread was branched from another one?

A starting point at least!

OK, so we're done! Excellent! :)

Now comes the hard part: Naming it.

threXML.com and .org are available
threadsML.com and .org are available

I prefer the threadsML because it's explicit and has a whiff of marketing cleverness about it. (I'm in favor of marketing cleverness.) In fact, I just registered it -- to protect it, not to preempt the discussion. (I suffer from Impulse Registration Syndrome.)

> I also ignored the thr: section because I'm not sure your
> example conveys the meaning of "parent" that we want. Wouldn't
> it refer to a parent thread, where the current thread was
> branched from another one?

Well, you probably know more about QuickTopic threading than I
do, so I'll let you make the decision.

> A starting point at least!

More than a starting point, I think it's a great step forward!

> Now comes the hard part: Naming it.

threadsML sounds fine to me.