Re: Merge threads - who, what, why
> I think it is unfair to blame 'this group' (either the wider
> of RSS-DEV or the membership of the RSS working group who work inpublic
> on this list) for Seth's choice of language. If you have issueswith
> Seth's use of the English language, please take them up with Sethbefore
> using it as evidence for a general critique of this ill-definedwider
> group. Particularly since Seth isn't even a member of the RSS-DEVRSS
> Working Group. It sounds like a heat of the moment thing that thetwo of
> you could resolve amicably offlist (hopefully).You're right Dan, and I apologize. The group isn't responsible for
Seth. Only Seth is responsible for Seth.
I intended this to be an intense discussion, with push back, but one
that didn't get personal.
> > I wanted to make a point today. And I think I made it.environment
> > As for FOAF -- FOAF is friend-of-a-friend.
> > It wasn't meant for identification or for web of trust.
> Um, well it was, since you mention it. As an experimental
> for figuring out how to deal with these issues in the 'wild' of theWeb,
> rather than in an academic/armchair environment. Identification andFOAF
> trust are two of the key issues that people like to speculate on.
> was designed as a way of getting us all some more real-lifeexperience
> of how those issues interact with the available technology (XML,not
> namespaces, RDF, digital signatures, URI identifiers...). It was
> designed to be useful, useable and experimental. Eventually. We're
> there yet, and to my knowledge haven't claimed otherwise (thoughperhaps
> others might've; I've not kept up with Weblogland...).Confusion about FOAF, but you're a daddy of the tech, so, okay.
> > It was a test of a technology and a concept.FOAF
> Yup. Technology that is enormously mixed up in the challenges of
> identification and trust in a distributed information system.
> > I have absolutely no use for a FOAF file at my site. #
> That's fine. I'm sorry you've got the impression people are forcing
> at you. It's just an RDF-based XML document format I made up withsome
> friends for exploring these issues instead of talking about them(we did
> a lot of the latter on the RDF lists; it got dull quick). It wasattention on
> intended to be deceptively fun, but through doing so focus
> some very thorny issues, both technical and social. If this isn'tup
> your street, that's fine. It's just another RDF vocabulary, and ifof
> no interest, plenty safe to ignore for now.link that
> > You want to know about me, trying clicking the little hypertext
> > says "About Burningbird". I know it doesn't have an orange xmlknow.
> > picture attached to it, but such is life.
> Will do. You sound sort of angry about this FOAF thing. If anything
> written on the FOAF and RDFWeb pages have caused annoyance, let me
> If it's Seth, talk to Seth. I'm kinda freaked that FOAF is all over
> Weblog land these last few days, while it's still pretty much work
> progress amonst friends. My advice to the curious: if it looksthe
> interesting, take a look. Many of our pages are a bit rough, and
> docs and code are often that way too. If you find it annoying,something
> half-baked, naive or sinister, maybe take a break and look at
> else instead. Or drop a note with your thoughts to
> rdfweb-dev@y... instead, maybe...
> > "Run your mouth". Unbelievable.
> Yes, in my version of English that comes over as a bit rude.
> > Shelley
- Unfortunately illness kept me away from my machine for a few days, and is
currently reducing my desire to correspond quite drastically. It is also
likely to make my normally rambling style even worse.
However Shelley's main question about the "business" of RSS is important and
I'd like to have my 2c.
It seems to me that there are three ways to define the purpose of a
technology. One I will label "designed", one "adaptive", and the other
The designed way is to have a purpose decided by necessity or inspiration
from which you design the technology. The technology then apparently springs
from the forehead of the individual or group who create it fully-formed,
since it is generally only after much work that the public is made aware of
The adaptive way is to define a purpose by examining the uses to which it's
predecessors are used.
The reductive is similar to the adaptive, but more forcibly redefines the
purpose by producing a technology that can no longer be used for some of the
tasks it's predecessors were put to.
The parthenogenesis of the designed way tends to produce "purer"
technologies with limited application, the adaptive way tends to produce
messy technologies with a wide range of applications, many of which it does
not match very well. As annoying as the inelegance may often be the latter
type tend to be the most useful. The reductive method tends to result in
something between those two.
Many technologies start with a designed version 1.0 (or 0.x when the
author(s) choose to acknowledge that they don't consider it finished) and
are then used for purposes outside of their initial use-case which feed into
an adaptive definition of the purposes of later versions. To elide
historical detail for the sake of brevity the Internet's designed goal is to
be a military and academic communication network that can survive total
destruction of many of it's nodes and the Web's designed goal is to provide
a simple way to write up scientific papers which would include references to
other such papers, hypertext being used to make those references more
useful. The Internet and the Web both have current uses quite different to
those, and many of their parts are used in manners further removed from
their origins (e.g. the use of HTML in many Windows technologies doesn't
even make use of the Web's distributed nature).
I maintain that RSS is such a technology. It's designed purpose is the
syndication of "news" items from individual websites to a portal website, to
be more specific to the MyNetscape portal website. It was *not* designed to
be of any particular use to bloggers, aggregators, or metadata providers,
but it *does* serve them and others.
Which makes answering Shelley's question a bit tricky. Casting the net wide
there are real-world use cases now which include some cases quite close to
the original intent, but also some that are quite disparate (e.g. using
RSS - either in accordance with the spec, or else as a mere provider of
vocabulary - to provide a table-of-contents to a collection of RDF documents
describing a site or other system). As such the best answer I can think of
for the purpose of RSS is:
"To provide information about web resources that change often enough to make
such information worth giving".
Which is a thoroughly unsatisfactory answer really, but not a useless one,
for it still has implications in our decisions if we intend RSS+ to remain
useful to all or most of its current users.
In particular it means that dropping features, including features that are
by-products of design rather than deliberately built into the format, should
only be done with extreme caution. With such a wide range of use-cases any
feature could prove vital to someone. This includes RDF, inherent (as
opposed to spec-defined) ordering, the ability to work as a "pure" XML
format, and in fact everything that someone (including myself) has suggested
The reductive method could be applied here. We could define the use-case of
RSS as, for example, "syndication of blog items", which is pretty much the
use case of RSS0.92+/RSS2.0 and design appropriately, dropping features such
a case doesn't need.
Dropping such a feature is likely to lead to a split as developers no longer
served look elsewhere, indeed that is part of the reason for the
RDFSS/RichSS split. Such a split may indeed be a good thing, but there are
obviously disadvantages in the loss of momentum and critical mass that it
In all I would avoid a reductive definition of RSS+'s purpose. If needed
such reduction can be provided by APIs in only providing access to some of a
feed's information without necessitating the same reduction in the format
This isn't conducive to simplicity, but it doesn't preclude it either, and
everyone benefits from simplicity (that said I'd be prepared to sacrifice
simplicity from an RDF perspective to gain simplicity from an XML
perspective - as in using Collection).