On Friday, May 23, 2003, at 19:01 Europe/Stockholm, QT - Danny Ayers wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> 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.

Not wanting to start the whole argument up again in yet another mailing list, but is there a concrete reason for wanting to work with RSS 2.0? I'm not saying that in a fit of anti-Winer playa hatin', I'm asking because as Danny says, RSS 2.0 is really loose. You get neither the tight semantics, nor the generic RDF compatibility, and the only thing you gain, perhaps, is some simplicity. Simplicity, I have to say, which seems curiously useless, as no one will be handcoding this apart from me. For a bet. When I'm drunk.

It seems to me we're just duplicating effort (and not just with fitting threading into RSS, but also fitting a semantic basis into 2.0) for no real reason.

I don't know - maybe something like 75% of all RSS channels.

That's what we call "installed base" where I come from.

I thought you showed how - using a similar technique to ENT - that we COULD do this with RSS 2.0. Fill in the void. Use the namespaces. I don't know call me crazy, but it just seems like heading out ONLY with a RDF/RSS1.0 implementation is gonna........

Well let's just say - be non-diplomatic, leave behind a number of aggregator vendors and.........be decidedly non-standard-like.

Speaking of knicker twisting........

< replied-to message removed by QT >

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

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> I don't know - maybe something like 75% of all RSS channels.
>
> That's what we call "installed base" where I come from.
>
> I thought you showed how - using a similar technique to ENT -
> that we COULD do this with RSS 2.0. Fill in the void. Use the
> namespaces. I don't know call me crazy, but it just seems like
> heading out ONLY with a RDF/RSS1.0 implementation is
> gonna........
>
> Well let's just say - be non-diplomatic, leave behind a number
> of aggregator vendors and.........be decidedly
> non-standard-like.
>
> Speaking of knicker twisting........


That's fair enough for me. I mean, yes, it can be done with 2.0 - no question about that. It's just that it will be, almost by definition, not very useful for anything but parse-and-display. For
parse-and-display, 2.0 is the mackdaddy. It's simple to understand and throws through XML::Simple like a hot cat through butter. But for smooshing with other vocabularies, putting into rdf databases, doing advanced queries and all that funky stuff, it's not even in the game. But, anyway, Onwards!

In a total sidetrack, I've been listening to Carmen all afternoon, and it has come to my attention that the great heroine of French Opera is a bit of a bitch. I just wanted to share.

Danny wrote:
> 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!).

I'm not sure what you mean by clarity here. My concern is mostly that we're co-opting the Annotation module for something that wasn't its 'true' intention. Is that what you mean? The Threading module, I think, is clear enough in its semantics and usage.

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

With the idea that a threading structure is an overlay on top of a linear timewise structure, we can say that child and parent items aren't necessary unless there are more than one child, or if the child or parent are contained elsewhere. This means that apps need to add the virtual parent-child relationship if it's not explicit, but it seems that any app that's reading ThreadsML is reading and building and internal sequence anyway.

Or do you mean to say that I should be able to pluck an item from the middle of any ThreadsML file or resource and put it in isolation, and find its parent/children from there? If so, then couldn't we say that whomever does the plucking needs to add the parent/children data to the isolated item?
> 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.

I need more RDF education to decipher this w.r.t how properties (vs. class instances) buy extensibility. Care to educate me here or point me somewhere?

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

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> 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?

Perhaps. I'm just looking at this now, oddly enough. Proper answers in the morning, but my initial reaction is that simplicity is the key here. We can track both ways using mod_threading and mod_annotate, but it's not clear. Maybe it would be worth just creating another module that makes sense when you read it:

<thread:child rdf:resource=""/>

<thread:parent rdf:resource=""/>

<thread:child>
<rdf:seq>
  <rdf:li rdf:resource=""/>
</rdf:seq>
</thread:child>


The whole range of agreesWith disagreesWith chidesAt isSarkyAbout stuff is great - but perhaps a second stage of implementation. ie it should supplement, and not replace the <thread:child> <thread:parent> elements.

> Perhaps. I'm just looking at this now, oddly enough. Proper
> answers in the morning, but my initial reaction is that
> simplicity is the key here. We can track both ways using
> mod_threading and mod_annotate, but it's not clear. Maybe it
> would be worth just creating another module that makes sense
> when you read it:
>
> <thread:child rdf:resource=""/>
>
> <thread:parent rdf:resource=""/>
>
> <thread:child>
> <rdf:seq>
> <rdf:li rdf:resource=""/>
> </rdf:seq>
> </thread:child>

