From: Chris N. <pu...@po...> - 2000-11-27 23:05:49
|
We will be discussing the possiblity of incorporating RSS 1.0 into Slash tomorrow at noon Eastern time on #slash, on slashnet (see http://www.slashnet.org/). Background: http://www.egroups.com/files/rss-dev/specification.html -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Chris N. <pu...@po...> - 2000-12-04 14:18:58
|
OK, here is a list of the data for stories that we have available, that we might want to put in to RSS 1.0 files. I listed pretty much all the data for stories, and just a few things for site. Comments welcome. The purpose of this is to put these items into available RSS fields, either in the RSS core in Dublin Core, or in our own Slash XML module. From here, we could then move on to defining fields for comments and users, and any other data we want to search on, for the purpose of returning search data to users and to any other searches we want to enable. site ---- URL name language slogan (description) contact email anything else? stories ------- URL (story ID) title author section topic department number of comments date other (probably not useful, or should not be included): introtext bodytext writestatus hits displaystatus commentstatus hitparade relatedtext extratext -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: <con...@ho...> - 2000-12-04 16:45:11
|
i just got on the list. mind giving me a little history on this request so i can get my mind cranking in the right direction? ciao, k ----- Original Message ----- From: "Chris Nandor" <pu...@po...> To: <sla...@li...> Sent: Monday, December 04, 2000 6:17 AM Subject: [Slashcode-development] RSS 1.0 > OK, here is a list of the data for stories that we have available, > that we might want to put in to RSS 1.0 files. I listed pretty much > all the data for stories, and just a few things for site. Comments > welcome. > > The purpose of this is to put these items into available RSS fields, > either in the RSS core in Dublin Core, or in our own Slash XML module. > > From here, we could then move on to defining fields for comments > and users, and any other data we want to search on, for the purpose > of returning search data to users and to any other searches we want > to enable. > > site > ---- > URL > name > language > slogan (description) > contact email > anything else? > > > stories > ------- > URL (story ID) > title > author > section > topic > department > number of comments > date > > other (probably not useful, or should not be included): > introtext > bodytext > writestatus > hits > displaystatus > commentstatus > hitparade > relatedtext > extratext > > -- > Chris Nandor pu...@po... http://pudge.net/ > Open Source Development Network pu...@os... http://osdn.com/ > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/mailman/listinfo/slashcode-development > |
From: Rael D. <ra...@or...> - 2000-12-10 08:08:53
|
Howdy, While there are other possible uses being bandied about, for the most part beyond my ken (search, replication, etc.), the primary history is this... As you probably know, Slashcode currently affords a Slashsite the ability to provide an XML document containing the titles and descriptions of current stories for syndication, like so: <item> <title>Will Linux Save Microsoft?</title> <link>http://slashdot.org/article.pl?sid=00/12/09/1840253</link> </item> This format is known as RSS 0.9. A newer, more modular version of RSS now exists, RSS 1.0 (http://purl.org/rss/1.0/), allowing for a) more information to be disseminated from the Slashcode database and b) modular extension of the feed to include Slashcode specific data, like so: <item rdf:about="http://slashdot.org/article.pl?sid=00/12/09/1840253"> <title>Will Linux Save Microsoft?</title> <link>http://slashdot.org/article.pl?sid=00/12/09/1840253</link> <description> Chait writes "Check this article out looks interesting! Will Linux Save Microsoft? " Its a fairly logical piece, and certainly not saying anything that any of us haven't thought about. My opinion has always been that as long as the source stays open, I don't care, but it'll definitely be interesting to see what happens. </description> <dc:creator>CmdrTaco</dc:creator> <dc:subject>microsoft</dc:subject> <dc:language>en-us</dc:language> <dc:date>2000-12-09T12:39</dc:date> <dc:format>text/html</dc:format> <slash:department> as-long-as-they-don't-close-the-source-who-cares? </slash:department> <slash:comments>301</slash:comments> </item> Now why would you want to do this? 1. It's incredibly useful to aggregators, websites, et al in order to allow the routing of the appropriate stories to the appropriate places (read: eyeballs). This brings the Slashsite more hits from more folks who would be the most interested. 2. For searches, replication, and countless other data-sharing reasons, bith intra- and inter-site. 3. Why not provide all the information at your disposal -- at least the bits you don't mind sharing? I hope this helps. Rael On Mon, 4 Dec 2000 con...@ho... wrote: > i just got on the list. mind giving me a little history on this request so i > can get my mind cranking in the right direction? > > ciao, > k > > ----- Original Message ----- > From: "Chris Nandor" <pu...@po...> > To: <sla...@li...> > Sent: Monday, December 04, 2000 6:17 AM > Subject: [Slashcode-development] RSS 1.0 > > > > OK, here is a list of the data for stories that we have available, > > that we might want to put in to RSS 1.0 files. I listed pretty much > > all the data for stories, and just a few things for site. Comments > > welcome. > > > > The purpose of this is to put these items into available RSS fields, > > either in the RSS core in Dublin Core, or in our own Slash XML module. > > > > From here, we could then move on to defining fields for comments > > and users, and any other data we want to search on, for the purpose > > of returning search data to users and to any other searches we want > > to enable. ------------------------------------------------------------------ Rael Dornfest ra...@or... Maven, http://www.oreillynet.com/~rael The O'Reilly Network http://meerkat.oreillynet.com ------------------------------------------------------------------ |
From: Rael D. <ra...@or...> - 2000-12-10 04:09:53
|
Howdy, First, I should apologise for my delayed response on this -- bad, bad procmail! On Mon, 4 Dec 2000, Chris Nandor wrote: > OK, here is a list of the data for stories that we have available, > that we might want to put in to RSS 1.0 files. I listed pretty much > all the data for stories, and just a few things for site. Comments > welcome. Chris, could you provide a dump of a typical record so as to see what type of data is in each of these fields? What further constraints are there in terms of what fields are likely to / will always / will _not_ appear together? For example, will there ever be a case when topic and section are both appropriate? Which fields have constrained possible values? > The purpose of this is to put these items into available RSS fields, > either in the RSS core in Dublin Core, or in our own Slash XML module. Aside from title, link, and description (corresponding to title, url, introtext, I believe) nothing else goes into the core as far as items are concerned. As for Dublin Core, there are various possible mappings you can do; for example: topic or section or a combinaton of the two in dc:subject, author in dc:creator, date in dc:date ... see my sample Slashcode RSS 1.0 document example below. > >From here, we could then move on to defining fields for comments > and users, and any other data we want to search on, for the purpose > of returning search data to users and to any other searches we want > to enable. You need to determine what's necessary/useful from the rest of the fields, and it makes sense at least initially to put these into a slashcode module ... again, see my sample below. At some point you might find that a more generalised module exists to house some of this, but that's not the case right now. Fact is that widespread use of an ad-hoc module will heavily influence any such generalised module. --- Ok, so first a little mapping between the fields you've provided and the RSS core (rss), Dublin Core (dc), and Syndication (syn) modules, and a made-up Slashcode (slash) module... > site > ---- > URL rss:channel->rss:link > name rss:channel->rss:title > language rss:channel->dc:language > slogan (description) rss:channel->rss:description > contact email rss:channel->dc:creator > stories > ------- > URL (story ID) rss:item->rss:link > title rss:item->rss:title > author rss:item->dc:creator > section rss:item->dc:subject > topic rss:item->dc:subject (either/or/combined) > department rss:item->slash:department > number of comments rss:item->slash:comments > date rss:item->dc:date > other (probably not useful, or should not be included): > introtext rss:item->rss:description > bodytext (more content than metadata, but up to you) > writestatus what is this? > hits rss:item->slash:hits > displaystatus what is this? > commentstatus what is this? > hitparade what is this? > relatedtext sounds interesting... what is it? > extratext sounds interesting... what is it? I'm afraid I don't know what some of the above are or how useful they would be, but they'd probably be best in a Slashcode module if deemed useful/interesting. If section and story are mutually exclusive, then have the appropriate one be dc:subject. If they co-occur, have the most descriptive one be dc:subject and the one more for internal use by slash:{topic/section}. --- The following sample template uses ${} to indicate the fields I've slotted in as mapped above... <?xml version="1.0" encoding="iso-8859-1"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://slashcode.net/rss/elements/1.0/" xmlns="http://purl.org/rss/1.0/" > <channel rdf:about="${site_url}"> <title>${site_name}</title> <link>${site_url}</link> <description>${site_slogan}</description> <dc:rights>Copyright 2000, ${site_name}</dc:rights> <dc:creator>${site_contact_email}</dc:publisher> <dc:publisher>${site_name}</dc:publisher> <dc:language>${site_language}</dc:language> <items> <rdf:Seq> <rdf:li rdf:resource="${story_url}" /> ... <rdf:li rdf:resource="${story_url}" /> </rdf:Seq> </items> </channel> <item rdf:about="${story_url}"> <title>${story_title}</title> <link>${story_url}</link> <description>${story_intro_text}</description> <dc:creator>${story_author}</dc:creator> <dc:subject>${story_section}: ${story_topic}</dc:subject> <dc:language>${story/site_language}</dc:language> <dc:date>${story-date}</dc:date> <dc:format>text/html</dc:format> <slash:department>${story_department}</slash:department> <slash:comments>${story_number_of_comments}</slash:comments> <slash:hits>${story_hits}</slash:hits> ... </item> ... </rdf:RDF> Again, a template will be much easier to refine with a sample record or three from your database. And, of course, quite a bit of this needs only a little artistic license. Hope this provides a useful start. Rael ------------------------------------------------------------------ Rael Dornfest ra...@or... Maven, http://www.oreillynet.com/~rael The O'Reilly Network http://meerkat.oreillynet.com ------------------------------------------------------------------ |
From: Chris N. <pu...@po...> - 2000-12-11 16:53:38
|
At 20:09 -0800 2000.12.09, Rael Dornfest wrote: >First, I should apologise for my delayed response on this -- bad, bad >procmail! :) >On Mon, 4 Dec 2000, Chris Nandor wrote: > >> OK, here is a list of the data for stories that we have available, >> that we might want to put in to RSS 1.0 files. I listed pretty much >> all the data for stories, and just a few things for site. Comments >> welcome. > >Chris, could you provide a dump of a typical record so as to see what type >of data is in each of these fields? OK, given below with the data. >What further constraints are >there in terms of what fields are likely to / will always / will _not_ >appear together? For example, will there ever be a case when topic and >section are both appropriate? Which fields have constrained possible >values? There is always a topic and a section. >> The purpose of this is to put these items into available RSS fields, >> either in the RSS core in Dublin Core, or in our own Slash XML module. > >Aside from title, link, and description (corresponding to title, url, >introtext, I believe) nothing else goes into the core as far as items are >concerned. As for Dublin Core, there are various possible mappings you >can do; for example: topic or section or a combinaton of the two in >dc:subject, author in dc:creator, date in dc:date ... see my sample >Slashcode RSS 1.0 document example below. OK. >> >From here, we could then move on to defining fields for comments >> and users, and any other data we want to search on, for the purpose >> of returning search data to users and to any other searches we want >> to enable. > >You need to determine what's necessary/useful from the rest of the fields, >and it makes sense at least initially to put these into a slashcode module >... again, see my sample below. At some point you might find that a >more generalised module exists to house some of this, but that's not the >case right now. Fact is that widespread use of an ad-hoc module will >heavily influence any such generalised module. Yeah, we could either try to come up with a "Slash" module, or some more general module. >Ok, so first a little mapping between the fields you've provided and >the RSS core (rss), Dublin Core (dc), and Syndication (syn) modules, >and a made-up Slashcode (slash) module... > >> site >> ---- >> URL rss:channel->rss:link http://slashdot.org/ >> name rss:channel->rss:title Slashdot >> language rss:channel->dc:language en-us >> slogan (description) rss:channel->rss:description News for Nerds. Stuff that matters. >> contact email rss:channel->dc:creator so...@sl... >> stories >> ------- I'll list three stories' worth of data for examples. >> URL (story ID) rss:item->rss:link http://slashdot.org/comments.pl?sid=00/12/11/152211 http://slashdot.org/comments.pl?sid=00/12/09/2329239 http://slashdot.org/comments.pl?sid=00/12/09/1933249 >> title rss:item->rss:title New P2P tool Using... IRC? Gifts For Geeks Could Tesla's Broadcast Power System Work? >> author rss:item->dc:creator Hemos CmdrTaco Cliff >> section rss:item->dc:subject articles features askslashdot >> topic rss:item->dc:subject (either/or/combined) internet xmas news >> department rss:item->slash:department interesting-idea cheesy-alliteration-is-where-it's-at relevant-ideas-from-one-of-science's-greatest >> number of comments rss:item->slash:comments 86 184 28 >> date rss:item->dc:date 2000-12-11 15:11:51 2000-12-11 11:06:02 2000-12-10 23:01:49 >> other (probably not useful, or should not be included): As noted, I probably would not want any of the below included, but added in all the story data we have just for kicks, in case I missed something. >> introtext rss:item->rss:description >> bodytext (more content than metadata, but up to you) Technically, introtext is not necessarily metadata either. introtext is what appears on the main page, which may be the entire text of the story. >> writestatus what is this? This is a flag determining whether a new static page should be written out (the story has been changed since last time a static page has been written). >> hits rss:item->slash:hits How many hits the story has received. >> displaystatus what is this? Whether the story should be displayed on the home page, in a particular section, or not at all. >> commentstatus what is this? Whether comments can be posted. Not used. >> hitparade what is this? A list of how many comments at each "score" level. So for "86,58,37,18,5,4,2", that would mean there are 86 total comments, 58 comments with scores of 0 and up, 37 1 and up, 18 2, 5 3, 4 4, and 2 at 5 and up. This is the info you see when you are in a story and you click the Threshold popup menu. >> relatedtext sounds interesting... what is it? This is for the "Related Links" box next to a story. >> extratext sounds interesting... what is it? This is not really used. >I'm afraid I don't know what some of the above are or how useful they >would be, but they'd probably be best in a Slashcode module if deemed >useful/interesting. I don't think any of them would be too useful or interesting -- or we just would not want to give out that information -- with the _possible_ exception of hitparade. >If section and story are mutually exclusive, then have the appropriate >one be dc:subject. If they co-occur, have the most descriptive one >be dc:subject and the one more for internal use by slash:{topic/section}. Well, topic is the most descriptive. Section is more for stuff like "Ask Slashdot", where you can have separate sections on the site. Topic is what is more like Subject. >The following sample template uses ${} to indicate the fields I've slotted >in as mapped above... > ><?xml version="1.0" encoding="iso-8859-1"?> ><rdf:RDF > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:dc="http://purl.org/dc/elements/1.1/" > xmlns:slash="http://slashcode.net/rss/elements/1.0/" > xmlns="http://purl.org/rss/1.0/" >> > > <channel rdf:about="${site_url}"> > <title>${site_name}</title> > <link>${site_url}</link> > <description>${site_slogan}</description> > <dc:rights>Copyright 2000, ${site_name}</dc:rights> > <dc:creator>${site_contact_email}</dc:publisher> > <dc:publisher>${site_name}</dc:publisher> Actually, this would probably be "OSDN" in the case of Slashdot, since OSDN is the publisher of the site. > <dc:language>${site_language}</dc:language> > > <items> > <rdf:Seq> > <rdf:li rdf:resource="${story_url}" /> > ... > <rdf:li rdf:resource="${story_url}" /> > </rdf:Seq> > </items> So <items> lists the individual items which are then described further below? > </channel> > > <item rdf:about="${story_url}"> > <title>${story_title}</title> > <link>${story_url}</link> > <description>${story_intro_text}</description> Yeah, since in the case of Slashdot we don't want to give this text away, we would probably at most give the first $n words or something. But probably, we won't put this in at all, and just rely on section/topic/department. > <dc:creator>${story_author}</dc:creator> > <dc:subject>${story_section}: ${story_topic}</dc:subject> Perhaps: <dc:subject>${story_topic}</dc:subject> <slash:section>${story_section}</slash:section> > <dc:language>${story/site_language}</dc:language> Right now, we just have site language support. > <dc:date>${story-date}</dc:date> > <dc:format>text/html</dc:format> > <slash:department>${story_department}</slash:department> > <slash:comments>${story_number_of_comments}</slash:comments> > <slash:hits>${story_hits}</slash:hits> Yeah, we won't put hits in, that's private data. > ... > </item> > > ... > ></rdf:RDF> > >Again, a template will be much easier to refine with a sample record or >three from your database. And, of course, quite a bit of this needs >only a little artistic license. > >Hope this provides a useful start. Yes, it does. I think what you've given us helps a lot. We need XML::RSS to support 1.0 of course, but we also need to find a way to tell the RSS what each topic (subject) and section means. How does that work? Do we create some document that describes the possible sections and topics? -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Rael D. <ra...@or...> - 2000-12-15 19:18:42
|
Howdy, A quick note about XML::RSS. I've patched it to be in compliance with RSS 1.0 Release and understand the Dublin Core and Syndication modules. I've submitted the patch to Jonathan Eisenzopf and am expecting him to release it any day now. So Slashcode will be able to emit (and parse) 0.9, 0.91, and 1.0 w/ modules. On Mon, 11 Dec 2000, Chris Nandor wrote: > >You need to determine what's necessary/useful from the rest of the fields, > >and it makes sense at least initially to put these into a slashcode module > >... again, see my sample below. At some point you might find that a > >more generalised module exists to house some of this, but that's not the > >case right now. Fact is that widespread use of an ad-hoc module will > >heavily influence any such generalised module. > > Yeah, we could either try to come up with a "Slash" module, or some more > general module. I think a Slash module would be a great start, afterwhich submitting it to RSS-DEV as direction for a more generalised Weblog/Slash/Portal module. > >Ok, so first a little mapping between the fields you've provided and > >the RSS core (rss), Dublin Core (dc), and Syndication (syn) modules, > >and a made-up Slashcode (slash) module... > > > >> site > >> ---- > >> URL rss:channel->rss:link > http://slashdot.org/ > > >> name rss:channel->rss:title > Slashdot > > >> language rss:channel->dc:language > en-us > > >> slogan (description) rss:channel->rss:description > News for Nerds. Stuff that matters. > > >> contact email rss:channel->dc:creator > so...@sl... Perfect. > >> stories > >> ------- > > I'll list three stories' worth of data for examples. > > > >> URL (story ID) rss:item->rss:link > http://slashdot.org/comments.pl?sid=00/12/11/152211 > http://slashdot.org/comments.pl?sid=00/12/09/2329239 > http://slashdot.org/comments.pl?sid=00/12/09/1933249 > > >> title rss:item->rss:title > New P2P tool Using... IRC? > Gifts For Geeks > Could Tesla's Broadcast Power System Work? > > >> author rss:item->dc:creator > Hemos > CmdrTaco > Cliff > > >> section rss:item->dc:subject > articles > features > askslashdot > > >> topic rss:item->dc:subject (either/or/combined) > internet > xmas > news Topic does indeed seem a better fit for dc:subject. > >> department rss:item->slash:department > interesting-idea > cheesy-alliteration-is-where-it's-at > relevant-ideas-from-one-of-science's-greatest > > >> number of comments rss:item->slash:comments > 86 > 184 > 28 > > >> date rss:item->dc:date > 2000-12-11 15:11:51 > 2000-12-11 11:06:02 > 2000-12-10 23:01:49 > > > > >> other (probably not useful, or should not be included): > > As noted, I probably would not want any of the below included, but added in > all the story data we have just for kicks, in case I missed something. > > >> introtext rss:item->rss:description > >> bodytext (more content than metadata, but up to you) > > Technically, introtext is not necessarily metadata either. introtext is > what appears on the main page, which may be the entire text of the story. Then introtext would definitely be appropriate for description if there is bodytext beyond. > >> writestatus what is this? > > This is a flag determining whether a new static page should be written out > (the story has been changed since last time a static page has been written). > > >> hits rss:item->slash:hits > > How many hits the story has received. > > >> displaystatus what is this? > > Whether the story should be displayed on the home page, in a particular > section, or not at all. > > >> commentstatus what is this? > > Whether comments can be posted. Not used. > > >> hitparade what is this? > > A list of how many comments at each "score" level. So for > "86,58,37,18,5,4,2", that would mean there are 86 total comments, 58 > comments with scores of 0 and up, 37 1 and up, 18 2, 5 3, 4 4, and 2 at 5 > and up. > > This is the info you see when you are in a story and you click the > Threshold popup menu. > > > >> relatedtext sounds interesting... what is it? > > This is for the "Related Links" box next to a story. > > > >> extratext sounds interesting... what is it? > > This is not really used. > > > >I'm afraid I don't know what some of the above are or how useful they > >would be, but they'd probably be best in a Slashcode module if deemed > >useful/interesting. > > I don't think any of them would be too useful or interesting -- or we just > would not want to give out that information -- with the _possible_ > exception of hitparade. I believe the way to go would be to create a Slash module with all of this, yet decide on what (like HitParade) you'd like to make public. The rest could be included only for internal/cross-site use. Up to you, though. > >If section and story are mutually exclusive, then have the appropriate > >one be dc:subject. If they co-occur, have the most descriptive one > >be dc:subject and the one more for internal use by slash:{topic/section}. > > Well, topic is the most descriptive. Section is more for stuff like "Ask > Slashdot", where you can have separate sections on the site. Topic is what > is more like Subject. Then section would be better as slash:section and topic as dc:subject. > >The following sample template uses ${} to indicate the fields I've slotted > >in as mapped above... > > > ><?xml version="1.0" encoding="iso-8859-1"?> > ><rdf:RDF > > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > > xmlns:dc="http://purl.org/dc/elements/1.1/" > > xmlns:slash="http://slashcode.net/rss/elements/1.0/" > > xmlns="http://purl.org/rss/1.0/" > >> > > > > <channel rdf:about="${site_url}"> > > <title>${site_name}</title> > > <link>${site_url}</link> > > <description>${site_slogan}</description> > > <dc:rights>Copyright 2000, ${site_name}</dc:rights> > > <dc:creator>${site_contact_email}</dc:publisher> > > <dc:publisher>${site_name}</dc:publisher> > > Actually, this would probably be "OSDN" in the case of Slashdot, since OSDN > is the publisher of the site. Makes sense. > > <dc:language>${site_language}</dc:language> > > > > <items> > > <rdf:Seq> > > <rdf:li rdf:resource="${story_url}" /> > > ... > > <rdf:li rdf:resource="${story_url}" /> > > </rdf:Seq> > > </items> > > So <items> lists the individual items which are then described further below? Yes. Think of it as a table of contents. It's the the only real RDF bit (matching items to channels via the rdf:about) in RSS 1.0. It's also incredibly useful when parsing the document as regular XML to determine whether or not anything is new without even going beyond <channel>. > > </channel> > > > > <item rdf:about="${story_url}"> > > <title>${story_title}</title> > > <link>${story_url}</link> > > <description>${story_intro_text}</description> > > Yeah, since in the case of Slashdot we don't want to give this text away, > we would probably at most give the first $n words or something. But > probably, we won't put this in at all, and just rely on > section/topic/department. The number one complaint (not that I can do much about it aside from point it out) from readers is the lack of descriptions on certain feeds. The title often is not quite enough to determine whether or not I'd like to follow the link. I'd _strongly_ suggest using introtext when there's a bodytext and the first 80-100 characters (minimum) of introtext when bodytext does not exist. > > <dc:creator>${story_author}</dc:creator> > > <dc:subject>${story_section}: ${story_topic}</dc:subject> > > Perhaps: > <dc:subject>${story_topic}</dc:subject> > <slash:section>${story_section}</slash:section> Yes. > > <dc:language>${story/site_language}</dc:language> > > Right now, we just have site language support. That's just fine if specified in the channel's dc:language element. > > <dc:date>${story-date}</dc:date> > > <dc:format>text/html</dc:format> > > <slash:department>${story_department}</slash:department> > > <slash:comments>${story_number_of_comments}</slash:comments> > > <slash:hits>${story_hits}</slash:hits> > > Yeah, we won't put hits in, that's private data. I'm assuming you mean story_hits, not the others? date will, along with subject, be the number one use of the Dublin Core module. Format isn't all that necessary since most RSS items are assumed to be text/html. Number of comments is nice and will be very useful in a more generalised popularity element in a more generalised module. > > ... > > </item> > > > > ... > > > ></rdf:RDF> > > > >Again, a template will be much easier to refine with a sample record or > >three from your database. And, of course, quite a bit of this needs > >only a little artistic license. > > > >Hope this provides a useful start. > > Yes, it does. I think what you've given us helps a lot. We need XML::RSS > to support 1.0 of course, Again, I'm just waiting on Jonathan's release of my update. What is the (even arbitrary) dealine? > but we also need to find a way to tell the RSS > what each topic (subject) and section means. How does that work? Do we > create some document that describes the possible sections and topics? This has been debated on RSS-DEV for some time -- using resources as subject rather than just string literals. For now, simply use string literals. The future of dc:subject is probably more along the lines of: <dc:subject> <rdf:Description> <taxo:topic rdf:resource="http://slashdot.org/search.pl?topic=internet" /> <rdf:value>internet</rdf:value> </rdf:Description> </dc:subject> This is akin to saying "the subject here is 'internet', as exemplified by the stuff you'll find at http://slashdot.org/search.pl?topic=internet". The same would be true for section in a slash module: <slash:section> <rdf:Description> <slash:topic rdf:resource="http://slashdot.org/index.pl?section=askslashdot" /> <rdf:value>askslashdot</rdf:value> </rdf:Description> </slash:section> "This story is in the "askslashdot" section, as exemplified by the stuff at http://slashdot.org/index.pl?section=askslashdot" This is termed "dumb down" and is the way the Dublin Core group are probably going. If you just need a string literal for your application, usethe rdf:value. If you want to provide a link, use the resouce provided. Again, this is still being worked out so as to be in accordance with DC and RDF in general, so don't worry about it for now. Meerkat, for instance, will map your categories to its own ontology and shuffle the stories about as appropriate. Please do let me know if there's any more info I can provide. Rael ------------------------------------------------------------------ Rael Dornfest ra...@or... Maven, http://www.oreillynet.com/~rael The O'Reilly Network http://meerkat.oreillynet.com ------------------------------------------------------------------ |
From: Chris N. <pu...@po...> - 2000-12-15 19:42:17
|
At 11:18 -0800 2000.12.15, Rael Dornfest wrote: >> >> introtext rss:item->rss:description >> >> bodytext (more content than metadata, but up to you) >> >> Technically, introtext is not necessarily metadata either. introtext is >> what appears on the main page, which may be the entire text of the story. > >Then introtext would definitely be appropriate for description if there is >bodytext beyond. Well, it depends on the site. For some sites, introtext may be the entire story, for others it may be only part of it. What we will probably do is make it an option to include introtext as description. However, yes, if anything is description, this is it. It's just that some sites -- like Slashdot, probably -- won't be including introtext in its RSS. If it does, it will only be the first $n characters. >> I don't think any of them would be too useful or interesting -- or we just >> would not want to give out that information -- with the _possible_ >> exception of hitparade. > >I believe the way to go would be to create a Slash module with all of this, >yet decide on what (like HitParade) you'd like to make public. The rest >could be included only for internal/cross-site use. Up to you, though. Well, first there are the texts, introtext, bodytext, and relatedtext. Setting aside those, writestatus doesn't matter, displaystatus is obvious (if you can see it, it is displaying :), commentstatus doesn't work. So I only see hits and hitparade as being interesting for putting in the module. So introtext would be description, bodytext would be some other main body text field (there's gotta be something like this in SOME module, it is going to be needed by anyone who wants to put a full story in the RSS file), and relatedtext is some other field. >Then section would be better as slash:section and topic as dc:subject. Agreed. >> Yeah, since in the case of Slashdot we don't want to give this text away, >> we would probably at most give the first $n words or something. But >> probably, we won't put this in at all, and just rely on >> section/topic/department. > >The number one complaint (not that I can do much about it aside from point >it out) from readers is the lack of descriptions on certain feeds. The >title often is not quite enough to determine whether or not I'd like to >follow the link. I'd _strongly_ suggest using introtext when there's a >bodytext and the first 80-100 characters (minimum) of introtext when >bodytext does not exist. Yes, this will be under consideration. >> > <dc:date>${story-date}</dc:date> >> > <dc:format>text/html</dc:format> >> > <slash:department>${story_department}</slash:department> >> > <slash:comments>${story_number_of_comments}</slash:comments> >> > <slash:hits>${story_hits}</slash:hits> >> >> Yeah, we won't put hits in, that's private data. > >I'm assuming you mean story_hits, not the others? Yes. >date will, along with >subject, be the number one use of the Dublin Core module. Format isn't >all that necessary since most RSS items are assumed to be text/html. >Number of comments is nice and will be very useful in a more generalised >popularity element in a more generalised module. Yep. >Again, this is still being worked out so as to be in accordance with DC and >RDF in general, so don't worry about it for now. Meerkat, for instance, will >map your categories to its own ontology and shuffle the stories about as >appropriate. > >Please do let me know if there's any more info I can provide. OK, but what I still don't know is how to create this Slash RSS module. What do we do there? Thanks, -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Rael D. <ra...@or...> - 2000-12-15 20:01:18
|
Howdy, On Fri, 15 Dec 2000, Chris Nandor wrote: > At 11:18 -0800 2000.12.15, Rael Dornfest wrote: > >> >> introtext rss:item->rss:description > >> >> bodytext (more content than metadata, but up to you) > >> > >> Technically, introtext is not necessarily metadata either. introtext is > >> what appears on the main page, which may be the entire text of the story. > > > >Then introtext would definitely be appropriate for description if there is > >bodytext beyond. > > Well, it depends on the site. For some sites, introtext may be the entire > story, for others it may be only part of it. What we will probably do is > make it an option to include introtext as description. However, yes, if > anything is description, this is it. It's just that some sites -- like > Slashdot, probably -- won't be including introtext in its RSS. If it does, > it will only be the first $n characters. That's just fine... including a taste is all that's needed. > >> I don't think any of them would be too useful or interesting -- or we just > >> would not want to give out that information -- with the _possible_ > >> exception of hitparade. > > > >I believe the way to go would be to create a Slash module with all of this, > >yet decide on what (like HitParade) you'd like to make public. The rest > >could be included only for internal/cross-site use. Up to you, though. > > Well, first there are the texts, introtext, bodytext, and relatedtext. > Setting aside those, writestatus doesn't matter, displaystatus is obvious > (if you can see it, it is displaying :), commentstatus doesn't work. So I > only see hits and hitparade as being interesting for putting in the module. Cool. > So introtext would be description, bodytext would be some other main body > text field (there's gotta be something like this in SOME module, it is > going to be needed by anyone who wants to put a full story in the RSS > file), and relatedtext is some other field. It's up to you (or the site at hand). I'd have... introtext as description unless no bodytext else first sentence or 100 or so chars of bodytext There is work well underway on a "content" module at: http://www.egroups.com/message/rss-dev/1307 > >> Yeah, since in the case of Slashdot we don't want to give this text away, > >> we would probably at most give the first $n words or something. But > >> probably, we won't put this in at all, and just rely on > >> section/topic/department. > > > >The number one complaint (not that I can do much about it aside from point > >it out) from readers is the lack of descriptions on certain feeds. The > >title often is not quite enough to determine whether or not I'd like to > >follow the link. I'd _strongly_ suggest using introtext when there's a > >bodytext and the first 80-100 characters (minimum) of introtext when > >bodytext does not exist. > > Yes, this will be under consideration. Ta. > >> > <dc:date>${story-date}</dc:date> > >> > <dc:format>text/html</dc:format> > >> > <slash:department>${story_department}</slash:department> > >> > <slash:comments>${story_number_of_comments}</slash:comments> > >> > <slash:hits>${story_hits}</slash:hits> > >> > >> Yeah, we won't put hits in, that's private data. > > > >I'm assuming you mean story_hits, not the others? > > Yes. > > > >date will, along with > >subject, be the number one use of the Dublin Core module. Format isn't > >all that necessary since most RSS items are assumed to be text/html. > >Number of comments is nice and will be very useful in a more generalised > >popularity element in a more generalised module. > > Yep. > > > >Again, this is still being worked out so as to be in accordance with DC and > >RDF in general, so don't worry about it for now. Meerkat, for instance, will > >map your categories to its own ontology and shuffle the stories about as > >appropriate. > > > >Please do let me know if there's any more info I can provide. > > OK, but what I still don't know is how to create this Slash RSS module. > What do we do there? Thanks, 0. Subscribe to RSS-DEV at eGroups (digest and Web-only modes are available) at: http://www.egroups.com/group/rss-dev/ 1. Write up a proposal using the mod_ template at: http://www.egroups.com/files/rss-dev/Modules/Proposed/mod_.html Use one of the others as guidance; a nice simple example (and more than a little apropos) is: http://www.egroups.com/files/rss-dev/Modules/Proposed/mod_annotation.html 2. Save it as mod_slash.html to: http://www.egroups.com/files/rss-dev/Modules/Proposed/ 3. Drop a note to RSS-DEV (rs...@eg...) proposing the module. Be sure to use a subject line like "(Slash) Slashcode Module Proposal" so discussion can be nicely threaded thereafter. That's it. I think we have already built out the basics for one here -- I'm glad to work on it with you. Rael ------------------------------------------------------------------ Rael Dornfest ra...@or... Maven, http://www.oreillynet.com/~rael The O'Reilly Network http://meerkat.oreillynet.com ------------------------------------------------------------------ |