Curiouser and curiouser!
A security 'mistake' has the author eating dinner at gunpoint.Patriot Raid[Ye Olde Phart]
[...] "You have no right to hold us," Asher insisted.
"Yes, we have every right," responded one of the agents. "You are being held under the Patriot Act following suspicion under an internal Homeland Security investigation." [...]
Three days later I phoned the restaurant to discover what happened. The owner was nervous and embarrassed and obviously did not want to talk about it. But I managed to ascertain that the whole thing had been one giant mistake. A mistake. Loaded guns pointed in faces, people made to crawl on their hands and knees, police officers clearly exacerbating a tense situation by kicking in doors, taunting, keeping their fingers on the trigger even after the situation was under control. A mistake. And, according to the ACLU a perfectly legal one, thanks to the Patriot Act. [...]
The text of this article made for pretty scary reading -- though not, I'm sure, half as scary as being there and, still less, being one of the poor bastards who didn't get an apology.
Of course you guys can expect a lot more, and a lot worse, of this type of thing. Patriot II may have been temporarily derailed but you can see it has the full backing of this neocon administration and they have proved themselves adroit at manipulating events to their advantage.
Whenever power can be wielded freely, and without responsibility, corruption is never far behind. Expect a big growth in the powers and budget of Homeland security, probably fuelled by an imminent danger of some kind (which may or may not come).
The USA is beginning to sound like the world that Philip K. Dick made.
- More about:
Bill Frisell working with John Zorn again. For us who've enjoyed the occasional blast of Zorn's band Naked City and the post Ornette freedoms of Masada, Masada Guitars is an intriguing prospect. Mark Saleski's review makes the album sound gentler than I'd have anticipated. Blogcritics: John Zorn:... [Dangerous thinking]
John Zorn, yeah!
- More about:
Aggregator as archives, not only as instant readers..Dave Winer: RSS readers that work like Usenet readers are a waste of time, imho. Aggregators should not organize news by where items came from, just present the news in reverse chronologic order.
I totally agree, this is why after trying other aggregators I came back to "Radio": it's just like reading a very large weblog updated by several people every hour, it's an activity we are familiar with and the ability that we have to scan titles and relevant information in a page makes this approach much more efficient than having to move from source to source. If an aggregator is meant as a way to take a snapshot of what's going on on hundreds of sources and quicky present it to us, I believe that presenting news in reverse chronological order is the way to go. But I also think that aggregators could be an interesting way to archive content, to let somebody quickly retireve something wrote sometime in the past. Archiving by author, again, does not make sense: most weblogging applications already do that, if I'm looking for something and I know who wrote it, I can simply look on the author's site. There are search engines, which are of course a good way to find information, but not always very efficient. There are cases when a directory might be more useful. We believe that archiving by topic in a directory could be a solution, and this is what we are trying to do. It's not for daily instant reading, it's to archive content. [Paolo Valdemarin: Paolo's Weblog]
I agree with Dave that organisation based upon source isn't a particularly useful innovation on it's own. But if he means that aggregators shouldn't attempt to organise posts at all (other than by order of arrival) then I totally disagree.
I still use Radio as my aggregator but I am not happy with it. It's just the most convenient reader I have found to date. Why? As I have said before, those readers actually made things less convenient. For example one, I forget which, offered me the ability to group feeds into an outline structure. This was good it meant I could keep my general news feeds aside from the feeds of people I know and so on. But when I clicked on a folder of feeds, it didn't present me with a view of all the items from each of the feeds in the folder. Now, why the hell not? This feature alone would have allowed me to dump the Radio aggregator.
Also we are working on k-collector which is a server based aggregator that will group items together from a number of different feeds, but it does that using ENT topics. This is integrated with our topic roll concept so that if you and I use topics from the same topic roll, our posts will appear together. Once you see this working (and we hope to show you soon) you can see how powerful this becomes.
Right now a cloud is identified by a unique URL, e.g.
Any topic from this roll can be uniquely identified as such, however a URL is not a very friendly thing to use in an interface as we have discovered implementing the interface for our k-collector proof of concept.
We're thinking up alternatives and have a number of approaches:
- Add a description attribute to <cloud>.
- Add a description tag to <cloud>.
- Add a <cloudinfo> tag to the <channel>
- Refer to the cloud's definintion for more info.
Options (1) and (2) are more or less the same. We've been somewhat baised towards attributes in ENT so I guess (1) makes most sense. It's also very easy to do. The downside is duplicating the description in every <cloud> tag. But I guess nobody has complained about the duplication of the href.
Option (3) might make sense. We could move all the cloud information here and just refer to it from the <item>'s. More efficient but it adds an extra burden on to processors.
Option (4) was initially my favourite. It's probably the right thing to do(tm). But it's problematic. We support all different kinds of external resource in ENT including things like XTM which doesn't really have any notion of a description. In addition it places a huge burden on processors who may otherwise not be interested in the external resource.
For this reason we will probably be adding a description attribute to the next draft of ENT (which will be published tomorrow).
Next set of features for Manila -- optional human-authored summaries for long weblog posts, along with the option, on a per-post basis to include the summary or the full text in the RSS feed. This is the solution for the conundrum that's been circulating in RSS-Land: should feeds include the full posts, or summaries? The answer is to let the author make the decision, and it's not a global, it's made on a per-post basis. The default is full text so people who do short posts never have to think about it. Along with this we'll have both sides of Trackback. We're testing with Moveable Type, but both sides will work without MT. It's not my #1 feature, but it's clear many users want it, so it's going in. [Scripting News]
Sounds to me like both of these are features that Radio users would like too.
This is really, really, fantastic news.
As a format, ENT is easy to understand, easy for application developers to implement, and pretty easy to parse. Kudos to Matt and Paolo for coming up with a design that is simple but extensible.
The downside isn't so easily excerpted. Read the link for more.
Without wishing to seem oversensitive I think it is fair to say that David's issues are not with ENT per se, but with the idea of people cataloguing their own items with meta data. His problems are social and the same argument could be made about RSS1.0 and mod_taxo.
David reflects upon what happened to meta data in web pages and wonders if the same thing won't come about here too. Here is how I responded in a comment on David's blog:
Thanks for the comment. I think you're broadly right that there will be a capacity for abuse here but it scales differently.
When Google was indexing billions of pages the metadata became meaningless even without the abuse. However with RSS I think the game is different.
I'm subscribed to 108 feeds right now. I add perhaps 1 a week on average. But I trust that the authors of those feeds would use topics reliably or not at all.
Any application I have that can understand my subscription list can usefully utilize those topics whatever I think about anyone else.
In a social software context somone else might trust my confidence in the indexing of those feeds. Etc...
I think we can find ways of making this work. I also think that automatic annotation of feeds with topics is another possibility.
To pick an example from my head. Syndic8 could have a topic engine that creates an annotated feed for every feed they monitor. If you trust Syndic8 you could use that feed instead and get the benefit of their indexing. And so on.
Adina's feed doesn't carry the whole post so:
Dave is concerned that a category standard would fall prey to the problems of ambiguity and scamming that killed HTML META tags.
As I noted in comments on his post, Dave is absolutely right at the scale of the web or the blogosphere.
However, I think that categories will be much more valuable at the community level. For example, Austin has a meta-blog, aggregating posts related to Austin. People in other cities are starting to do the same. If we could map sub-categories, we would be able to create a cross-regional directory. There are local editors who keep the system from being spammed, and make decisions about how to map categories.
So, I think that the system can work in the context of defined groups and defined applications.
The only thing that ENT is missing is a way to alias categories -- Austin's "music events" maps to Ann Arbor's "concerts." Presumably this could be implemented at the application level.
Aliasing topics is a powerful, and sometimes complicated, concept so we choose to leave it out of the ENT spec. We took the view that this issue was best resolved by using a proper topic map behind the ENT cloud. However if the functionality is needed and we can find a simple way to do it, we're open to that - especially while the spec is still in at the draft stage.
The XFML standard, for example, provides a <connect> tag which can be used to explicitly link a topic in one document to the same topic in another document. ENT could just duplicate this facility. But what would it be connecting to?
In XFML the answer is easy. An XFML topics in one document connects to an XFML topic in another document. Similarly for XTM the implication is that you make associations with other XTM topics. But ENT topics are transient things that live for a short while in an RSS feed. So logically you wouldn't connect an instance of an ENT topic in one feed to an instance of an ENT topic in another feed. Would you? Apart from the fact that I know of no way to address an arbitrary element in an RSS feed I think it far more likely that you want to alias the use of the topic to a fixed point of reference, e.g.
When you see "music event" in the Austin feed you should read it as the same thing that Ann Arbor folks mean by "concert."
There may be no current item in the Ann Arbor feed using the concert topic so we definitely need a fixed point of reference. What is that? One answer might be a topic map and topic maps are certainly good for this. How else could we do it?
It would be easy enough to add an XFML style <connect> element to the ENT spec. An example might be:
<topic id="music_event"> <connect>http://annarbor.example.org/topics.xml#concert</connect> </topic>
However ENT also allows topics without the backing of a topic map, in which case someone may just want to specify a topic ID, e.g.
<topic id="music_event"> <connect>concert</connect> </topic>
But the problem with this approach is that it means that music_event is now synonymous with anyone's definition of concert. We could add an href attribute to connect to differentiate but I don't particularly like that either.
Maybe someone else can come up with a simple alternative that befits the style of ENT? I'm still leaning towards this as a problem best solved by topic maps.
[Update] I've been thinking about this a little more and feel that the best way forwards is to work with groups like SocialText and the SSA to make sure the right tools are in place to solve this kind of problem using topic maps. Adina?
Easy News Topics. Last week, Paolo Valdermarin and Matt Mower released their specification of Easy News Topics 1.0 (ENT), which is designed as an RSS 2.0 module that can add topic and categorization information to an RSS feed. I committed to get back to them (and others) with a review and some commentary on the approach. The good news: As a format, ENT is easy to understand, easy for application developers to implement, and pretty easy to parse. Kudos to Matt and Paolo for coming up with a design that is simple but extensible. Now the bad news: I'm worried about two issues. First is the problem of self-categorization. ENT presupposes that authors can successfully create microcontent with the following properties: It can be placed in one or more categories the author is qualified to categorize the content correctly the author's categories have meaning to the reader In addition, we then run into a larger problem with self-categorization, which is the question of categorization across feeds. In other words, we have a problem of definitions - one person's rebel is another person's revolutionary. Even with ENT's inclusion of clouds, which are (potentially) external topic maps that create self-consistent maps of the world, we still have the problem of intentional or unintentional misunderstanding and misreading of metadata like categories, which leads me to think that the entire concept of self-categorization is extremely difficult to work on a large scale. A good example of this failure to scale is the history of web page... [Sifry's Alerts]
David presents a good analysis of ENT 1.0 and, as you would expect from David, some of the wider issues around self-categorization of data. In particular he compares a future of users adding topics to their RSS feeds to the abuse of META tags in HTML. It's a point worth discussing:
Off the cuff I can see two potential arguments to suggest that this won't be a big problem.
- ENT is not designed only for self-categorization of feeds. Yes that's how we intend to use it, and certainly I think a lot of people will use it that way. But ENT could just as easily be used by a categorizer bot that sucked in feeds and annotated them (using heuristics) with topics from it's own cloud. This thought has lead me to wonder if there is some need for authorizing the use of a cloud. Would you trust Googlebot to add topics to RSS feeds? Or Feedster bot?
- As David points out, the solution to the META problem, as wrought by Google, was to bring an element of the social into the mix. He rightly, I think, indicates that a solution to the eventual problems of metadata in RSS will probably be social also. There has been a lot of talk recently about identity and reputation systems. Blogging tends to be very much more personable than ever web publishing was before. I read sites because they are meaningful to me. If your categorization isn't, I probably won't read you for long.
myRadio supports ENT 1.0.
Announcing the release of ENT 1.0 (Easy News Topics) support in myRadio. One of the stated goals of ENT is to "represent topics sufficiently that they be useful in enabling smart aggregators (e.g. filtering, recombining feeds, etc...)". RSS+ENT feeds can be filtered in myRadio, by selecting topics of interest.
Available topics for a feed are those seen by the aggregator, in the RSS feed. That list will grow in time. Later, myRadio will support topicRolls for this purpose. Future features may also include recombining feeds according to topic.
Update myRadio.root in RU, or download the latest here. Configure using the "Edit Topics" link in the myRadio navigation bar. Please contact me with any feedback, suggestions, and bug reports.
Fantastic news. Well done Mikel.
This will be the first application in the hands of users that will let them get the benefit of topics in their feeds. liveTopics 1.1.3 is in beta at the moment and should be available soon. Once that happens there will be a small cluster of feeds that do support ENT. But we need to do more.
Specifically we need to find a way to get at the hordes of MovableType users and get them in the game.
All together now... "Land of the Free, Home of the Brave."
We are proud to announce the launch of the Social Software Alliance
The brainchild of the pioneers at SocialText the alliance is intended to be a place where the developers & users of social software can come together to create open standards, and, contribute industry best practices. Our initial aims are:
- aid discovery of developers working on synergistic projects and standards
- assist in shaping open standards that mesh well with other alliance and Internet standards
- help promote each standard to gain wider adoption
Quoting from the call for discussion:
"The fast-paced nature of the social software space now argues for developing light-weight, easy-to-implement standards, following the Internet tradition of rough consensus and running code, but perhaps moving faster than the larger standards bodies. It is expected that those standards promulgated by the alliance which become widely adopted will be proposed to the appropriate general standards body or bodies: W3C, IETF, ISO, etc. "
There will be a SocialText sponsored Happening tomorrow (see the site for more details) and we hope that anyone who is interested in the development of social software will come and get involved.
Following up on GlobeAlive I've found a few more interesting things:
- The desktop client really needs to go. Trillian will be supporting the Jabber protocol soon, so Jabber as a replacement for the desktop client will be fine.
- The system saves the transcript of all chats & offline Q&A -- something to remember. I'm not sure what the copyright is on material I write in either.
Perhaps the system should allow me to choose a Creative Commons license to be applied to everything I write on GlobeAlive?
Also I wonder if those transcripts and Q&A are searchable? One possibility is that they should be indexed by matching keywords found in the original question (& transcript) with keywords attached to the expert in question.
Another question that occurs to me is: "How does the rating system work?" I can't find it explained on the site.
I really do think this is an interesting idea. So far I've already been asked one real (& tough) question. I guess I will get both sides when I try using it as a user.
- More about:
I'm a lot more careful than I may seem, at least when it comes to other family members. So I've been slow to blog about the good work my older son, Allen (who is, like, 24 years older than the younger one), has quietly been doing on a project he only told me about a month ago, long after it was well underway.
The project is GlobeAlive, the slogan of which is The World Live Web. It's basically a 'live' search engine: one that finds human beings who might be available to answer questions in real time. There's a lot of synergy with what Britt is doing with Xpertweb, and what Mitch has been saying about the Strip Mall Infomediary, both of which also, like GlobeAlive, could stand to benefit from the kind of identity infrastructure I wrote about in Making Mydentity, and expect to see coming out of SourceID and similar efforts. There are also natural synergies with smart mobbery, social software, moblogging, and most of the stuff in Marc's blogrolling column. And, of course, instant messaging with presence detection, which is why Allen and friends are currently developing a new client that uses Jabber.
What prompts me to start talking about Allen's work with GlobeAlive is Britt Blaser's post yesterday, What's That In Your Genes? Britt does a nice (and flattering) job of explaining the fertile ground where the Xpertweb and GlobeAlive circles overlap.
Some interesting context: Allen isn't your typical Web entrepreneur. He isn't even a techie. He's a writer and a philosopher whose research tends to want answers he found Google and other Web search engines didn't quite provide. What he wanted were the kind of answers you can only get from live human beings — real experts on, say, relativity theory or Ludwig Wittgenstein (two subjects he mentioned in recent conversations). Not finding what he wanted with Web search engines, he decided to invent an engine that searched for live people. Here's how he explained it to me on the phone a few minutes ago:
GlobeAlive is for when you want a person and not a site. If you want a site, Google's your engine. If you want a person, GlobeAlive is there for the job. Or will be. We're still in beta, although we have a very devoted group of people involved already.
Is it for when you're looking for experts?
It can be for any form of interaction; not just an expert answer, even though that's the most common use at this early stage. But I don't want this to be thought of as just another expert site. It's not just that. It's a live search engine. Later we may want to make a distinction between an expert, a conversationalist, or a somebody with something to sell. But for now the primary use will be to find experts, and get expert answers to questions.
Where does it stand technically?
We've been working and reworking it for going on two years now, but basically it's still in beta. Right now we're working with GlobeAlive desktop, which is a crappy instant messenger. That's why we're working on a Jabber client right now. What we're want next is to scale up on both the supply and the demand side. More experts, more participants, and more users doing searches. Right now it's like Google with a handful of Web sites to search. But we've been at this long enough to know that the idea does work, and it does scale. And it will grow organically, and in value. The bigger it gets, the better it gets.
How does an expert keep from getting bothered by the wrong questions?
You only come up in searches when you want to be found. Your keywords and nothing else. (It's a bit more complicated than that, I think; but that's what I wrote down.)
What about your business model?
Revenues come from paid placements. We've played with the word "chatvertising." In any case, appropriate advertising. Positive-value stuff. Nothing insulting or intrusive. And we want to put in financial incentives for participants in the form of tiered revenue sharing.
I'm intrigued by the idea that the Web, or the Net, is missing a live element, in spite of all the efforts going on with VoIP, instant messaging and other stuff. And I'm impressed that Allen has already taken this thing as far as he has, entirely on its own bootstaps. He's funded it himself, out of his own pockets, and with the help of many friends who believe in the idea.
He's also started a blog. That's in beta too, but coming along nicely for a rookie effort.
So check it out. Sign up, if it intrigues you. Since Allen's now out here in the blog world as well, I'm sure he'd be interested in all kinds of connections and constructive feedback.
GlobeAlive does look interesting so I signed up. This is fairly simple although choosing the keywords to be associated with takes some time and is pretty much unassisted.
In order to be available to help people you need to run one of their desktop clients. I'm doing that now but I will be glad when I don't have to because it's awful. The proferred Jabber is no more convenient for me than their own client. I want something that lets me continue to use my existing IM client Trillian.
Since nobody else seemed to be about to ask me a question I decided to try and chat with myself. This experience has left me a little skeptical. The client just connects, automatically. There is no page-request, no introduction, the guest is unidentified and all I would get as a clue is their last search term (if any).
As a protocol I think that this leaves a lot to be desired of. It would only take a few false and/or malicious connections before I might wonder if this is going to be a bother.
I think that the person wanting to chat should at least be asked their name, and a precis question. Since I am, presumably, helping them for free I don't think it's too much to ask that I shouldn't have to do it blind!
Anyway, that said, I am ready to help anyone on my choosen topics. Ask away!
Oligopoly Watch. Author Steve Hannaford has been a consultant and business analyst for a long time. I don't know how long, but I remember him writing business columns for MacWeek more than a decade ago, when getting on their "free" subscription list was still a big deal. Over the years he's published a variety of management newsletters and written a couple of books which are classic texts in the graphic arts industry. Steve and I have been friends for a long time too, and I've encouraged him to start a weblog. For the last few years he's been following the seismic shifts wrought in the business world by the Internet, technology, and globalization and he has some interesting things to say about business, markets, and the effects of global conglomerates. Now Steve's decided to take the plunge and launch a Radio weblog, Oligopoly Watch, as a precursor to a book he's writing on the same topic. He takes a look at current news items and provides some interesting insight into what they really mean. If you're interested in what goes on behind the scenes of your favorite multi-national check it out. You might be surprised at what you find. [b.cognosco]
Steve's blog was a fascinating read. I shall be subscribing.
New RSS features on topicexchange.com. A minor (but very handy) change to the Internet Topic Exchange today: it now supports ENT (spec), which means suitably equipped aggregators will be able to pull topic information straight out of the RSS feeds.
Making this actually useful is a new RSS feed: all posts on the site. If you want to keep track of everything, subscribe to that one (traffic on the Exchange is still not awfully high, so you won't find yourself overwhelmed). An aggregator which understands topics will be able to just pull down this one RSS feed instead of heaps of individual topic channel feeds.
The most interesting bit is yet to come: I've been contacted by Scott Johnston and Greg Gershman, who both seem interested in using Topic Exchange information to do some sort of classification of search results. Sort of like the way Google uses dmoz to give you links to relevant categories when you search. This functionality is yet to come, but the hooks are there in the Topic Exchange, so any developers are welcome to start using them from now on!
For people who are interested in using this, I've written a page to explain how to handle the data. Enjoy!
This is fantastic news. Well done Phil!
Just came across a link to:
which is an attempt to create a validatable XML language for describing outlines. It's simple and, as you would expect, very similar to OPML. Key differences are:
- The use of a <metadata> tag in the <head> section to allow generalized meta data to be used there.
- The provision of an optional <data> tag to contain an <outline> nodes contents (rather than packing it into a text attribute)
- The provision of an optional <item> tag for use in an <outline> node.
It is this last that is key to OML since the use of multiple <item> tags can replace the use of custom attributes within the <outline> node. It is these custom attributes which can prevent OPML from being validated. They also make it inconvenient to use tools based upon DTD or schema when editing OPML documents (to which I can attest).
A while back I came across instructions for what you need to put into an RSS feed to tell readers that it has moved to a new location (URI). But, for the life of me, I can't find it now. Does anyone know what I'm talking about? I'm reasonable sure I didn't imagine it.
- More about:
ask.yahoo.com RSS beta. Ask Yahoo!, a daily column that features Q&A with Yahoo!'s expert team of Surfers, is now syndicating its content via RSS. Here's the link to the RSS file:
Hey hey -- some RSS action from Yahoo -- subscribe now so they know we're out here! [Brain Off]
I've subscribed, sight unseen. Now wouldn't this be a great feed to have topics? So you could see the Q&A that really mattered to you. And Yahoo! already have a taxonomy.
I've created a page for people interested in beta testing liveTopics 1.1.3, please go add yourself if you want to get involved.
I've been having an agreeable chat with, among others, Danny Ayers about ENT, RDF, and ThreadsML. Danny expressed some concerns about the dangers of re-inventing wheels. I share his concern although our viewpoints are perhaps a little different.
I want to share part of one my messages:
My view is that RDF is a great way of doing things as long as it is wrapped with 1st rate tool support and matched with applications that warrant it. So far as I can tell both of those are near to non-existant right now and RDF remains primarily the domain of "those people who are interested in RDF and think it is a good idea," with a few exceptions.
Back when Paolo and I were tossing this idea around we carefully thought over "are we re-inventing RDF" and came to the answer: "no." ENT is, by comparison, pretty simple/limited compared to RDF. But right now I think simplicity is more valuable thanpower. We are still in the early stages of building the semantic web and, really, the applications we have don't *need* RDF's power right now. We think ENT is "just good enough" to launch a raft of exciting applications.
I fully expect though, that those applications will grow too big for ENT and simple "hard-wired" standards like it. But this demand will, perhaps, lead to an awakening about RDF. It's time will have come because there will be applications that justify it's complexity & the perceived benefits of those applications will be enough to overcome the inertia involved in getting started with it. And, hopefully, by that time the RDF folks will have delivered much more solidly on the tools front ;)
In short my belief is that simple, focused, standards now will pave the way for the adoption of more powerful standards later.
Also, as I have stated before, I don't think that RDF will really hit a home run until OWL is ready for prime-time.
I'd like to publish the 2nd public draft of the ENT1.0 specification soon. Today if I can. There have been a couple of clarifications, a fix to the examples (thanks to Phil Pearson) and a couple of issues to be cleared up.
- The spec says that a topic ID must look like an XML NAME. XML NAME is quite a restrictive set of characters and it looks like it wasn't such a good choice. For example Tim Bray wants to use topic names like sports/baseball/NYMets and XML NAME won't let him do that (I personally don't agree with him about his topic, but that's okay). He suggests using something from the Internationized Resource Identifer (IRI) specification because topic ID's are likely to end up as parts of URI's. Good thinking Tim! So, on this note, I propose changing the XML NAME defintion to IRI ifragment. Does anyone have any comment about this?
- I have some concern that the use of namespaced attributes, e.g. <ent:cloud ent:href=""> instead of <ent:cloud href=""> may cause some people problems. It's perfectly valid XML but people aren't used to seeing attributes in namespaces and it may prove to be confusing. Since we are trying to keep ENT simple and since I don't think it will matter too much either way, I am considering dropping the namespace on the attributes. Does anyone have any comment about this?
We look forward to your comments.
This is a test -- have I broken my feed yet again?
Hopefully i've fixed it again.
- More about:
While ENT is doing something different (it's categorizing individual items within a feed) I can see how ENT might help to solve Chris' problem too. An ENT enabled feed holds topics about the items it contains. Over time it would be possible to analyze the topics and come to some conclusions about what the feed is about.
It would then be possible for software to automatically categorize each feed in the subscription list, based upon their content.
Does that sound like a solution to your problem Chris?
I'm not saying this would be a trivial problem... but it would be a big step closer to solving it. Of course it requires that lots of people use ENT and, hence, that lots of tools support it. We're working on that ;-)
I've noticed quite a few people publishing the ENT 1.0 spec url as:
which is quite understandable because that is, for now, where the document lives. It's, probably, also the URL your browser shows when you view the spec. However the proper URL for the spec is:
This is a PURL or permanent url.
A PURL is like a regular URL except that it is managed by a redirection server. When you create a PURL you decide what it should be called & where it should point. Whenever a browser tries to load the PURL the PURL server automatically redirects the browser to the actual target URL.
This means that when, for example, we move the ENT spec to a more permanent home we can change where it's PURL points and the link doesn't break. It still points to the right place. PURLs are a powerful way to use redirection in advance.
Oh by the way. Anybody can create them. Just go to www.purl.org, register and away you go.
However, for this reason, it is important that the spec is always referred to by it's PURL and not by any particular URL at which it is found. We would be grateful if you could check and see which URL you have used.
Can the tail wag the dog..?
- More about:
Paolo and I are pleased to announce the release of the first public draft of the Easy News Topics (ENT) specification. ENT1.0 is an RSS2.0 module designed to make it really easy to incorporate topics into RSS feeds. Why would you want to do that? Because it will help to enable a raft of new, smarter, aggregator products.
RSS has become very important to a lot of us and we are starting to see its penetration into the business world as well. We think that integrating topics will help aggregators applications to scale to meet the future needs of users as well as delivering some very powerful applications. I've spoken before about the kinds of thing I want my aggregator to do:
- group posts from many feeds by interest.
- filtering posts I don't want to see
- scoring & promote posts
- recombine different feeds dynamically.
I hope that ENT might help bring all these things a little closer. We also see a role for classification in bringing new ways to order, view, and, search weblog data.
We are offering ENT1.0 to the community (under a Creative Commons License) in the hope that we can foster these applications and many more, that we haven't even begun to think of yet.
I will soon be releasing to the public the next version of liveTopics which will be ENT compliant. At that point any Radio user will be able to easily add topic metadata to their RSS feed. We hope that there will soon be many applications available to make use of it.
We look forward to your comments.
There are a NUMBER of patents that were issued - all surrounding this area of VOD - back in the early 90's. This particular one, from USA Video - broadly covers a method for Internet users to request and receive "a digitized video program for storage and viewing. What next? A patent on walking down the street?
I know of patents that were issued for TV On-Deamnd, digital video servers (storing movies - which then get sold or rented) and even hot-spots within a video stream (click on something in a particular zone of the screen.) This a hopeless litigous situation!
I ran into patents first - when we tried to do our MediaMaker project - which had thumbnails representing video clips. Surprise, surprise a company called Montage had that patent. So anybody who ever tries to have a thumbnail represent a video clip - can get held up by Montage lawyers. Of course Montage doesn't have a product, services or really even exist at all - except for the explicit purpose of suing people.
How ironic that the same folks who sued RePlay (and put them out of business) are getting sued themselves. Enough already!
The only thing crazier that current patent laws (in the US and probably here in Britian) is the idea that we have any chance of seeing anything more sane in our lifetimes.
See, here's the problem. (Brace yourselves. I'm going to bring up Lakoff again.) Basically, all our politics proceeds from two radically opposed notions that are nonetheless equally true. The one on the Right holds that the world is a dangerous place, that bad people are on the loose, and that we need to keep ourselves safe from those people. The one on the Left holds that the world is a good place, and that we should do everything we can to nurture whatever keeps it that way. Only one of those, however, makes interesting news. Only one of those is good for stirring up the kind of righteous anger that carries us to war, and to "delivering justice," whatever we decide that is. Only one of those lends itself to handy all-simplifying sports and war metaphors.
Sad but true.
Economic Sledgehammer. As an addendum to the previous post, direct reverse engineering has always been illegal, and the DMCA hasn't changed that. The engineers who developed the x86 clones went to great lengths to do so in clean environments and to avoid any contamination that could be construed as misappropriation of trade secrets or theft. They did this as a direct result of laws that were already on the books exacting severe penalties for such behavior. We did not need the DMCA to protect companies from theft by direct reverse engineering. DMCA extends these severe criminal penalties to the acts of merely discussing such things, investigating them via legitimate research, and engaging in almost any activity that the copyright holder deems to expose his "intellectual property" regardless of whether it causes actual harm or not. Thankfully, the courts have yet to uphold a conviction where no harm has been found and there are those in the legal community who claim this as evidence the DMCA is acceptable and functional law. These "unbiased" advocates of the DMCA blithely overlook the effects of economic penalty imposed on defendants when a law is structured, as the DMCA, to make them guilty until proven innocent. It is the economic sledgehammer aspect of the DMCA that is most damaging to users and individuals, for it prevents innovation by stifling the willingness to speak, act, or promote any function that may draw a copyright holder's ire. [b.cognosco]
Yep, it's hard to conceive of a better weapon of corporate terror -- a fantastic tool for incumbents, anxious to stamp out potential competition. When I read people like Larry Lessig, Ernie and Rick I get the feeling that good law tends to be subtle, precise, does what it needs to and keeps the hell out of everyone elses way. It's hard to see the DMCA as good law.
I was reading recently from The Innovators Dilemma which talks about the history of companies manufacturing hard disks. I wonder, if the DMCA had been around then, whether we would be seeing 250GB hard disks today?
[Posted on xml-dev]
I doubt this introduction will make converts of anyone, OWL just isn't that easy to grok, but the applications it presents are credible ones. I think the problem for skeptics is that they (a) have seen it all before, and, (b) are suspicious of things that they can't directly grapple with, and, OWL & RDF are not for the fainthearted.
The fact that RDF is not widely considered to be a success is not surprising to me. It looks complicated and it's not immediately obvious what you do with it - it's just metadata after all. I believe that OWL or, more precisely, useful OWL ontologies, are what will make RDF successful. It's OWL that tells applications what they can (and cannot) do with RDF metadata. That's it's power.
Two key things need to happen now:
- The creation of applications that help developers to create robust and useful ontologies.
- The creation of libraries for embedding RDF+OWL into applications (as ubiqitous as XML parser libraries are today).
If these two pieces of the puzzle can be assembled then I think we will see a raft of components built that utilize ontologies to perform their functions. These components will be made into JavaBeans, .NET assemblies, published as web services, whatever. Users will consume those services and never need to know that OWL or RDF are involved.
However until those tools arrive I believe the only course left to you (unless you're trying to build them yourself) is to be pragmatic and keep a weather eye open. As Dave Winer commented recently about RDF: "I am not against it, as long as it doesn't interfere with what I want to do."
Franchise history is being made, now if we can just make it to 10-0!
- More about:
Results Oriented KM. Some recent thoughts on KM:
- KM is not an end in itself. It is a set of disciplines and tools to help us meet our business objectives.
What is the point of doing KM if it does not help us meet our business objectives? KM can only be measured by its ability to help us meet our business objectives.
- KM needs to address the quality of our decision-making.
What is the point of KM if we still make lousy decisions - if we do the wrong thing - even exceptionally well? We would do better to do the right thing badly and not bother with KM at all!
- KM needs to address the issue of our motivation and our ability to make use of the knowledge we have.
We can be given all the perfect information and knowledge that we need to do our jobs but if we fail to use it then what is the point?
- KM should help us to improve our awareness and understanding.
KM should not be just about helping us to know more. It is through increased awareness and understanding that we start to see our organizational world in new ways and identify new business opportunities.
- KM is about helping us to identify new opportunities and leveraging them.
Measuring the results of KM is important but we should not forget that KM is also about identifying new opportunities. We can measure cost/profit etc but we cannot measure 'missed opportunities" by their very nature we do not see missed opportunities until it is too late. [Gurteen Knowledge-Log]
Some insightful thoughts from David.
I'm actually pretty pleased with this.
I wrote a new Table of Contents driver for liveTopics which uses the new OPML generator.
Now, fully regenerating my table of contents (the whole 239 topics A..Z of it) takes 49 seconds start to finish!
This was a task that took well in excess of 16 minutes (not counting upstreaming) last time I tried it.
I knew that Radio's outline were slow but...
Internally liveTopics uses Radio's outlines quite a lot. When you are outputting outlines for activeRenderer it seems quite convenient to use Radio's built-in support them as a type. But as my topics database has grown, liveTopics has begun to groan. And this on a pretty zippy P4 1.6GHz, I can only imagine what it must be like for some people out there with somewhat slower machines (Marc?)
So I took a first cut a few minutes ago at re-writing the liveTopics outline generator and did a little benchmarking. At the moment it takes the Radio outline based generator 64 seconds to generate the XML for my topic liveTopics which is the largest topic in my database at 82 posts. By contrast it takes my hand-rolled OPML generator just 2 seconds to do the same work!
It will take a little bit of time to replace the current generator properly but I anticipate the performance difference will be startling.
The next step is to allow liveTopics to import topicrolls from other locations. [Matt Mower]
Matt expands his work on topic information for Weblog entries. He adds another hierarchical layer by introducing "topic types". This basically allows you to group your containers (topics) into another layer of containers (topic types), thus adding more modelling power to one's own topic structure. Without knowing what really is going on in Italy I would be very cautious with attempts to "define a control language for topics rather than allowing users to make up their own." This is where most projects in this are seem to go the wrong way. At some point someone steps in and wants to take control instead of developing tools that would allow the negotiation of shared topic meanings... [Sebastian Fiedler]
Since Paolo's currently out of range I guess I should add something here.
Blog Notes (Giuseppe Granieri's blog aggegrator project) is a structured news feed viewer. It allows you to attach certain pre-defined topics to a post to indicate such things as:
- the post is an ironic comment
- the post is about politics
In order to keep the structure under control the range of topics must necessarily be restricted. So in essence the range of topics in Blog Notes forms a controlled vocabulary and liveTopics will, to some extent, support this.
However that won't mean that people will be unable to create their own topics or interact with other applications that do permit is such as Phil Pearson's Internet Topic Exchange. As a sidenote I am very conscious that the work in integrating liveTopics and TopicExchange never got finished. I have it in mind to get in touch with Phil again and see where we are with the outstanding issues. (Phil if you see this and have a moment, please ping me via IM).
I'm really interested in finding out whether anyone actually uses (either produces or consumes) the the RSS1.0 Taxonomy module (hereafter <taxo:topics>). If you do, I would be grateful if you could add a comment to this post along with the URL of your feed and/or application.
As I posted on Saturday I am investigating methods for incorporating topic metadata into RSS feeds. As a Radio developer I'm mainly interested in RSS2.0 feeds but I don't want to duplicate any efforts / re-invent any wheels unnecessarily. So I'm considering <taxo:topics> very carefully.
However my view is that almost nobody is using it. I've spent a good bit of time this afternoon examining the feeds of various people in the RSS community (obviously trying to home in on those using RSS1.0) and there is no sign.
Phil Ringnalda points me at Syndic8's feed information where you can see that even while 25% of feeds there are in the 1.0 RDF format, less than 2.5% actually declare the <taxo:topics> namespace (and we have no way yet to verify whether they actually go ahead and use it).
If it really is the case that nobody is using it then I have to ask why?
A good site to keep an eye on for anyone using broadband in the UK. I am a Telewest cable customer and have been very happy with their service so far. But if they futz with the T's & C's...
It appears that Google have decided that company press releases and lobbyist puff pieces are legitimate news items as far as Google news is concerned.
- More about:
Trooper-style citizenship – as Heinlein satirizes – is a condition that sounds free and honorable but is actually impossible to exercise with free will or honor. A recent article on posthumous citizenship for some non-American soldiers speaks volumes when it notes that the citizenship is not real or practical, but symbolic. It suggests citizenship may be most meaningful to the dead, the static, the non-thinking.
Heinlein’s citizenship is granted for soldiers who have made it through boot camp, where they have learned not to question authority, to follow all orders from above instantly and exactly, and who have no other allegiance than to the all-wise central state. It is a Rumsfeldian vision of citizenship. It is a citizenship where each moral compass is not individually discovered, tested and mapped, but instead simply imprinted. It must be because "Man has no moral instinct."
Recently retired USAF lieutenant colonel Karen Kwiatkowski compares the Bush/Rumsfeld doctrine to Robert Heinlein's vision in Starship Troopers and finds some uncomfortable similarities.
I've been doing some thinking about how to encode topic information into RSS2.0 feeds. As a simple test of the Radio callback facility I have implemented a very simplistic protocol. Within each <item> is a tag
<topic id="topic_id" type="topic-type" source="url">topic name</topic>
for each topic associated with the item (post). A concrete example (using the rsstopics namespace):
<rsstopics:topic rsstopics:id="the_state" rsstopics:source="http://matt.blogs.it/topics/topicsT.html#the_state" rsstopics:type="generic">the state</rsstopics:topic>
Whilst this does have the advantage that it's simple and direct it's also a bit silly to invent a new format for topic information when we have two standard culprits available already:
RDF is a general format for describing resources. A resource in RDF terms is anything which can be uniquely identified by a URI. An RDF statement (utilizing Dublin Core metadata) that asserts me as the owner of my weblog might look something like:
If you cut away the syntactic fluff what this says is:
Matt Mower is the Creator of http://matt.blogs.it
Referring back to the problem at hand, describing what a post (expressed as an RSS item) is about we could come up with something like:
<topic id="topic_id" type="topic-type" source="url">topic name</topic>
Which is more or less exactly where we started -- using RDF hasn't altered the solution but it has added some framework around it (in this case adding rdf:about to signal the presence of RDF data within the item). However we can go a step further. A useful article by Eric van der Vlist discusses this very subject and refers to the RSS1.0 taxonomy module.
Somewhat counter to what you would expect RSS2.0 does not follow on from RSS1.0, nor does RSS1.0 follow on from the popular RSS0.9x formats. RSS1.0 is, depending upon your point of view, a step forward or an aberation. RSS1.0 uses a modular set of RDF based tags to describe items in the RSS feed. One such module is the Taxonomy module which is intended to allow classification of RSS channels & items.
Using the taxonomy module you create something like:
Here the <topics> element contains a list (using the RDF defined Bag - or unorderer list - container element) of resources indicating topics that describe the item. Each resource then has a <topic> element that describes the topic. It might look something like:
Although it's a jumble of RDF, the RSS1.0 taxonomy module, Dublic Core, and, a custom rsstopics schema this says exactly the same thing as the original:
<topic id="topic_id" type="topic-type" source="url">topic name</topic>
But do we have to deal with such an ugly mess? Perhaps not. Our original choices included the XML Topic Maps format. This is a complete specification for exchanging topic information. An example of a topic in XTM format might look something like:
Again this encodes the same information, using a standard format and only one required namespace (that of XTM itself). A URI such as http://www.purl.org/rss-topics/rss-topics#generic points at a topic in another map (in this case a topic describing the topic-type generic).
The use of XTM comes with a number of advantages with the main one being that there are an increasing number of tools available to process & manipulate it (for example, see topicmap.com). However there also a number of problems with this representation when you attempt to embed it within another XML format such as RSS.
It's not clear whether an XTM fragment such as this is valid when used in this way
Each time a topic is used we will be duplicating it's details, bloating the markup & potentially creating invalid entries
The <occurence> relation within the <topic> element is technically redundant. The enclosing <item> indicates the occurrence.
One way to avoid these problems would be to embed the topics within the RSS <channel> definition and refer to them from each <item>. However we still need a way to refer to the topic and XTM doesn't provide this. If we had a good way to reference topics then we could either embed mini topic map within the RSS file, or just have the <topicmap> in an external file and point to it. What could we use? One possibility is RDF.
Using a combination of RDF and XTM would mean something like:
<rsstopics:topic>http://www.example.org/myTopicMap.xtm#topic-id</rsstopics:topic> <!-- XTM in an external map -->
<rsstopics:topic>#topic-id</rsstopics:topic> <!-- XTM element inline in the RSS -->
In this example the item now refers to an XTM defined topic either elsewhere in the RSS feed (contained within a valid <topicmap> element) or within an external topic map. The referenced <topic> element can further describe the topic (names, types and so on) using all the expressiveness of XTM. It's also efficient since there is no duplicated information within the feed.
I have described approaches using RDF, XTM and a hybrid of the two. Each has advantages and disadvantages although I believe the hybrid makes the best use of both formats.
I'd welcome comments and or opinions from interested parties.
Intel consultant detained without being accused of a crime. No right to a lawyer. No chance to see the evidence against him. Secret proceedings. Covered here. What country do... [BookBlog]
Slippery slopes are... well... slippery.
I don't use Mozilla as my day-to-day browser. Over the last couple of years I have become very dependent upon MS IE. IE may be a terribly irritating browser at times but it's still ahead of Mozilla on Windows and the WYSIWYG editor is a major plus when editing weblog posts.
One thing that does puzzle me though is why the built in View Source application:
- doesn't show line numbers
- doesn't have a jump-to-line-n command
Both seem like pretty obvious functionality to me.
Here are some screenshots to give you an idea where I am going with this.
There are a few more days work to get this to a point where it is usable. I hope to release 1.1.3 to interested parties (Roland?) at the weekend. Oh and of course this release also contains RSS+topics and Topic Types!