I’m pleased to announce the release of the first draft of
RDF Forms. This is the first usable
specification to emerge from some ideas that have been floating around in my
head for a couple of years (in
It looks brain-dead simple now, so I think (hope?!) that means that I
probably got it right.
As an example of an RDF Form, here’s a query (aka GET) based one for the
“Top downloads” service of
Mark’s RESTful MS Web services front end;
<rf:indexedBy rdf:resource="http://diveintomark.org/msweb/?WSDL#topType" rf:shortName="topType"/>
<rf:indexedBy rdf:resource="http://diveintomark.org/msweb/?WSDL#topN" rf:shortName="topN"/>
<rf:indexedBy rdf:resource="http://diveintomark.org/msweb/?WSDL#cultureID" rf:shortName="cultureID"/>
Thanks to Jan Algermissen and
Aaron Swartz for their help (though
Aaron didn’t know he was helping on this when he answered a question for me 8-).
for comments on the using a feed URI scheme to identify a subscription action for the
feed, e.g. “feed://http://example.org/rss.xml”.
I think we can do better. Here’s two big reasons why I don’t like this proposal;
- “Clicking” on a URI should always be safe, and provide information
about the identified resource, not take an action upon it. This enables
humans and automata to be able to trust that they’re
not entering into an obligation
by dereferencing a URI (any URI, not just http URIs).
- The resource really is “http://example.org/rss.xml”, and putting
“feed://” on the front obfuscates that from parties who don’t know
what “feed://” means.
So what’s the better proposal? For one, get folks to start using an
RSS-specific media type
so that the client knows it’s RSS. Then you just need to register
your aggregator as the application that handles that media type. Within
the aggregator, I would expect to see that feed after clicking on
the URI, but with a BIG “SUBSCRIBE” button in plain site when it realizes
that I’m not already subscribed to that feed. As a bonus, there’s no need
for a different “subscription URI”.