- From: Dan Brickley <danbri@w3.org>
- Date: Sat, 7 Sep 2002 15:54:28 -0400 (EDT)
- To: <rss-dev@yahoogroups.com>
- cc: <www-archive+rss@w3.org>
On Sat, 7 Sep 2002, p2psmoke wrote: > Using the RDBMS/SQL example, ordering is not part of the > infrastructure of the tables, its part of the querying process. > RDBMS, just like with RDF, is concerned about the collection of data > for an entity, how to identify the entity, and how to relate > entities, all within fairly rigid guidelines that prevent variations > away from some small group of mathematically proven rules. No more, > no less. Ordering is processing, and isn't part of the model, it > occurs through SQL as in "select a, b, c from tablea order by a". A > direct analogy in RDF would be to not have the container, but to > order based on one of the properties, such as a date. > > What might be a better thing, don't you all think, is to have a non- > optional date field. And then let the aggregators display however > they want based on this date. > > Shelley I've considerable sympathy for this view. Smarter consumer apps will always want to offer multiple ways to render the data; eg. in Mozilla we'd probably use sortable columns for several attributes, and use their XUL UI machinery to allow users to sort things. However I do feel it is useful to have a general 'default' ordering provided in each feed, since it allows consumer apps to be very simple minded and just pass through that ordering without doing any sorting. I do think we should explore the idea of moving beyond this default / hard coded approach, since it will (I suspect) help flesh out some of the opportunities ahead of us. RSS syndication is often about documents, but it is also often about the things that those documents are about. The Weblog use case is more in the former category, but in other uses of RSS it might pay off for us to be more explicit about when we're talking about properties of a document (ie. the item) and when we're talking about properties of the thing the document describes. My old favourite example was for an RSS feed from a jobs website. See prev writeup at http://ilrt.org/discovery/2000/11/rss-query/ The extension vocab (or 'module' in RSS-DEV speak) I sketch there adds an 'advertises' property that connects each rss:item to a Job. Not all RSS extensions are so picky about distinguishing documents from the things they describe, but I think the explicitness is worthwhile. But it has consequences for sorting. In the job example, I write: <item rdf:about="http://example.com/job2.html"> <title>The title of job1 goes here</title> <link>http://example.com/job2.html</link> <description> (Job2-Job2-Job2...) A simple textual description of the job (ie. abstract of the job advert we reference) goes here. </description> <job:advertises> <wn:Job job:title="Job title for job2 goes here" job:salary="150000" job:currency="UKP" > <job:orgHomepage rdf:resource="http://ilrt.org/"/> </wn:Job> </job:advertises> </item> ...and in this case I didn't include a date, either associated with the job or the document that describes the job. I could've added 'closingDate' to the job, or dc:date / publicationDate etc to the job description. Consider related examples: concert listings, upcoming movies, conference announcements. In these cases too, there might be a natural presentation order that is associated more with the thing being described (concert/movie/conference date) than the document that describes it (concert listing, movie or conference announcement). I don't think we know yet what the best practice advise should be, for a site giving a listing of (for example) upcoming conferences, with Item URLs pointing off to conference info on various sites. Should the ordering by chronological, by date of conference; or by date of conference announcement (ie. the pub date of the item docs)? RSS 1.0 is delicately silent on such issues, currently. It allows channel authors to choose whatever seems the natural default ordering, and creates and expectation that consumers of this data will trust that the data source had some good reason for this ordering. Apps that care more should look at the properties (dates etc) of the rss items, and the properties of things (eg. jobs) described using extension vocabularies. So my fear about ommitting rdf:Seq is that we could end up encouraging people to conflate documents with the things they describe; jobs with their adverts; conferences with their announcments. Simply sorting on the dc:date of the rss:item could give counter-intuitive behaviour (I think conference annuoncments might be best example here, since date of conf is probably the natural ordering, rather than date of announcment). If the RSS-DEV WG were to improve RSS 1.0's account of these issues, and offer guidlines for producers and consumers, I could live without the rdf:Seq and without document ordering carrying any meaning. But all the time RSS feeds want to have a meaningful default ordering (which will often _not_ be the same as that you'd get from ordering on date of item), I want to be able to get this from the rdf:Seq too. Otherwise we risk a return to RSS 0.9, where it appeared to be RDF, but critical (or in this case, non-critical but very useful) information was only available if the feed is processed as XML rather than RDF. Dan -- mailto:danbri@w3.org http://www.w3.org/People/DanBri/
Received on Saturday, 7 September 2002 15:54:29 UTC