Are there any implementors of the current mod_threading spec? If not, why not just modify it? How does this work?

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

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
>> Perhaps. I'm just looking at this now, oddly enough. Proper
>> answers in the morning, but my initial reaction is that
>> simplicity is the key here. We can track both ways using
>> mod_threading and mod_annotate, but it's not clear. Maybe it
>> would be worth just creating another module that makes sense
>> when you read it:
>>
>> <thread:child rdf:resource=""/>
>>
>> <thread:parent rdf:resource=""/>
>>
>> <thread:child>
>> <rdf:seq>
>> <rdf:li rdf:resource=""/>
>> </rdf:seq>
>> </thread:child>
>
> Are there any implementors of the current mod_threading spec? If
> not, why not just modify it? How does this work?

As a member of the secret cabal that is the RSS-Dev working group, I can tell you that no one really knows. Yoohoo! Aaron? Are you awake out there?

(in fairness, sure, we could change it, but making one from scratch with the proper schema behind it and suchlike is probably easier. Danny could probably give birth to some OWL without much discomfort or squawking, and do that and some proper documentation would be bliss. I'll document, whence the time comes.)

Actually, this is a good idea if we want to make it RSS2.0 compatible too.

When you join the Opera cult and take the red pill - you're required to take Italian, German and French - in that order.

Though Germond and 'La Toreador' is a required item in all baritones reptoire - I never made it to the third year of that torture ("tell us Mr. Canter - WHY do you insist on taking these COMPUTER courses (said in the most snobby tone you've ever heard) ....when you should be up to 3rd Mozart counterpoint by now?")

So needless to say - I don't speak French. "Ma Io Italiano no so bene" and "Und meine Deutsch ist nicht do gut"

But Carmen IS beautiful, and I would HOPE she is a bitch! How would you like it if all those dicks were trying to poke you all the time!
Anyway back to the issue at hand.........

......... supporting installed base aggregators is just a polticial move to get us in the game. Once we're there you simply say "if you want these advanced features - guess what?

You gotta move on up baby..........(don't get me started singing the "Good Times" theme song)

< replied-to message removed by QT >

> (in fairness, sure, we could change it, but making one from
> scratch with the proper schema behind it and suchlike is
> probably easier. Danny could probably give birth to some OWL
> without much discomfort or squawking, and do that and some
> proper documentation would be bliss. I'll document, whence the
> time comes.)

Sounds good. Want to take a shot at it? This is just for the threading 'overlay', agreed? Anyone else want to participate in creating (vs reviewing) the new module?

BTW, the OWL would be for anyone using the old module who wants a semantic mapping, right?

>
> Actually, this is a good idea if we want to make it RSS2.0
> compatible too.

Excellent.

Edited by author 05-23-2003 03:06 PM
Go, Marc!

... though compatibility isn't an operatic tale of subterfuge. (Not that you meant that -- just riffing on your theme.) It just makes cool stuff work :-)

> Danny wrote:
> > 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!).
>
> I'm not sure what you mean by clarity here. My concern is mostly
> that we're co-opting the Annotation module for something that
> wasn't its 'true' intention. Is that what you mean? The
> Threading module, I think, is clear enough in its semantics and
> usage.
>
> >
> > 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.
>
> With the idea that a threading structure is an overlay on top of
> a linear timewise structure, we can say that child and parent
> items aren't necessary unless there are more than one child, or
> if the child or parent are contained elsewhere. This means that
> apps need to add the virtual parent-child relationship if it's
> not explicit, but it seems that any app that's reading ThreadsML
> is reading and building and internal sequence anyway.
>
> Or do you mean to say that I should be able to pluck an item
> from the middle of any ThreadsML file or resource and put it in
> isolation, and find its parent/children from there? If so, then
> couldn't we say that whomever does the plucking needs to add the
> parent/children data to the isolated item?

Errm, sorry, don't worry about it - I'm just confusing things unnecessarily ;-)


> > 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.
>
> I need more RDF education to decipher this w.r.t how properties
> (vs. class instances) buy extensibility. Care to educate me here
> or point me somewhere?

