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.