Re: [RSS-DEV] Re: Very Simple RSS 2.0 Proposal [was: Two "beefs" with RSS 1.0]

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