QuickTopic free message boards logo
Skip to Messages

TOPIC:

ThreadsML???

Introduction
This is a continuation of a discussion about ThreadsML started over a year ago. Marc Canter resurrected it with an introductory email and has been pushing it along since then.
 
Reference links:
ThreadsML.org
Early definitive statement in the older discussion
An early JOHO article by David Weinberger
(not accepting new messages)
^     All messages            185-284 of 284  85-184 >>
  Messages 284-281 deleted by author between 07-10-2008 08:24 AM and 04-03-2005 08:15 PM
280
Danny Ayers
06-26-2003
04:32 AM ET (US)
> Sorry I haven't posted back on this yet. I'm taking a few days
> off in celebration of the release of QT Pro
> (http://www.quicktopic.com/gopro). I'll be back soon;

Congratulations!

Cheers,
Danny.

PS. I recommend traveller's rehydration powders for hangovers ;-)
279
Steve YostPerson was signed in when posted
06-25-2003
03:22 PM ET (US)
I should also mention that the just-announced QuickThread (http://www.quicktopic.com/cgi-bin/quickthr...l=/em/H/mXbfHC2srY3) serves as a good example of what *could* be accomplished natively by email clients and *any* web board/mailing list if they both supported ThreadsML.

As it is, you forward your batch of emails to new@quicktopic.com and we automatically create a QuickTopic forum from them.
278
Steve YostPerson was signed in when posted
06-25-2003
03:18 PM ET (US)
Sorry I haven't posted back on this yet. I'm taking a few days off in celebration of the release of QT Pro (http://www.quicktopic.com/gopro). I'll be back soon; Sam Ruby's work sounds interesting.

-Steve
277
Marc Canter
06-24-2003
05:39 PM ET (US)
Here here - these are good times for open standards.

My own personal needs revolve around getting a face or image associated with a channel into the spec - so aggregators can give a visual clue to folks - who's channel it is.

Images could also get formerly associated with posts as well - though this is more problematic. Mainly because we can standardize on 32x32 or 48x48 for identifier images - while content images need to be a wide range of sizes and shapes.....

Anyway back to the relationships between PIE and ThreadsML.

How 'bout one of you - go and post something about 'our' schema - and extend a collaborative effort to Sam and his efforts?

- Marc

< replied-to message removed by QT >
276
Danny Ayers
06-24-2003
05:10 PM ET (US)
In case anyone in RSS-land hadn't noticed, Sam Ruby's set up a Wiki to work on a conceptual model of a (web)log. Quite a mixed bag of luminaries have asserted their support. This may lead to a successor to RSS that everyone can agree on (working title is 'Pie' as in 'easy-as'), or it may just be an interesting exercise in analysis and group dynamics. Either way it's significant to the ThreadsML initiative - if something does come out of it, ThreadsML needs to be able to operate with it from day 1. The analysis will be worth watching as it certainly treads into ThreadSpace, we could learn here. I have plenty of personal reservations, but I've been reading Sam's blog long enough to trust his approach (smart guy too), and I think this is almost certainly a (rare) case of it being better to influence things from within.

Sam's trying to address one issue at a time on his blog (just started with the about/link/guid/URI stuff) :

http://www.intertwingly.net/blog/

The Wiki's at :

http://www.intertwingly.net/wiki/pie/

Particularly significant to ThreadsML is the 'Related' stuff - "An Entry exists in an environment of Web Pages, Weblogs, other Entries, Channels, Threads, etc. If we want to fully model Entry, Entry should know how it relates the environment." :

http://www.intertwingly.net/wiki/pie/Related

Cheers,
Danny.
275
Marc CanterPerson was signed in when posted
06-15-2003
02:24 PM ET (US)
Howdy folks. Happy Father's Day.

Check this out:
http://radio.weblogs.com/0122611/outlines/Conversation.html

It's a WebOutliner doc - saved off as a read-only form - which maps out how WebOutliher would edit ThreadsML files. Re-entrant conversations.

There's also instructions in here - for adding your own input into this conversation. Sorry it's not ThreadsML compliant - yet. But you'll get the idea of how exciting this is.
Edited 06-15-2003 02:25 PM
274
Marc Canter
06-14-2003
04:26 PM ET (US)
Yes - there is some overlap - but also with our People's DNS efforts - as well.

Basically you've speced out a cool new tool.

We put that into the category of "go for it - dude!" We support 100%.
- Marc

< replied-to message removed by QT >
273
David H. Deans
06-14-2003
03:09 PM ET (US)
Hello folks, Ben Hammersley sent me over here.

I've posted a brief description of what I refer to as a "GypsyBlogger" application, and associated "Blogger Caravans" here http://www.erablog.net/blogs/dhdeans/

Note, the "trackbacks" link leads to further closely associated comments on other sites. At the AlwaysOn site, be sure to page down to the "member comments" section, and that's where I reference my dialogue with Ben.

If there's a good parallel with your ThreadsML project, then let me know. If not, please excuse this interuption.
272
Steve YostPerson was signed in when posted
06-11-2003
11:24 AM ET (US)
Off topic: I've put this topic into QuickTopic Pro mode (sneak preview for you all). That's visible to participants in two ways: you can upload pictures, and there's a topic introduction at the top of the page. (I could customize the look too, but will defer that for now). I'm doing a beta soon, so you may soon see other QuickTopic forums with the QuickTopic Pro logo at the top.

If you'd like to participate in the beta, let me know at syost@quicktopic.com.

Excuse the thread interruption.
271
Marc Canter
06-10-2003
03:59 PM ET (US)
Yes and thank you VERY MUCH for your work on said specs.

:-)

< replied-to message removed by QT >
270
Danny Ayers
06-10-2003
03:36 PM ET (US)
hehe

The URI http://purl.org/threads has been confirmed as ours, with myself and Steve as maintainers.
At the moment, as a URL it will/should redirect to threadsml.org (doesn't seem to have gone through the system yet). Eventually I suppose it should resolve to the spec(s).



< replied-to message removed by QT >
269
Marc Canter
06-10-2003
01:09 PM ET (US)
And I'd be honored - in the true spirit of chaordic principles - to welcome Steve and Danny as our 'maintainers'.

I just hope they don't evolve into 'containers'.

Or even worse - the dreaded - 'sustainer'.

Maybe now - the humble Mr. Hammersley can take that spec, read it and spit out some more details for our web site.

- Marc

< replied-to message removed by QT >
268
Steve Yost
06-10-2003
08:05 AM ET (US)
Excellent, Danny. I'll be happy to be listed as maintainer. I just registered at purl.org. Username is steve-yost.
> once they've confirmed it would be good to add another person as
> another maintainer - Steve? You'd just have to register at
> purl.org, if you haven't already.
267
Danny Ayers
06-10-2003
05:19 AM ET (US)
Hi folks,

I've updated the sample in the strawman vocabulary [1] on the Wiki following Steve's suggestions (I'd got the FOAF way out), also tweaked it (e.g. inserted the missing RDF namespace ;-) so it's now valid RDF according to the W3C's validator [2].

I've submitted a request at purl.org to use the obvious namespace:
http://purl.org/threads

once they've confirmed it would be good to add another person as another maintainer - Steve? You'd just have to register at purl.org, if you haven't already.

I've still not got any further with the person-grouping stuff (I was meant to be writing an article about RDF grouping last week too), but that's very much on my list for the next couple of days.

Cheers,
Danny.

[1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary [2] http://www.w3.org/RDF/Validator/
266
Steve Yost
06-08-2003
06:27 PM ET (US)
Rick Thomas wrote:
> ...This suggests that a hierarchy is not an adequate model.

True, and fortunately Danny Ayers' recent proposal does allow for multiple parents. See http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary
265
Deleted by author 06-08-2003 04:23 PM
264
Danny Ayers
06-03-2003
12:18 PM ET (US)
Whoops!
You're quite right.

For some, e.g.

  <foaf:Person foaf:name="Lena">

I think this would be valid as an alternative, but like you suggest for the readers benefit it'll be better as

  <foaf:Person>
  <foaf:name>Lena</foaf:name>
...
  </foaf:Person>

This one :

   <foaf:email rdf:resource="lena@twounlimited.com" />

I believe is simply *wrong* - the resource should be a URI, so again the literal format above is better (not wrong!).

That's what comes from not consulting the manual...

Cheers,
Danny.


< replied-to message removed by QT >
263
Steve Yost
06-03-2003
12:01 PM ET (US)
Danny wrote:
> Attributes? I've just looked at my FOAF and it starts like this
> :
> <foaf:Person>
> <foaf:name>Daniel Ayers</foaf:name>
> <foaf:title>Mr</foaf:title>
> <foaf:firstName>Danny</foaf:firstName>
> ...
>
> So the values all seem to be literal text (if anything, I'd have
> though the nesting would have caused problems).
>
Ah. Should we change the wiki to match that then? Or am I mis-reading it?
As I realized, since dc:contributor is in the <items> element, RSS readers are not reading dc:contributor now, so it's really not an issue. But yes, we can hope they'll accomadate the FOAF if it's there. I'd be more confident if FOAF wasn't just "the best choice at the moment". So I'd want to make FOAF optional for dc:contributor, with plain text an alternate. Thoughts?
262
Danny Ayers
06-03-2003
07:58 AM ET (US)
> Actually, thinking about Danny's proposal a little more, I'm
> confusing the dc:contributor element with the dc:creator element
> in the individual post. The dc:contributor item should be
> considered optional -- shouldn't we specify which elements are
> required and which are optional? And it won't break RSS readers.

That sounds very reasonable. Feel free to edit the Wiki.
Personally I'd probably go for making the minimum of the elements mandatory, with the idea that a little data is better than none at all.

Cheers,
Danny.
261
Danny Ayers
06-03-2003
07:58 AM ET (US)
> I'd like to try implementing the strawman proposal Danny
> proposed at
> http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary,

cool!

> but I haven't heard back about the usage of foaf for the
> dc:contributor element.

Looking into it, I'll get back to you, but for now at least use your best guess.

> My concern is that the foaf element will break existing RSS
> readers, which at best will ignore tags that it doesn't
> recognize, and therefore simply not find anything in the
> dc:contributor element, since all of foaf's data seems to be
> represented as XML attributes rather than text elements (or is
> there an alternative?). If that's the case, I must ask for an
> alternative or eliminate the foaf element.

Attributes? I've just looked at my FOAF and it starts like this :
<foaf:Person>
<foaf:name>Daniel Ayers</foaf:name>
<foaf:title>Mr</foaf:title>
<foaf:firstName>Danny</foaf:firstName>
...

So the values all seem to be literal text (if anything, I'd have though the nesting would have caused problems).

I think we should consider it a bonus if current RSS readers can view the data, rather than a requirement. I reckon that if the data is available in a systematic format, then the tool builders will adjust accordingly. We certainly need a way of identifying the people, and FOAF looks the best choice at the moment.

Cheers,
Danny.
260
Steve YostPerson was signed in when posted
06-02-2003
11:18 PM ET (US)
Actually, thinking about Danny's proposal a little more, I'm confusing the dc:contributor element with the dc:creator element in the individual post. The dc:contributor item should be considered optional -- shouldn't we specify which elements are required and which are optional? And it won't break RSS readers.
259
Steve YostPerson was signed in when posted
06-02-2003
11:14 PM ET (US)
Mark Woodward, I read your thoughts at http://stopwar.us/threadsml.html. You could probably do much of what you want if your forum site simply supported RSS, but ThreadsML would obviously be applicable for representing the threaded discussions.
258
Steve Y.Person was signed in when posted
06-02-2003
11:10 PM ET (US)
I'd like to try implementing the strawman proposal Danny proposed at http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary, but I haven't heard back about the usage of foaf for the dc:contributor element.

My concern is that the foaf element will break existing RSS readers, which at best will ignore tags that they doen't recognize, and therefore simply not find anything in the dc:contributor element, since all of foaf's data seems to be represented as XML attributes rather than text elements (or is there an alternative?). If that's the case, I must ask for an alternative or eliminate the foaf element.
Edited 06-02-2003 11:10 PM
257
mwoodwarPerson was signed in when posted
05-31-2003
05:14 PM ET (US)
Thanks for the welcome Steve. I've posted in the wiki (will parade my ignorance and say that this is my virgin wiki post...hope it came out ok).

In case it didn't, you could have a look at my thoughts on including a ThreadtoRSS element at http://stopwar.us/threadsml.html


Mark
256
Jon Lebkowsky
05-31-2003
04:59 PM ET (US)
> Oh, and hello, Jon. So you *are* reading :-) Glad to have your eyes
> and mind on this.

I'm getting the posts via emails but I was out of the loop for a while, several irons in the fire. I've just printed the 77-page ANS paper & want to read it, then go over the stuff in the threadsml wiki and look for the resonance that Marc's seeing.
255
Steve Yost
05-31-2003
04:29 PM ET (US)
Welcome, Mark! With 10 years of experience, you can probably come up with some good use cases, or just validate the ones we have. Feel free to leave commentary or add your own ideas at the wiki in the use case area: http://www.quicktopic.com/cgi-bin/thwiki.pl?UseCases

Oh, and hello, Jon. So you *are* reading :-) Glad to have your eyes and mind on this.


Mark wrote:
> Hello there, I am new to the discussion but very much interested
> in ThreadsML (am drinking the kool aid as we speak)....
254
mwoodwarPerson was signed in when posted
05-31-2003
02:41 PM ET (US)
Hello there, I am new to the discussion but very much interested in ThreadsML (am drinking the kool aid as we speak).

I learned about this at the OSCOM conference from Jon Udell, and think that it is a significant, and much needed piece of work.

Though not a programmer, I have spent the better part of 10 yrs in some way managing online discussion forums, and am willing to help in whatever way I possibly can. In the meantime, I wanted to say hello from the Nashville area...and will continue reading.

Mark

ps The online outliner is really boss
253
Marc Canter
05-29-2003
07:28 PM ET (US)
Just so you know - I'm gonna be talking a lot over the next week or so about something called the ASN (Augmented Soical Networks.) I'll be bringing up ThreadsML as much as I can - taking ALL of your names and efforts in vein.

JUST KIDDING!

No I just wanted you all to know that there are LOTS of folks who want and who can profit and prosper from something like ThreadsML - and we're all "rooting" for yah!

:-)

So the ASN is a dream-like scenario that a few folks are theorizing. And so I'm part of a group that is challenging the premise of just sitting around talking. We're saying: "well what IF you had the resources, brains, money and support?"

So ThreadsML comes in play here. Nobody doesn't want it - let's put it like that.
252
Jon Lebkowsky
05-28-2003
03:34 PM ET (US)
> woe...woe is me...this referred-to-message-removing is *really*
> annoying. I'm losing track of threads. Also, not being able to
> change the subject line...lost, adrift in a sea of mails.

Dude... you need threadsml!

~ jon
251
Marc Canter
05-28-2003
03:12 PM ET (US)
Facts:

1. Yes that's why we need ThreadsML and are here in the first place.
2. The Wiki lives as a breathing, seething beast. Feel free to throw away all of it and start over (at least the page I created - for the purposes of the web site getting fleshed out.)

3. It's gonna take one session of just reading through everything - to get a synonymous trail going. There's nothing we can do about that.
4. Buono fortuna.

< replied-to message removed by QT >
250
Ben Hammersley
05-28-2003
02:25 PM ET (US)
woe...woe is me...this referred-to-message-removing is *really*
annoying. I'm losing track of threads. Also, not being able to change the subject line...lost, adrift in a sea of mails. I want my metadata back.

Also, could changes to the wiki, or a notifier of such, be posted to the list. I'm offline a lot of the time at the moment, and can't keep up with distributed conversations. (Therein find a use case for
ThreadsML)

Anyway, yes, I'll load the old faithful and see what I can tap out for the good Doctor...
249
Marc Canter
05-28-2003
02:04 PM ET (US)
In the sense of:

"who's doing what?"

"why is it such a hodge podge?"

"am I missing something here?"

or

"what am I supposed to do?"

Consider all that crap fodder and source material. I tried going through recent posts - culling what seemed like juicy tid-bits - to me.
But step back, take a deep drag on that infamous pipe of yours and just do your thang. :-) Please.

Give us some words that:
 - explains what the goals of ThreadsML are
 - what we've come up with so far (may want to check with Steve Y on that)
 - what work is in progress
 - what we can expect as far as a roadmap
 - you know - all that "marketing stuff that humans need" kind of communication stuff..........

And then send that to the good, kind Dr. Weinberger.

:-)

Maybe we can even get Paolo to create a good logo for us.

:-)

