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 >

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

Bravo!

< replied-to message removed by QT >

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

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

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 :-)

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

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 >

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.

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

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

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