Re: Setting up a purl for rss/1.1, was: Re: RSS 1.1

On Sun, Jan 23, 2005 at 04:16:19PM +0100, Reto Bachmann-Gmuer wrote:
> 
> Christopher Schmidt wrote:
> 
> >
> >>I guess asking this now would mix up following questions:
> >>- is an update needed?
> >>    
> >>
> >I think that this is a question that can be answered simply by looking 
> >over the history of RSS 1.0. There have been a number of evolutions in 
> >both RDF and syndication since the RSS 1.0 specification was released, 
> >which can be used to the advantage of the format.
> >  
> >
> A good point. However the only use of newer RDF features I can see is in 
> the payload module not in the core. You do use new RDF/XML features:

> -parseType="Collection": good,but doesn't solve the problems with items

I'm not sure what you mean by this: what problems with items? It creates 
an ordered list in RDF, but at the same time doesn't generate (much) 
syntactic cruft for tools which don't understand RDF. (Most aggregators 
that I've found do not use RDF to parse these files.)

> -omit rdf:RDF: makes it impossible to add arbitrary triples to the 
> RSS-Document

Since no source is going to want to aggregate these "arbitrary triples" 
anyway, why would allowing them make any sense? 

> So you gave up backward compatibility in an attempt to be revolutionary. 
> Now you postponed revolution and that's the time to reconsider 
> compatibility. I think the ability to deprecate properties is a nice 
> feature and renders -in this case - a new namespace obsolete. on 
> http://esw.w3.org/topic/RSS I've fixed the RSS bugs my way, but you 
> could go much closer to the model you propose, the only exception is the 
> image property, where I don't think it's possible to deprecate its class 
> usage but not its property usage.

Using the same RSS 1.0 namespace is, quite simply, broken. The namespace 
uses image as both a property and a class, which is prohibited by the 
OWL specifications. Using it is broken. However, the next draft of the 
RSS1.1 spec (which will be released tomorrow) will have informative 
mappings in OWL from RSS 1.0 to RSS 1.1, so tools which understand OWL 
will be able to understand the changes from RSS 1.0 to RSS 1.1.

Looking at the page on the ESW wiki:

The first example does not have any ordering in the items, as far as RDF 
goes. There is no way to know what is the actual order, in RDF. This 
order is the entire reason behind the rdf:parseType="Collection" in the 
first place, and was also the reason behind the rdf:Seq. From an XML 
point of view, the "inChannel" aspect is far more extra syntactic cruft 
than the parseType="Collection" would be. 

Not only that, but as you say, this format doesn't work in old 
aggregators, so you're not keeping backwards compatibility. 

1. Breaking compatibility
2. Loss of ordering of items
3. Extra cruft via "inChannel"

Your second example still contains the only thing I really wanted to get 
rid of with 1.1, the rdf:Seq element. I think that this aspect of RSS 
1.0 is the primary one which would cause content creators to "pass it 
by" for something simpler, so bringing that back is not an option I'm in 
favor of.

I understand the desire to keep backwards compatibility, but both of 
these examples demonstrate problems in the way they're done: one with no 
order in the RDF, the second with the rdf:Seq that has always been a pet 
peeve with the specification.

I'm open to discussion on this, of course, and if the will of the 
community was against 1.1 as is, and towards something different, I'm 
sure that will be shown as time passes, but the problems I've outlined 
are the exact reasons why RSS 1.1 didn't go the way that you've suggested 
in the first place.

Regards,

-- 
Christopher Schmidt



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/