- Marc

< replied-to message removed by QT >
248
Ben Hammersley
05-28-2003
01:51 PM ET (US)
I have editor access there... wassup with that page?

On Wednesday, May 28, 2003, at 17:40 Europe/Stockholm, QT - Marc Canter wrote:

>
< replied-to message removed by QT >
247
Marc Canter
05-28-2003
11:40 AM ET (US)
Dudes,

Does anybody know anybody at Syndic8?

http://www.syndic8.com/feedinfo.php?FeedID=26156

- Marc
246
Danny Ayers
05-26-2003
04:10 AM ET (US)
No idea - I'll ask on rss-dev...

< replied-to message removed by QT >
245
Steve YostPerson was signed in when posted
05-25-2003
06:29 PM ET (US)
How well (and how) does the use of foaf elements for dc:creator and dc:contributor interoperate with existing RSS readers?
244
Danny Ayers
05-25-2003
08:05 AM ET (US)
I've put the strawman on the Wiki as "ThreadsVocabulary", please hack away :
http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary
243
Ben Hammersley
05-25-2003
06:27 AM ET (US)
On Sunday, May 25, 2003, at 03:28 Europe/Stockholm, QT - Jay F wrote:
> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
>> can you think of a better name for tdb:threadHead ?
>
> I think "head", to many people, suggests "header". However, it
> probably would suggest the right meaning to everyone who has
> worked with CVS.
> threadBegin is the other one I like a lot.

