> Ben, while we have your attention, what do you think of the
> current proposed spec with regards to parent/child
> relationships?
>
> http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66
>
> In light of your concern over the purity of semantics (which I
> think is legitimate in the cause of the semantic web), I
> particularly wonder about the use of the annotation module to
> express child-to-parent relationships. The thing is, we want to
> be able to track both ways. Should we add another module?

IMHO, definitely. I don't think the whole kitchen sink is needed (as in Thread Description Language [1]) but then I think it needs to be made clearer than the Annotation and Threading modules. (can always include owl:equivalentTo if needed!).

It needs to work both ways in such a way that the whole graph could be drawn starting at any given point (in theory at least), and ditto the timeline. Having the messages as class instances and the arcs between them as properties will also make it straightforward/transparent to extend the language e.g. A childOf B ..later.. A agreesWith B.

[1] http://www.eyrie.org/~zednenem/2002/web-threads/

Cheers,
Danny.

ThreadsML should enable us to
> only send the diffs - just as QT is working now.....

Right, interesting point. I think this could relate to the skeleton vs. skeleton + content I muttered about earlier. A skeleton could contain the structure (list/tree/graph of item URIs) without the content. Serving the skeleton first at update time would make it easy to only deliver content diffs.

> - scenarios that can be built with BOTH RSS 1.0 and RSS
> 2.0

I do have a personal preference here, but trying just to be pragmatic, the RSS 2.0 spec doesn't define *anything* about extensions, whereas RSS 1.0's extensions have to be defined in terms of the RDF model. It will be easier to go from tightly-specified to loosely specified, so the RSS 1.0 would be the appropriate starting point. Also, as Ben is pointing out, it slips in with existing generic RDF apps a dream.

> - but before I go - may I make a request?
> - could folks go to the SSA Wiki and leave some
> BLOODEY
> endorsements for your standard of choice?
> - us marketing folks need support in the ant
> colony

Ooo-ooh! (1960's British comedy drama queen voice), don't get your knickers in a twist, I'll have a look when time permits dear...

Cheers,
Danny.

Ben, while we have your attention, what do you think of the current proposed spec with regards to parent/child relationships?

http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66

In light of your concern over the purity of semantics (which I think is legitimate in the cause of the semantic web), I particularly wonder about the use of the annotation module to express child-to-parent relationships. The thing is, we want to be able to track both ways. Should we add another module?

Edited by author 05-23-2003 12:51 PM
Ben wrote:
> Our messages crossed - that's precisely what you do, yes.

I love it!


Marc wrote:
> - it seems to me that the entire content of a
> sub-thread needs to be in the RSS feed

Yes, I think we agree that it will be in the dc:content element, which won't be available to RSS aggregators *now*, but wouldn't it be cool if it were an option that if the dc:content data were there it could be displayed at the users' option. [It would be up to the RSS-reader app writers to do this.]

and Marc wrote:
> - take for example how Joi does his 'RSS comments'
> feed. I get an entire copy of ALL the comments and
> the source post -EVERY TIME another comment is
> left! ThreadsML should enable us to only send the
> diffs - just as QT is working now.....

I interpret this only as saying that ThreadsML captures each comment as a separate item. It's up to the apps that generate ThreadsML to do things like parsing reply-to emails to strip out the chaff as QuickTopic does.

On Friday, May 23, 2003, at 17:45 Europe/Stockholm, QT - Marc Canter wrote:

> - woe be it to us - to break any of the "installed" base
> of RDF
> - DC compliant apps. But don't get me started on this
> 'so-called' installed base of FOAF compliant apps and services.
> I mean "really" (said we a scorning British accent).......

You have to distinguish between FOAF or RSS specific apps, and the whole framework of RDF apps in total. FOAF, RSS1, ThreadsML,
MusicBrainz, whatever, are all just vocabularies - and the toolkits we can use to build apps to service specific vocabularies all depend on the conventions being the same. It's not so much breaking an installed base of apps, as breaking the installed base of toolkits and libraries.
Complying with the rest of ye olde semantic web, however, would be a big win. I mean, really! (sung to the tune of the Toreador Song)

OK - as long as the marketing departments requirements are met:
 - it seems to me that the entire content of a sub-thread needs
to be in the RSS feed

 - take for example how Joi does his 'RSS comments' feed. I get
an entire copy of ALL the comments and the source post -EVERY TIME another comment is left! ThreadsML should enable us to only send the diffs - just as QT is working now.....

 - scenarios that can be built with BOTH RSS 1.0 and RSS 2.0

 - there obviously will be BOTH creators and contributors - so we need to track them both

 - woe be it to us - to break any of the "installed" base of RDF
- DC compliant apps. But don't get me started on this 'so-called' installed base of FOAF compliant apps and services. I mean "really" (said we a scorning British accent).......
 
 - marketing dept sign-off

 - but before I go - may I make a request?
  - could folks go to the SSA Wiki and leave some BLOODEY
endorsements for your standard of choice?
  - us marketing folks need support in the ant colony

:-)
 

< replied-to message removed by QT >

On Friday, May 23, 2003, at 17:29 Europe/Stockholm, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> Danny, thanks for clearing that up.
>
> Also, I had a shower thought on dc:contributor vs dc:creator
> that works for everyone:
>
> For each post taken in itself, the author is the creator (of the
> post) so we use dc:creator for that (and thus retain RSS-reader
> compatibility). For the entire thread, there's the thread's
> creator and all the contributors, so within the <channel>
> elememt we include dc:creator and bag of
> dc:contributors.
>
> Does this sound good?

Our messages crossed - that's precisely what you do, yes.

