« An email and some book recommendations from Booby Woolf | Main | Web ontologies: problems, benefits »

RSS1.0 in drag

So my question is this: why isn't Atom defining a Syndication Element Set as a complement to the Dublin Core Element Set? Why duplicate all that effort when the Dublin Core people have been over the issues again and again for nine years? Ian Davis

To which we can add what Edd Dumbill said.


March 16, 2004 09:56 AM

Comments

Sam Ruby
(March 16, 2004 11:23 AM #)

Care to discuss the rationalle behind the following element in RSS 1.0?

<title xmlns="http://purl.org/rss/1.0/">

Morten Frederiksen
(March 16, 2004 01:09 PM #)

Sam,

Do you really think that it is a reasonable "defense" for a bad decision to point at an obviously similar bad decision?

(Which, BTW, just maybe wasn't that bad a decision at the time, you know, things have changed since then.)

Sam Ruby
(March 16, 2004 01:44 PM #)

Morten: I was honestly unaware that the rss 1.0 title element was considered a bad decision. Is there a consensus on this?

Ian Davis
(March 16, 2004 11:21 PM #)

Sam, it's quite clear that RSS 1.0 was trying to be compatible with earlier versions. Also if you take a look at the RDF schema (http://web.resource.org/rss/1.0/schema.rdf) you'll see that rss:title is a sub property of dc:title. In other words an rss:title ISA dc:title. Atom appears to have neither the excuse of backwards compatibility nor the saving grace of an ISA relationship. So it really is reinvention, not reuse.

Danny
(March 17, 2004 12:41 PM #)

If we have a normative mapping from Atom to RDF/OWL which includes :

atom:title rdfs:subPropertyOf dc:title

etc.

won't we have the best of all worlds?

Bill de hra
(March 17, 2004 02:55 PM #)

I'll admit the title was somewhat tabloid, but it serves to highlight two points.

1. There is reinvention in Atom and I'm not sure the Atom community isn't doing itself harm as a result.

2. I see RDF itself being reinvented, piecemeal, but not just in web syndication. That makes me think RDF needs to be considered by those doing the reinvention, but perhaps it needs to be made more accessible first.

On what Danny said: I think it's better not to map than map. But if this kind of mapping was to be done in Atom better it should happen in a separate spec.

Mark
(March 17, 2004 02:58 PM #)

At least the date elements in Atom are specifically taken from Dublin Core. The 0.2 spec mini-spec made this clear, but the equivalence seems to have been dropped from mnot's 0.3 drafts. It should be put back in. atom:issued *is* dcterms:issued, the only thing we did was move it to our own namespace, under the twisted logic that it would be "simpler" if all the required elements were in the same namespace. I'm not defending it, but there it is.

However, many of the other relations that Ian mentions are simply wrong, and I grow weary of hearing the tired old cliche of "reinventing the wheel". Atom borrows its robust linking syntax from HTML, which no doubt borrowed it from somewhere else that I am unfamiliar with. One could just as reasonably ask why RDF had to go invent their own linking syntax, when there was a perfectly good one in HTML already.

Bill de hra
(March 17, 2004 06:55 PM #)

I'd like to see the equivalences put back in a future draft. But I don't really buy the (twisted) logic that transgressing a namespace is ever simpler than just using what's already there. Maybe at the ened of the day people don't like the look of ns mixed documents outside an envelope/content format. Oh well.

Ian Davis
(March 17, 2004 09:35 PM #)

"Atom borrows its robust linking syntax from HTML" is hardly the best example to pick. Even my cursory peek into the world of Atom has revealed two ongoing problems with this borrowing - using multiple tokens in the rel attribute and the inconsistency of the alien link construct when compared to all the other Atom elements.

Also I wish people would remember that Dublin Core isn't RDF - they're technology neutral terms.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1186