[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
You just knew it would be RDF
Roy M. Silvernail <roy@rant-central.com> wrote:
And folks, I think we've struck oil! One <link> header, where available,
pointing to an RDF file that hosts the full set of metadata about the site in
question. Back that up with a comment pointer in robots.txt for the sites
where the admins work in restraints.
Go back about 48 hours and I remember thinking, "This is going to end up
being RDF". Immediately followed by "some sections of the community
won't like that". ;-)
Looking at Bill's example reminds me that I really want exactly 3 and no
more than 3 bits of information about the files pointed to by this
metadata file.
- href location
- plain text title
- type
We can already say the following in formats that are already well
understood:-
<rdfs:seeAlso rdf:resource="http://foo.com/bar.rdf" dc:title="The Foo
RSS 2.0 feed" />
and in html
<link rel="alternate" type="something" href="http://foo.com/bar.rdf"
title="The Foo RSS 2.0 feed" />
So there's really only one thing missing and that's a formal agreed list
of types. To be used like this.
<rdfs:seeAlso ... ns:type="rss20" ... />
<link ... type="http://bar.com/metatype#rss20" ... />
Now if there's a type of http://bar.com/metatype#list (or something)
that refers to one of these lists as well, we can construct arbitrarily
complex networks of these files. And we would only need a single <link>
entry that could happily go in every web page on a site.
So how do we get this file type namespace built?
I want to ask one last thing that may wind up the RDF people. Even
though we're using RDF, can we please structure these list files so that
they're readable by plain old XML parsers. If you want to add arbitrary
RDF structures, please do it on the end of the file so that the core
information is still in the XML form. This may seem an unnecessary
restriction ("just use an RDF parser, duh!", "It's all just triples,
triples all the way") but we also want this standard to have the widest
possible implementation.
--
Julian Bond Email&MSM: julian.bond@voidstar.com
Webmaster: http://www.ecademy.com/
Personal WebLog: http://www.voidstar.com/
M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433