On Friday, May 23, 2003, at 16:12 Europe/Stockholm, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
>> You want to support both. There's the originator of the
> thread
>> (creators) and those who add on (contributors.)
>>
>> :-)
>
> I don't know how to take the smiley, but I'll assume it's a
> serious suggestion. My point is that RSS aggregators -- a useful
> consumer of ThreadsML -- won't be able to display the poster's
> name if it's
> dc:contributor. And while the authors of the Dublin Core thought
> the distinction between creator and contributor was valuable
> enough to include it, I don't think the fine points of the
> semantics win over compatibility with existing apps in this
> case.
>
> This one of the trickiest parts of spec-making. More opinions?

I have to totally and completely disagree. Sacrificing the complete dublin core semantics for the benefit of the current crop of apps is distinctly short sighted. We'd seriously regret it in six month's time.
Plus, and this is a VERY KEY POINT :) we must not forget that the apps we're talking about are not just the current crop of Readers. The beauty of using RDF is the ability to feed it into other existing RDF applications and databases. Those apps and databases will not respect any adulterated form of the DC semantics, and so we'd be breaking a lot of functionality.

Anyway, creator and contributor are used in entirely different ways: in an RSS 1.0 feed representing a message thread (with each <item> being a new message) contributor would be used inside the <channel> section of the feed, with its values corresponding to the creator values of each <item>. I.e. Marc Canter is a Contributor to this conversation as a whole, but the creator of this small individual section. You use both. Does that make sense?

Danny, thanks for clearing that up.

Also, I had a shower thought on dc:contributor vs dc:creator that works for everyone:

For each post taken in itself, the author is the creator (of the post) so we use dc:creator for that (and thus retain RSS-reader compatibility). For the entire thread, there's the thread's creator and all the contributors, so within the <channel> elememt we include dc:creator and bag of
dc:contributors.

Does this sound good?

< replied-to message removed by QT >

> which works nicely to show the whole message in an aggregator,
> and while that's cool in that it lets you use the aggregator as
> a full reader, I'd be concerned that not everyone would want
> that effect, or at least they'd want the choice.
>
> There aren't any extra capabilities in the content module, but
> its express purpose seems to be to hold the full content as
> opposed to a description or excerpt.
>
> If I'm wrong about these assumptions, though, let me know -- I'm
> no expert on current usage.

RSS 2.0 [1] defines <description> as "The item synopsis.", RSS 1.0 uses Dublin Core [2] which has "An account of the content of the resource."
Some folks do put the full content into description, but I think this is a really bad idea - it's one thing not using metadata, it's another to use metadata and mangle the semantics. Some of the vanilla XML lobby (e.g. Sam Ruby) have been talking about including full content in an <xhtml:body> in RSS 2.0, which complicates matters because its usage isn't actually defined anywhere, but at least that's better than misusing <description>. A few folk are strongly in favour of providing the full-content somewhere, e.g. Phil Ringnalda, a few folk, e.g. Bill Kearney, are worried that the additional network load of providing full-content 'naively' will be costly to content providers.

If you're writing an app that consumes RSS, then you probably have to take the worst-case into account, such as badly formed XML. But using data in way that operates best with the specs and doesn't encourage abuse means that we have at least a chance of getting data that can be used in apps more sophisticated than today's.

Cheers,
Danny.

[1] http://backend.userland.com/rss
[2] http://dublincore.org/documents/dces/

Ugh - yes I'm sorry I see you have a serious issue and I'm futzing around with smiley faces.

This fork in the road was coming.

We need to collect input from Ben, Matt, Paolo, Mark, Danny, David and others......

< replied-to message removed by QT >

> You want to support both. There's the originator of the thread
> (creators) and those who add on (contributors.)
>
> :-)

I don't know how to take the smiley, but I'll assume it's a serious suggestion. My point is that RSS aggregators -- a useful consumer of ThreadsML -- won't be able to display the poster's name if it's
dc:contributor. And while the authors of the Dublin Core thought the distinction between creator and contributor was valuable enough to include it, I don't think the fine points of the semantics win over compatibility with existing apps in this case.

This one of the trickiest parts of spec-making. More opinions?

You want to support both. There's the originator of the thread
(creators) and those who add on (contributors.)

:-)

< replied-to message removed by QT >

Perhaps Ben can shed some light on this. My get tells me Radio handles this differently.

< replied-to message removed by QT >

Mark wrote:
> And I understand (as
> March alluded to) it has become used by bloggers to embed the
> entire content of each post (in the <description> tag).
> ... Perhaps what I am missing is the
> "extra capabilities" that the content module provides -- what
> are examples of such capabilities?
>

I wasn't aware that blogging tools typically use the <description> tag to house the entire message. My default Movable Type 2.51 template for RSS1.0 shows this:

<description><$MTEntryExcerpt encode_html="1"$></description>

while your modified one has

<description><$MTCommentBody encode_xml="1"$></description>

which works nicely to show the whole message in an aggregator, and while that's cool in that it lets you use the aggregator as a full reader, I'd be concerned that not everyone would want that effect, or at least they'd want the choice.

There aren't any extra capabilities in the content module, but its express purpose seems to be to hold the full content as opposed to a description or excerpt.

If I'm wrong about these assumptions, though, let me know -- I'm no expert on current usage.

In looking at the MT template though, I want to reconsider my use of dc:contributor as the name of the author. Just for compatibility with RSS readers (given our recent reasoning on momentum) I think I should change it to dc:creator. Even though in a discussion the participants are really contributors more than creators, I think in this case compatibility might win over pure semantics. What do you think?