Please don't take the subject change to imply the WikiWord discussion
should be trumped by this. I still don't think that fat lady has had her
moment on stage yet. But wait, there's another fat lady lurking in the
wings, and they may be the same individual! (01)
Consider what follows to be a summary or repost of something I've been
harping about elsewhere. It has to do with federating syndications with
topic maps rather than aggregating syndications sorted by headlines,
authors, or time. Here goes. (02)
At blogsunlimited I said this:
* * * * *
At 07:42 AM 5/12/2003, David P. Janes wrote:
>The RSS "disappears" after hours or days, whereas the blog persists. Surely
>I can't be the only person who thinks this loss of information is a fairly
>massive problem? (03)
This particular issue really does help make the case for something that Sam
Hunting and I have been developing (I'm sure we are not the only people on
this planet thinking this way). (04)
We fairly strongly believe that if all (read: as many as possible)
syndications get read on a continuous basis and are federated into a topic
map -- which, BTW, does not copy any of the content of the blogs (or other
syndications) but, rather, points to them in a RESTful way, then the issue
raised (disappearing syndications) is reduced or eliminated, and, at the
same time, far more room for linking and annotations can occur because the
topic map, itself, is a document that resides on the Web. I may have said
this before in this forum, so please forgive the duplication if that is the
case. Slides for a presentation I recently gave in service of Tom
Munnecke's Uplift Academy project (see: http://www.givingspace.org) can be
found at http://www.nexist.org/rss/slides/ (05)
As the slides will show, federation (not aggregation) can be accomplished
in a distributed, even redundant fashion, and it then becomes possible to
merge those federations into a larger, single topic map, one that's
available on the Web at many different URLs, thus satisfying the need for
distributed, collaborative processing of syndications. (06)
The slides also speak to the future of such a federation: the ability to
mine the content of syndicated documents, looking for keywords and phrases,
using those keywords and phrases as fodder for google searches in service
of augmenting the communities of practice that participate in such a
federation. (07)
There is a social side to this. The technical side, that of tweaking the
RSS to satisfy the needs of a topic map builder, are almost trivial:
mostly, the required tags already exist. It's the social side: appropriate
use of those tags, that counts. (08)
Sam Hunting and I occasionally perform vast feats of consulting under the
moniker: "Federating Cognition In The Wild". (09)
We would argue that there exists, today, just one type of blogger: the
"wild type". (biological metaphor, sorry). I personally conjecture that, in
the same sense that serious bloggers make judicious use of FOAF, trackback,
and all the other nifty stuff the blogosphere is churning out, "wild types"
will eventually become "topic types" as they grok and begin to exploit the
tremendous synergy that can emerge when they are thinking in terms of their
contribution to a topic map just as much as they are thinking about their
contribution to the thread(s) in which they rant. (010)
Always happy to entertain comments and criticisms of this proposed paradigm
shift in human collaboration. (011)
* * * * * *
Turns out somebody expressed some valid concerns. Here's that event:
* * * * * *
I think these are thoughtful concerns related to my call for a paradigm
shift, and I would like to respond to them, for I think there are replies
that should be capable of putting to rest the kinds of angst exhibited
here. The three issues raised here are reliability, public trust, and
scalability. Comments interspersed. (012)
At 12:04 PM 5/12/2003, David P. Janes wrote:
>I'm a believer in repositories, obviously, but you don't think that the
>structure, the metadata should be "recreatable" from source -- the blogs
>(and side files) themselves? If the worlds biggest data crash every
>happened at google, one would assume that they could get back up and
>running as quickly as they could re-spider the Internet. With the pure
>repository built upon transitory information (RSS feeds) approach, this
>doesn't seem to be doable.
>
For those who already took the time to view my slides, they already saw the
slide http://www.nexist.org/rss/slides/img2.html which makes explicit my
conviction that this is a distributed, collaborative effort, one that is,
at once, redundant, crash resistant, and not at all conducive to the notion
of the "world's biggest data crash." Yes, individual sites could drop out.
I think the architecture I sketched can deal with that. (013)
>Furthermore, over time, does not one becomes more and more at the mercy of
>the data repository owners? If I want to create my own search engine, it's
>theoretically possible to do: the techiques are well known. With the data
>repository owners, I can have what they allow me, in as much as they do.
>
If the software used to build the repositories is open source (it is), and
if the sites are dispersed and confederate in a collaborative fashion, and
if the content of those sites (topic maps) remain online and downloadable
(they are intended to be so), then, who owns the data? (014)
Now, I can well imagine that there should be business models underlying the
Websites involved, for they must be operating in a sustainable fashion.
Otherwise, what's the point? And, I can well imagine (I can imagine quite
a bit, to quote Han Solo), that there are sound business models that can
emerge when one is a steward of the public trust for a body of data. Those
business models should not, in any way, preclude the full and complete
disclosure of that which is mined from public sources, just as, in the same
sense, data derived from scientific research which is paid for by public
money should be (but is not usually) placed immediately in the public domain. (015)
>Another issue is the "Internet Event Horizon" -- what if the Blogosphere
>starts expanding quicker the capability of the repositories to track those
>feeds? The Internet is wholey decentralized in a nice way right now -- you
>put up a link, I can go there. Centralization reintroduces the concept of
>data bottleneck.
This clearly sounds to me like a request to better understand my proposal
through the lens which illuminates issues of scalability. Earlier, it was
reliability, then public trust. Now, it is scalability. Again, I repeat,
for those who already viewed my slides, the response is clear. Issues of
scalability are almost always dealt with best through scalable
architectures, and confederations of agents are almost always scalable and,
I might add, otherwise extensible in their features and capabilities. (016)
Please recall my earlier words, that users would be able to access the very
same federated information at many sites, presumably located all over this
planet. My slides try very hard to make it clear that old man Von Neumann,
and his bottleneck, simply don't gain any traction in this architecture. Of
course, your mileage may vary, and other proposals that want to accomplish
the same thing -- promote a paradigm shift in Web collaboration -- may soon
appear. (017)
Finally, to return to the original notion of loss of metadata. It is true
that a topic map, say, the XTM notation [1], is a different representation
than is RSS, though topic maps can be serialized in RDF or the XTM XML
serialization, or even the ISO 13250 SGML notation. The original RSS
notation could, theoretically speaking, be reconstructed. After all, it's
all tagged, and XSLT templates could be written, again, theoretically
speaking, to do so. I suspect that once you have the XTM document (the
topic map in any form, for that matter), you won't find a need to
reconstruct the original RSS feed. Indeed, there is no reason on Earth why
blogs could not syndicate with XTM instead of RSS, except for the
historical precedence of RSS in the metadata arena. (018)
Permit me to wax a bit deeper here. After all, RSS really is far less about
metadata than it is about indexing content, and indexing content is what
topic maps were invented for. It just happens that metadata is a good way
to build indexes, but when the thrust of your interest lies more in the
index and less in the meta-aspect of that index, topic maps came along with
the power to build associations and, indeed, whole knowledge bases as
indexes. It is precisely that added horsepower that motivates the need to
move to topic maps for federation and, maybe syndication. (019)
Consider this. What is the purpose of an entry in a blog? I would submit
that the purpose of an entry in a blog is to articulate a position on some
subject and that position constitutes a topic associated with that
subject. At the same time, that entry is more than likely cast under some
illumination, typically, some other blog entry, news article, whatever. In
short, that entry is, in fact, associated with some other information
resource. Absent hrefs in the entry, we may or may not be able to find
that association, particularly in an RSS feed. In fact, we may not discover
that association at all directly from the syndication, but must read the
content and follow its links to do so. (020)
I must now confess that I have yet to read the O'Reilly book on RSS, and it
may have a chapter or two that makes it clear that I am far too naive to be
saying what I am saying here. But, from (as google is my friend) what I
have been able to glean from the Web thus far, I don't think I'm too far
off base in suspecting that RSS just isn't strong enough to do what I think
syndication could or should do. But, I have a bias, perhaps a chip on my
shoulder, because I created the book _XML Topic Maps_ by federating the
writing of a bunch of really smart people into that book and getting it
published. Call it bragging rights, cock-sure behavior, whatever you like,
but, after hanging out with Steve Newcomb, I'm pretty sure that his
original early 1990's vision of the topic map as the right way to build
indexes on steroids is, indeed, one of possibly several tickets to the
future, and I am just as sure that RSS, in its present incarnation, is not
one of those tickets. But -- for those who are still reading -- RSS is a
good start! Mapping RSS to XTM is turning out to be pretty easy, so long as
RSS is used appropriately, so we don't have (theoretically speaking) to
toss out our blog engines anytime soon. (021)
[1] XTM is the XML Topic Maps proposal created by a committee headed by
Steve Newcome and Michel Bizunski, the original creators of the topic maps
paradigm, known then and now as ISO 13250. Documentation can be found many
places on the Web, starting at http://www.topicmaps.org, and also in my
book. Eventually, I will get around to putting the entire book online, most
likely at my development site http://www.nexist.org/dev/TopicMap (022)
* * * * *
I think the two fat ladies are related, if not the same individual. That is
because the nature of the ExpandingWikiWords thread and this new one are
really different topics related, quite closely, I think, to the subject
Semantic Interoperability.
It just seems to me that no matter how you cut the cheese, no wait! slice
the pie, we're all playing in the same sand box, especially, if it is true
that our game is to find ways to augment human potentials with respect to
learning, communication, and creativity. My view is that it shouldn't make
a wit of difference whether you use WikiWords or Enormously Long Names For
Things, whatever. It only matters that you find and exploit ways to
disambiguate things, to mind, as John Sechrest correctly (I think) points
out, context and scope.
I return you now to your regularly scheduled programming.
Jack
---------------------------------------------------------------------------
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor (023)
Build smarter kids globally to reduce the need for smarter bombs. (024)
--
This message is archived at: (025)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=5.1.1.6.0.20030513164351.03a885c0@thinkalong.com (026)
|