Again, I'm just confusing things here. All I meant was that if we start with something like

A tml:childOf B

where A and B are resources (i.e. have URIs) then later it'll be possible to add other relationships on top like

A xyz:agreesWith B

The RDF Primer is probably the main reference - pretty long but pretty much covers everything.

Cheers,
Danny.

> That's fair enough for me. I mean, yes, it can be done with 2.0
> - no question about that. It's just that it will be, almost by
> definition, not very useful for anything but parse-and-display.
> For
> parse-and-display, 2.0 is the mackdaddy. It's simple to
> understand and throws through XML::Simple like a hot cat
> through butter. But for smooshing with other vocabularies,
> putting into rdf databases, doing advanced queries and all that
> funky stuff, it's not even in the game. But, anyway, Onwards!

I think it'll be easy enough to knock together an RSS 2.0 mapping through which it would be possible to do all the wonderful things, as long as the content producers were prepared to follow guidelines. But RSS 2.0 wasn't designed for heavy lifting so because of that, and not because of any intention here, it would be a lot more work for app builders to go that route.
For example, there isn't any consistent way of identifying people within RSS 2.0, but RSS 1.0 can plug in FOAF right away, thanks to the shared model.
> In a total sidetrack, I've been listening to Carmen all
> afternoon, and it has come to my attention that the great
> heroine of French Opera is a bit of a bitch. I just wanted to
> share.

Heh, thank you for sharing that. I must admit I chuckled when I found out that Rigoletto's "La donna é mobile" is all about how fickle women are (yes, I did get a slap).

Cheers,
Danny.

Bravo!

< replied-to message removed by QT >

> > (in fairness, sure, we could change it, but making one from
> > scratch with the proper schema behind it and suchlike is
> > probably easier. Danny could probably give birth to
> some OWL
> > without much discomfort or squawking, and do that and some
> > proper documentation would be bliss. I'll document, whence
> the
> > time comes.)
>
> Sounds good. Want to take a shot at it? This is just for the
> threading 'overlay', agreed? Anyone else want to participate in
> creating (vs reviewing) the new module?

I think we've got all the bits we need - so I guess first we either need to do a strawman prototype or formalize the requirements, heh, can I guess which way this will go...

> BTW, the OWL would be for anyone using the old module who wants
> a semantic mapping, right?

I'm happy to go for the OWL birthing (assuming the beak's the right way up). The way I imagine it working is with the layering :

(1) informally specified : compatibility RSS 2.0 (kind of)
(2) specified as RDF vocabulary/RSS module : (1) + compatibility RSS 1.0 + general RDF
(3) with OWL : (1) + (2) + stricter RDF/reasoning etc

Any app that didn't get 3 could still operate on 2, any app that didn't get 2 could still operate on 1, though 1 would probably just be a "display text" kind of level, and the apps that could do groovy things with (3) are still on the drawing board...

> > Actually, this is a good idea if we want to make it RSS2.0
> > compatible too.
>
> Excellent.

I'll be happy to do an XSLT RSS 2.0 -> RSS 1.0 mapping as well.

Cheers,
Danny.

Now that's to presume (and I don\t wanna come off as anti-FOAF at all - as much as anti-hype) that FOAF exits as well.

I have just undergone an intense three day "what the fuck is FOAF" effort. And dudes let me tell you here - it ain't much.

The FOAFnaut doesn\t work, the FOATamatic gave me a FOAF record - which is now dutifully embedded into the header of my blog's HTML page and "now what?"

Where are the apps that do something with FOAF? Where is the spider crawling the web detecting FOAF-ites?

Am I missing something here?

For all the TALK about FOAF - what's the benefit? Am I crazy or what?
I like the icon-logo though - that's cool! But there ain;t much there besides that..........

< replied-to message removed by QT >

> I think we've got all the bits we need - so I guess first we
> either need to do a strawman prototype or formalize the
> requirements, heh, can I guess which way this will go...

You got it! Show us the prototype!

> > BTW, the OWL would be for anyone using the old module who
> wants
> > a semantic mapping, right?
>
> I'm happy to go for the OWL birthing (assuming the beak's the
> right way up). The way I imagine it working is with the layering
> :
>
> (1) informally specified : compatibility RSS 2.0 (kind of)
> (2) specified as RDF vocabulary/RSS module : (1) + compatibility
> RSS 1.0 + general RDF
> (3) with OWL : (1) + (2) + stricter RDF/reasoning etc