thread:firstPost

Obvious... :-)
242
Jay FPerson was signed in when posted
05-24-2003
09:28 PM ET (US)
> can you think of a better name for tdb:threadHead ?

I think "head", to many people, suggests "header". However, it probably would suggest the right meaning to everyone who has worked with CVS.

I was thinking of: threadStart.

This came to mind because, in online forums / discussion moderation, it is common to see "topic started by . . ." or, as on QuickTopic, "start a new topic".

Here are some other possibilities:

threadBegin
threadBirth
threadEnter
threadInception
threadKickoff
threadOrigin

threadBegin is the other one I like a lot.
241
Marc Canter
05-24-2003
08:45 PM ET (US)
OK - so I guess I'll just keep trying, and use the validator to test with........

- Marc "arrows in the back" Canter

< replied-to message removed by QT >
240
Danny Ayers
05-24-2003
05:20 PM ET (US)
> Right, both are optional--either one or both could be used, so:
>
> (optional) I am part of a thread that starts at: some-uri
> (optional) I am responding to (my parent is): another-uri

The second is covered by tbd:parent(s)

The first - can you think of a better name for tdb:threadHead ?

Cheers,
Danny.
239
Danny Ayers
05-24-2003
05:20 PM ET (US)
> Sablotron XSLT transformation error on line 7: XML parser error
> 4: not well-formed (invalid token).

