On Tue, 9 Nov 2004 19:08:13 +0100, Laurent Le Meur <[EMAIL PROTECTED]> wrote: > > ATFU, http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html gives more > information > about what is being RDF-friendly.
Thanks, good pointer. > But the modifications could maybe be smaller -> for example making the > globally > unique "id" an attribute of <entry> (it can be mapped to an rdf:about > attribute with > a simple xslt), defining the Atom-core entry elements as simple RDF-like > elements (no > mixed content), and allowing any #other# namespaced elements in <entry>. Hmm, XSLT can take the <id> element content and put it into an rdf:about attribute, but I think the aim here would be to avoid needing XSLT if at all possible. It's not a typical use of a URI, but if <id> was left as it is then it could be defined as an inverse functional property when used with RDF. > But: RDF is about metadata after all. The content part of the entry has > nothing to do > with RDF. How would you make the separation? Data is data. The content is a representation of the resource, there's no reason that shouldn't be part of a Resource Description Framework model. I've not followed the content discussion fully recently, but I'm sure there will be a suitable datatype available in RDF. In passing I think it's worth noting that RDF/XML literals changed quite a bit after the original RSS 1.0 spec came out, and the usual approach to content there (as <content:encoded>) shares some of the problems associated with character escaping in RSS 2.0. If there ever is a revision of RSS 1.0 then it might well deprecate <content:encoded> in favour of using RDF/XML's XMLLiterals with true XML content (e.g. XHTML). This could lead to an element <content:unencoded>... Cheers, Danny. [1] http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-XML-literals -- http://dannyayers.com