Sounds good!

>
> Any app that didn't get 3 could still operate on 2, any app that
> didn't get 2 could still operate on 1, though 1 would probably
> just be a "display text" kind of level, and the apps that could
> do groovy things with (3) are still on the drawing board...

My guess is that many existing apps would find themselves at (1), but I see your point :-)

>
> I'll be happy to do an XSLT RSS 2.0 -> RSS 1.0 mapping as well.

Great idea. Surprised it hasn't been done. Or do you mean just for the ThreadsML extensions?

Geez, can we call it that now -- an extension to RSS?

Marketing department votes:

Fine.

Call it:

"ThreadsML: an extension to RSS"

< replied-to message removed by QT >

> Call it:
>
> "ThreadsML: an extension to RSS"

Hey, it's Marketing. Shouldn't it be

"ThreadsML: a good extension to RSS"

See, I'm not in Marketing. All I could come with is 'good'.

One wants to stay away from hype - 'cause I happen to know that Danny Ayers is here and if you piss HIM off, then you're in trouble.

:-)

Anyway - associating ourselves with RSS - when we have MR RSS himself - the good Ben one here - is obvious. (or as I call him "Big Ben".) It's OK if I'm bigoted here - as people called me "Big Mac" - for years. (Marc Aaron Canter) - which of course put us in good graces with Apple when it came to being the 10th Mac developer back in '83.

:-)

< replied-to message removed by QT >

Wow, this discussion can really move in a couple days when it gets a little momentum!

So, is the focus now defining the threads markup wholly within the constraints of RSS?

I know, early on in this dicussion, RSS was definitely a context in which threads were imagined. But, I am asking:

Is ThreadsML (at least, phase 1) really just the "threads module of RSS"?

It's a man and he's made of hay.
(I had pollen-induced insomnia last night, gave me time to think about this)
"ThreadsML: a /rather/ good extension to RSS"

Namespace :
xmlns tbd = "http://purl.org/to-be-decided"

Vocabulary :

tbd:Thread (class)

rss:item (class)
rss:items (property)

tbd:parents (property)
tbd:children (property)

dc:creator (property)
dc:contributor (property)
dc:date (property)

content:encoded (property)

foaf:* as required

----
Thread is the big boss - a thread will contain the whole, errm, thread.
Ok, RSS item is reused to represent individual messsages or posts, items to represent the sequence of posts in chrono order - the timeline. This should give existing RSS apps a chance of displaying ThreadsML without
modification. Ideally we would define a term in our own namespace - perhaps a subclass of rss:item, but then the namespace would confuse the
aggregators.
The only problem with this is the mandatory requirements of rss:item : title and/or description and maybe link I think - maybe we use dummies?
tbd:parents/tbd:children - poor names, but we need something that avoids confusion with nextByDate/previousByDate.

In the example below I've got the parents/children in Seqs - I'm not sure this is actually necessary. Do they need to be ordered? Would Bag do? Would something like this be better? :

<item rdf:about="http://example.org/lena1">
...
   <tbd:child rdf:resource="http://example.org/ken2" />
   <tbd:child rdf:resource="http://example.org/henna1" />
   <tbd:child rdf:resource="http://example.org/senna1" />
...
</item>

----

Anyhow, here's minimal example :

<rdf:RDF xmlns="http://purl.org/rss1.0"
         xmlns:tbd = "http://purl.org/to-be-decided">

<tbd:Thread>
   <items>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken1" />
         <rdf:li rdf:resource="http://example.org/lena1" />
         <rdf:li rdf:resource="http://example.org/ken2" />
         <rdf:li rdf:resource="http://example.org/lena2" />
      </rdf:seq>
   </items>
</tbd:Thread>

</rdf:RDF>

The Seq above shows the timeline.

---

Full example :

<rdf:RDF xmlns="http://purl.org/rss1.0"
         xmlns:tbd = "http://purl.org/to-be-decided"
         xmlns:dc = "http://dublincore.org/dc"
         xmlns:foaf = "http://purl.org/firthofforth"
>

<tbd:Thread>

<!-- metastuff about the thread -->

