Re: Set Those Semantics Free

[...]
>   3. Put an XHTML with embedded RDDL info at the rss20 URI's "end"
>   4. This would allow any RSS 2.0 reader to continue working...
>   5. ...As well as allow RSS 1.0/RDF readers to transform RSS 2.0 into
> RSS 1.0/RDF by following the rss20/URI, finding the RDDL info there,
> downloading the XSLT, and making the transformation.

Well put. RSS aggregators in particular, however, would probably be more
likely to have the stylesheet built-in as a part of the code, i.e. shipped
along with the distribution. In other words, there are only a handful of
syndication formats that an RSS aggregator (rather than a generic RDF
processor) needs to know about, and so automatic transformation by querying
the namespace wouldn't be necessary.

What the RDDL is for is to document the transformations (and other things
related to the language), and to provide machine readable links should
these be required in the future. It's very simple to parse a RDDL document
using a SAX filter (or something like that), and as I noted in my previous
email, software such as XSV [1] already implements it.

Another benefit of the RDDL documented approach is that updates to the
transformations can be checked for occasionally; and applications that have
the transformation built-in are not precluded for doing this.

> I think I see a couple of possible snags in this scenario:
>
>   A) The URI (actually URL) isn't under my control. What
> if Dave refuses?

I'm sure that Dave is watching, and if not we can always show him what
we've been talking about. If he decides not to take this approach or
something similar, I suspect he'll provide a reason either in public or on
request, so you could discuss it further with him then.

Really, I'm just approaching this from a technical viewpoint: I'm simply
advocating the use of RDDL as a potential benefit to the users of RSS. This
approach is neat because no one really loses anything, but we still have to
discuss it and make our case.

>   B) How would an RDF reader "know" what URIs to download and
> read as RDDL? RSS 2.0 is namespace-extensible, so readers potentially
> have to try several URIs, never knowing which the "correct" one is.

I'm glad you've asked this question. It's actually simple to pick the right
namespace, keeping in mind a few facts about XML (that are currently being
debated [2] on www-tag, but I'll proceed nevertheless).

* The root element of the document decides the language of the document:
IOW, the namespace of the root element is the major language for the
document
* The rule above always applies, except for when you have XML functions [3]

Anyway, the point is that if you want to get the RDDL catalogue for a file,
you should use the namespace of the root element, and that in RSS 2.0 none
of the namespace extensions could change the nature of the root element
(otherwise they'd change the meaning of the document).

[...]
>   (i) Are there any standard/recommended techniques for
> embedding the rddl:resource links in the document (here
> RSS 2.0) itself rather than in a separate document?

Not that I know of. The linking technique is comparable to the use of
stylesheets: it's useful to have them out-of-band because repeating
information on that scale is unnecessary, and parsers only need the
information occasionally.

Think of the similar situation with XML schema: you don't embed a schema
documents in instances: instead, you used the xsi:schemaLocation attribute
(in fact, RDDL makes that unnecessary too).

> (Note that rddl:resource is an element, and obviously cannot
> be made the root element of the document; is there any
> convention that says "child rddl:resource elements of the root
> element necessary apply to the whole document"?;

The RDDL specification appears to only make provisions for the semantics of
rddl:resource elements that appear within the context of the specially
adapted RDDL XHTML derivation. To answer your question, you'd have to
carefully scour the documentation, and more likely email the authors.
There's nothing stopping you from embedding the rddl:resource elements, but
you have to be aware that the semantics are likely "undefined" at this
point.

There's nothing stopping you from making your own element, of course, but I
suspect that you want RDDL parsers to be able to work on RSS 2.0 documents.
I don't think you could rely on them doing that. In any case, using the
root element's namespace as a link to the RDDL profile for the language is
basically how the system was designed to work.

>   (ii) Is there any standard technique for embedding information
> in the document itself that is an rddl:resource link pointing to the
> RDDL itself of the document?

Apart from the root element's namespace? :-)

Just a quick sidenote: the other namespaces that constitute RSS 2.0
extensions could themselves use RDDL to define what they mean, and how
they're to be converted. However, the RSS 2.0 namespace overrides
everything: you can't ask the namespace of bits of embedded elements to
find out what those elements mean in that context. You have to go to the
root element's namespace, and find out what it says about stuff that's
embedded inside it. What RDDL could do with is a feature for saying "for
other namespaces used as extensions to instances of this language, you can
use their RDDL profiles as the definitions". I note that the XSLT program
that Sjoerd wrote is flexible enough to convert the extensions that Dave
added to scripting.com's RSS feed into RDF. I haven't properly looked over
his code yet, but I trust that it competently converts to RDF in all cases;
if not, I'm sure Sjoerd would be happy to update it.

Many thanks for your comments,

[1] http://www.garshol.priv.no/download/xmltools/prod/XSV.html
[2] http://www.w3.org/2001/tag/ilist#mixedNamespaceMeaning-13
[3] http://www.w3.org/DesignIssues/XML
[4] http://backend.userland.com/rss2
[5] http://static.userland.com/gems/backend/rssTwoExample.xml

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Wednesday, 18 September 2002 20:10:03 UTC