Re: [syndication] You just knew it would be RDF

["Bill Kearney" <wkearney@syndic8.com>]

> 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". ;-)

And they certainly won't if you take the negative approach.

> 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

No, you want to be sure those three will be present.  If more are present you
can certainly ignore them.  Now I also realize you'd want to have some known
limits because of how simple XML tools can process the data.  This can be easily
arranged.

But to dictate 3 and no more is unacceptably restrictive.  It would do no
applications any harm whatsoever to allow for optionally present elements.  You
know this already as it's evidenced quite nicely in things that use RSS modules.
Let's not repeat past mistakes.

> 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" />

Using rdfs:seeAlso is not without it's limits.  There's type info that's hard to
insert using RDF style without it becoming seriliazed in a form some people
whine about.  However, the format could just as well use a schema that clearly
indicates we're essentially inheriting from seeAlso and everything will work out
fine.  And things that don't use schemas won't care.

> 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?

Right, here's the idea I've suggested previously, once we get a handle on the
'rel' string then we identify and document the format types and setup fragment
URLs for them.

I've got a purl being setup for this but others can certainly be used.

The idea being we'd use either MIME types or URI as the key to the types.

http://something.example.com/feedlist/1.0#subscription
http://something.example.com/feedlist/1.0#group
http://something.example.com/feedlist/1.0#category

And things like that.  Each backed up with a web page at that URL with an A name
ref at that fragment.  This to not only let developers do a string match on the
URI but to let people reading the XML readily find some documentation.

The format URI is likewise do-able.  OCS has one already, ADX should be issuing
one shortly.  Anything else wanting to play along here would benefit from
publishing one of their own.  Then it's just a matter of the developers being
educated about the merits of each.

> 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.

As I've asked countless times before, the avoidance of unnecessary complications
is important.  There are plenty of ways to serialize this data so that's both
simple to parse and based on a compatible data model.  Worrying that it is or
isn't RDF has shown itself to be needlessly divisive.

-Bill Kearney