> Is there supposed to be something else in there I'm missing?
> What gives?

I tried it at the W3C's RDF validator

http://www.w3.org/RDF/Validator/


from the URL, it fails (IOException while reading URI at character 249 using encoding null.)

copy & pasting the source, it works.

My guess is there's a junk EOF character or something crept in. Weird.
> P.S. THEN I'm gonna ask you how to add names to my "trusted
> network".

First you'll need a little black book and some invisible ink...
238
Jay FPerson was signed in when posted
05-24-2003
04:08 PM ET (US)
In reply to Danny's comment in /m235:

>I hadn't thought of identifying the head of the thread, but
> for the branch idea I guess that's what would be
> happening. In fact both parts could be optional - "I am
> the head of a new thread". Yep, I reckon this is worth pursuing.

Right, both are optional--either one or both could be used, so:

(optional) I am part of a thread that starts at: some-uri
(optional) I am responding to (my parent is): another-uri
Edited 05-24-2003 04:09 PM
237
Marc Canter
05-24-2003
03:45 PM ET (US)
Hey Danny - thanks for the FOAF bookmarklet.

Since I know FOAF is not directly related to this list, however this issue is relevant to the acceptance and pickup of ANY standard (such as ThreadsML) I'm gonna use this list reply to ask:

"why do I get this error code?"