<items>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken1" />
         <rdf:li rdf:resource="http://example.org/lena1" />
         <rdf:li rdf:resource="http://example.org/ken2" />
         <rdf:li rdf:resource="http://example.org/lena2" />
      </rdf:seq>
</items>

<dc:contributor>
   <foaf:Person foaf:name="Ken">
   <foaf:email rdf:resource="ken@twounlimited.com" />
   </foaf:Person>
</dc:contributor>

<dc:contributor>
   <foaf:Person foaf:name="Lena">
   <foaf:email rdf:resource="lena@twounlimited.com" />
   </foaf:Person>
</dc:contributor>

</tbd:Thread>

<item rdf:about="http://example.org/ken1">
   <title>Start of thread</title>
   <content:encoded><![CDATA[<p>Honey, I'm home!</p>]]></content:encoded> <link>http://example.org/ken1</link>;
   <dc:date>2003-05-17T12:45:59+01:00</dc:date>
   <dc:creator>
      <foaf:Person foaf:name="Ken">
         <foaf:email rdf:resource="ken@twounlimited.com" />
      </foaf:Person>
   </dc:creator>
   <tbd:parents />
   <tbd:children>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/lena1" />
      </rdf:Seq>
   </tbd:children>
</item>

<item rdf:about="http://example.org/lena1">
   <title>blah</title>
   <content:encoded><![CDATA[<p>You're late!</p>]]></content:encoded> <link>http://example.org/lena1</link>;
   <dc:date>2003-05-17T12:46:00+01:00</dc:date>
   <dc:creator>
      <foaf:Person foaf:name="Lena">
         <foaf:email rdf:resource="lena@twounlimited.com" />
      </foaf:Person>
   </dc:creator>
   <tbd:parents>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken1" />
      </rdf:Seq>
   </tbd:parents>
   <tbd:children>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken2" />
         <rdf:li rdf:resource="http://example.org/henna1" />
         <rdf:li rdf:resource="http://example.org/senna1" />
      </rdf:Seq>
   </tbd:children>
</item>

</rdf:RDF>

Running this through my head, we need to find/invent/build-on a URI scheme for messaging systems other than those that are web based.
For the uninitiated, a URI is a Unique Resource Identifier. They look like URLs, (in the xxxx://yyy.zzz.aaa type format) but DO NOT have to actually resolve. This is important to remember.

The URI is absolutely key to ThreadsML as it is the only real way of identifying each message. With a web based thread the URI can be as simple as the permalink to the message (as long as the permalink is unique forever more) but with IM or email, it's not so simple. We need to look at how we're going to form URIs for an IM message, for example, otherwise we won't be able to do the great feature of threadsml: thread portability.

Now, for reasons too long and dull to go into, I'm writing this mail offline and will send it later in a burst of sendmail, so I can't check if anything exists already, but we do definitely need a formal scheme for creating a URI for a single IM message, email, or
message-from-as-yet-unknown-device.

Perhaps
http://www.threadsml.org/$originatingserve...$/$timesinceepoch$/ $hash$

so,

http://www.threadsml.org/mail.benhammersley.com/ben/123456789/
lsdufg43b34r86tf

http://www.threadsml.org/toc.oscar.aol.com...mmersley/123456789/ fsdhfaffd

which would definitely be unique and identifying. But there may be something already in existence. Perhaps for email, IRC and Jabber, but probably not AIM or SMS or MSN Messenger. If they don't exist already, we'll have to invent them - not a bad thing.

thoughts anyone?

> I can't check if anything exists already, but we do definitely
> need a formal scheme for creating a URI for a single IM
> message, email, or
> message-from-as-yet-unknown-device.

Good point, although I don't think the scheme's an earth stopping issue - it's only part of the identifier, the only definite requirement is that it's unique. If we need to know the transport/format or whatever (probably a good idea) that should go elsewhere. An hash of the content would probably be a good way of getting the uniqueness - there are plenty of off-the-shelf tools/algorithms.

I doubt whether there's a scheme that adequately covers
message-from-as-yet-unknown-device though maybe one of the existing URNs [1] might do (not got time to check the RDFss right now). If there's nothing too close, I guess we could always register an informal URN namespace. I can't see the use of a proper scheme making much difference to any implementation (except perhaps breaking some regex based toys). Anyhow, in the interim the http:// scheme is probably adequate for ID.

So I'd suggest either

http://blah/123123hashofthecontent123123

or

urn:blah:123123hashofthecontent123123

Cheers,
Danny.


[1] http://www.iana.org/assignments/urn-namespaces

PS. I just remembered Benja Fallenstein's got an informal urn registered (urn-5) which he's using for his Fenfire/Gzz 'Xanadu in RDF' app - it's based on random numbers. Might be a possible.

http://www.iana.org/assignments/urn-informal/urn-5

Just a quick reply to say thanks for the work, Danny, and comments Ben. I'll read in more detail when I get a chance later this weekend.

>
< replied-to message removed by QT >

Thanks for the example Danny! I have some comments / questions:

The thread lists each post in the header, and each post lists any parents or children it may have. By suggesting this, are you imagining this kind of scenario:

1. a post ken1 is made, starting a thread

2. a reponse, lena1, is made indicating ken1 as parent and "tracking back" to ken1 who adds lena1 as a child

3. a response, ken2, is made indicating lena1 as parent and "tracking back" to lena1 who adds ken2 as a child

-etc.

Is this correct: this would allow one to store, with/in each post, a bit of ThreadsML that represents just the post and any parents and children--and from this, an application could assemble (aggregate) a complete ThreadsML thread? For example, the ken1 post could store with/in it this plus some minimal header:

<item rdf:about="http://example.org/ken1"&___GT___;
   <title>Start of thread</title>
   <content:encoded><![CDATA[<p>Honey, I'm home!</p>]]></content:encoded> <link>http://example.org/ken1</link&___GT___;;
   <dc:date>2003-05-17T12:45:59+01:00</dc:date>
   <dc:creator>
      <foaf:Person foaf:name="Ken">
         <foaf:email rdf:resource="ken@twounlimited.com" />
      </foaf:Person>
   </dc:creator>
   <tbd:parents />
   <tbd:children>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/lena1"; />
      </rdf:Seq>
   </tbd:children>
</item>

One of the things I wonder about in this is what exactly the start of a thread is. I mean, in general, does a thread always have a singular start? Can a post in the middle of a thread be the start of a new thread? How would that be expressed?

With the iCite net, I am designing it to allow for any child post to declare any post in the hierarchy of parents the start of the thread. So each post says:

I am part of a thread that starts at: some-uri
(optional) I am responding to (my parent is): another-uri

Leaving out the optional second declaration would suggest a "flat" conversation type thread, where the sequence of posts could only be determined by each post's timestamp.

Any thoughs on this?

On Saturday, May 24, 2003, at 10:04 Europe/Stockholm, QT - Danny Ayers wrote:

> In the example below I've got the parents/children in Seqs - I'm
> not sure this is actually necessary. Do they need to be ordered?
> Would Bag do? Would something like this be better? :

Bag is best, I think. The Seq will undoubtedly be wrong in anything but the simplest case. Besides, because we are mandating use of dc:date, the app can create a timeline sequence quite easily, if the user wants that view. (Personally, I switch between different sequencing all the time, from time to author, to subject and back again.)

On Saturday, May 24, 2003, at 10:04 Europe/Stockholm, QT - Danny Ayers wrote:

<a whole world of snip/>

> <dc:contributor>
> <foaf:Person foaf:name="Lena">
> <foaf:email rdf:resource="lena@twounlimited.com" />
> </foaf:Person>
> </dc:contributor>
>
> </tbd:Thread>

Could we Bag up the dc:contributors? (I'm still unclear on repeating elements in RDF. Danny heeeeeelllllppp)

Also, I'm concerned that wrapping <rss:items> to <tbd:Thread> will break anything that currently uses XML tools to parse RDF. I know they're bad and naughty and ripe for a spanking, but we need to
preserve compatibility with RSS 1.0.

Inside the FOAF stuff, I'd *love* to see <rdfs:seeAlso>.

On Saturday, May 24, 2003, at 02:03 Europe/Stockholm, QT - Jay F wrote:
> I know, early on in this dicussion, RSS was definitely a context
> in which threads were imagined. But, I am asking:
>
> Is ThreadsML (at least, phase 1) really just the "threads module
> of RSS"?

Pretty much, but only in that RSS 1.0 is a major vocabulary of RDF. I'd go further, though, and say it's a profile too. Mandating use of the dc elements is absolutely key.