Error
Unable to parse FoaF (http://blogs.it/0100198/gems/FOAF.rdf).

Sablotron XSLT transformation error on line 7: XML parser error 4: not well-formed (invalid token).

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

???????????????

If you look at my FOAF.rdf file - it looks fine to my naked eye. That's what FOAFmatic gave me.

http://blogs.it/0100198/gems/FOAF.rdf

Is there supposed to be something else in there I'm missing? What gives?

- Marc

P.S. THEN I'm gonna ask you how to add names to my "trusted network".



< replied-to message removed by QT >
236
Danny Ayers
05-24-2003
03:42 PM ET (US)
> > 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.

Can I add that it will also be an ontology (just don't tell Shelley!).
> Mandating use of the dc elements is absolutely key.

+1.

Cheers,
Danny.
235
Danny Ayers
05-24-2003
03:41 PM ET (US)
> 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.

Yes and no I suppose - I wasn't really thinking that far ahead, just trying to see what you'd need to represent the thread in an RSS friendly fashion. But I'm sure the way you describe it would be a possible scenario.
> 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>

Ouch, that got escaped for Outlook...I think I recognise it though. Yep, although I think the centralised server idea is a good one, I reckon setting things up so that they *can* be pretty loosely distributed would leave the options open.

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

Interesting thought. Like a CVS branch, then - I don't see why not. We'd need an extra term or two to express this, but it could well be useful later.

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

I hadn't thought of identifying the head of the thread, but for the branch idea I guess that's what would be happening. In fact both parts could be optional - "I am the head of a new thread". Yep, I reckon this is worth pursuing.

Cheers,
Danny.
234
Danny Ayers
05-24-2003
03:32 PM ET (US)
> Could we Bag up the dc:contributors? (I'm still unclear on
> repeating elements in RDF. Danny heeeeeelllllppp)

I'll read up a bit - see if there are any discernable best practices. There's the containers (Bag/Seq/Alt), collections (first (rest)) or just repeated individual properties to choose between... I'll stick this on the faq to-do list while I'm at it...

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

Having 'channel' instead? Hmm - suppose so, though it does make it look more like a pig, I might just shoot a mail to rss-dev to try and get a better picture of weak links.

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

Heh, so foaf:* sounds alright then? Again I suppose it would be best to do it in a way that didn't offend too many old-fashioned newsreaders (remember Reginald Bosenquet?).

Cheers,
Danny.
233
Ben Hammersley
05-24-2003
02:30 PM ET (US)
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.
232
Ben Hammersley
05-24-2003
02:29 PM ET (US)
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>.
231
Ben Hammersley
05-24-2003
02:29 PM ET (US)
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.)
230
Jay FPerson was signed in when posted
05-24-2003
02:11 PM ET (US)
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?
229
Steve Yost
05-24-2003
11:32 AM ET (US)
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 >
228
Danny Ayers
05-24-2003
09:19 AM ET (US)
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
227
Danny Ayers
05-24-2003
09:17 AM ET (US)
> 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
226
Ben Hammersley
05-24-2003
08:52 AM ET (US)
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?
225
Danny Ayers
05-24-2003
04:04 AM ET (US)
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>
224
Jay FPerson was signed in when posted
05-23-2003
08:03 PM ET (US)
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"?
223
Marc Canter
05-23-2003
04:27 PM ET (US)
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 >
222
Steve Yost
05-23-2003
04:04 PM ET (US)
> 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'.
221
Marc Canter
05-23-2003
04:00 PM ET (US)
Marketing department votes:

Fine.

Call it:

"ThreadsML: an extension to RSS"

< replied-to message removed by QT >
220
Steve Yost
05-23-2003
03:57 PM ET (US)
> 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?
219
Deleted by topic administrator 06-24-2008 02:19 AM
218
Marc Canter
05-23-2003
03:41 PM ET (US)
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 >
217
Danny Ayers
05-23-2003
03:38 PM ET (US)
> > (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.
216
Danny Ayers
05-23-2003
03:29 PM ET (US)
Bravo!

< replied-to message removed by QT >
215
Danny Ayers
05-23-2003
03:29 PM ET (US)
> 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.
214
Danny Ayers
05-23-2003
03:19 PM ET (US)
> 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.
213
Steve YostPerson was signed in when posted
05-23-2003
03:05 PM ET (US)
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 :-)
Edited 05-23-2003 03:06 PM
212
Steve Yost
05-23-2003
02:59 PM ET (US)
> (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.
211
Marc Canter
05-23-2003
01:59 PM ET (US)
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 >
210
Ben Hammersley
05-23-2003
01:57 PM ET (US)
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.
209
Steve Yost
05-23-2003
01:51 PM ET (US)
> 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?
208
Ben Hammersley
05-23-2003
01:49 PM ET (US)
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.
207
Steve Yost
05-23-2003
01:48 PM ET (US)
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?
206
Ben Hammersley
05-23-2003
01:40 PM ET (US)
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.
205
Marc Canter
05-23-2003
01:28 PM ET (US)
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 >
204
Ben Hammersley
05-23-2003
01:24 PM ET (US)
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.
203
Danny Ayers
05-23-2003
01:16 PM ET (US)
> 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.
202
Danny Ayers
05-23-2003
01:01 PM ET (US)
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.
201
Steve YostPerson was signed in when posted
05-23-2003
12:57 PM ET (US)
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?
200
Steve YostPerson was signed in when posted
05-23-2003
12:50 PM ET (US)
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.
Edited 05-23-2003 12:51 PM
199
Ben Hammersley
05-23-2003
11:55 AM ET (US)
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)
198
Marc Canter
05-23-2003
11:45 AM ET (US)
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 >
197
Ben Hammersley
05-23-2003
11:34 AM ET (US)
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.
196
Ben Hammersley
05-23-2003
11:31 AM ET (US)
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?
195
Steve Yost
05-23-2003
11:29 AM ET (US)
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 >
194
Danny Ayers
05-23-2003
10:27 AM ET (US)
> 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/
193
Marc Canter
05-23-2003
10:17 AM ET (US)
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 >
192
Steve Yost
05-23-2003
10:12 AM ET (US)
> 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?
191
Marc Canter
05-23-2003
09:52 AM ET (US)
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 >
190
Marc Canter
05-23-2003
09:51 AM ET (US)
Perhaps Ben can shed some light on this. My get tells me Radio handles this differently.

< replied-to message removed by QT >
189
Steve Yost
05-23-2003
09:42 AM ET (US)
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.
188
Steve Yost
05-23-2003
09:42 AM ET (US)
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?
187
Marc Canter
05-23-2003
01:17 AM ET (US)
OK dudes

I've collected some juicy bits and two screen shots at:

http://www.quicktopic.com/cgi-bin/thwiki.pl?WebSiteCopy

Feel free to take this raw stuff, copy edit it, and turn it into some spiffy web site language. Now is the time for wordsmiths to do their thing.

Ben & David - this means you.

We need a site that says:
 - what ThreadsML is
 - it's status
 - our evolutionary approach
 - some use cases
 - what the evolutionary phases will be
 - and an FAQ

Seem reasonable?

- Marc
186
Mark Carey
05-22-2003
05:15 PM ET (US)
>ThreadsML's purpose is to allow saving or moving the >entire contents of a thread (and having the capability for >representing the branches that threads have, unlike plain >RSS). Making it a superset of RSS1.0 (and/or RSS2.0) gives >us compatibility with the RSS usages, and using a separate >content module lets readers/importers that support it add >extra capabilities.

That helps, but it doesn't fully answer my question. I understand that the original intent of RSS was to provide excerpts with links to "full stories". And I understand (as Marc alluded to) it has become used by bloggers to embed the entire content of each post (in the <description> tag). My question was/is: what extra benefit is derived from placing the entire message within a <content> tag (like the QT feed) versus placing the entire content within the description tag (as I have done)? With the message in the description tag, I can use existing aggregators to read entire threads, but I can't read data in the content tag. Perhaps what I am missing is the "extra capabilities" that the content module provides -- what are examples of such capabilities?

Thanks,

Mark
Edited 05-22-2003 05:34 PM
185
Marc Canter
05-22-2003
03:17 PM ET (US)
This is a perfect explanation of the ThreadsML logical strategy.
1. Leverage existing standards where possible
2. Get others to work on an a piece of an inter-locking puzzle
3. Focus on real-world examples
4. Enables LOTS of cool new stuff

So the issue of embedding ALL the content into the RSS feed may seem strange, but it's exactly that sort of un-anticipated usage of
technology - that Clay Shirky talks about - that separates the ants from the robots.

The analog inside of us - looks at what's available and we say
(collectively) "what's the shortest distance to get us from here to there?"

RSS (in whatever form) has always seemed to be to be the bext transport vehicle - because it's already being used - as an amazing standards for content syndication.

But why stop there?

Paolo and Matt haven't stopped? Ben hasn't stopped? Steve hasn't either.........

< replied-to message removed by QT >
184
Steve YostPerson was signed in when posted
05-22-2003
02:04 PM ET (US)
Mark, here's my take on this:

RSS1.0 was intended for syndication, where usually the end-user will be reading a list of headlines and brief descriptions and going to the orignal posting site to read the full content.

ThreadsML's purpose is to allow saving or moving the entire contents of a thread (and having the capability for representing the branches that threads have, unlike plain RSS). Making it a superset of RSS1.0 (and/or RSS2.0) gives us compatibility with the RSS usages, and using a separate content module lets readers/importers that support it add extra capabilities.

BTW, given the amount of "resources" available to work on proofs of concept, I'm really glad that we're building on RSS, since there are already interesting uses and lots of apps for that. It'll provide some necessary momentum.
^     All messages            185-284 of 284  85-184 >>