Curiouser and Curiouser!

Curiouser and Curiouser! on metadata http://matt.blogs.it/ RSS feed for topic metadata Copyright 2006 Matt Mower Squib/0.1 self@mattmower.com self@mattmower.com en-gb Bringing topics to RSS Sun, 30 Jun 2002 10:10:55 +0100 <A href="http://www.iaslash.org/node.php?id=4523">Bringing metadata back into RSS with subject taxonomies</A>. I hope to be able to spend time experimenting with XML again after a few projects I'm working on settle down. First on my plate will be to read more about how to bring <A href="http://www.xml.com/pub/a/2001/05/02/semanticwebsite.html">subject-headings/topics into RSS</A>. Specifically, I think <A href="http://www.topicmaps.org/xtm/index.html">XTM for Topic Maps</A>, the <A href="http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_taxonomy.html">RSS taxonomy and Dublin Core modules</A>, and Peter's <A href="http://xfml.org/">XFML</A> are where I am going to be spending my time at first. [<A href="http://www.iaslash.org/">ia/ - news for information architects</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » Serendipity! I'm also interested in how to add topic-based metadata to RSS feeds.  I'd come across XTM a while back but not had an immediate use for it.  Time to start reading I guess.  </BLOCKQUOTE> http://matt.blogs.it/entries/00000063.html More on liveTopics Wed, 10 Jul 2002 21:51:52 +0100 I gave an initial pitch of some of my ideas today.  Not a pitch that I would like to give to an objective audience but, then, this is only my second day <A href="http://radio.weblogs.com/0107808/2002/07/09.html#a179">off the job</A>!! I was trying to show how liveTopics and blogPlex fit together. liveTopics really started life as a bootstrap technology for the blogPlex.  blogPlexing depends upon being able to extract meaningful information from what people say on their weblogs.  Until such time as technologies like Cyc or Summarizer (see Share in the sidebar) can deliver the goods I needed something else.  Hence liveTopics was born to allow you to annotate your posts with descriptive concepts.  From a very simple original concept it has taken on a life of its own which is kind of cool. There are two steps on the way to blogPlex that I think are worth sharing.  The first is topicRolling which I have discussed in another <A href="http://radio.weblogs.com/0107808/2002/07/09.html#a181">recent post</A>.  Briefly topicRolling allows you to publish your topics & subscribe to the topics used by others.  This allows a group of people to develop a shared conceptual vocabulary or BlogSpeak. The second is the super-blog.  This was really <A href="http://www.wwpp.org/">Jack Foster Mancilla's</A> idea.  This is an extension of the Blog Topic Table of Contents (TTOC) idea which will be familiar if you click through any of the topic links on my page (or click <A href="http://radio.weblogs.com/0107808/outlines/topics/allTopics.html">here</A>).   At the moment the TTOC is an individual affair, however pretty soon I am to provide the ability for a group of people to create a super-blog together. In the same way that the TTOC now lists each of an individuals posts under a topic, the super-blog will list the posts of every member creating a way to see what each member of the group has posted regarding specific concepts.  This makes topicRolling very important.  We will also need tools to support the merging and grouping of topics into <A href="http://radio.weblogs.com/0107808/2002/07/09.html#a182">topicThemes</A>. My view at the moment is rather than embarking on a massive project to create some kind of control language or standardized vocabulary that we allow Darwinian pressures to select topics.  As has been written elsewhere people will gravitate towards "good" topics and abandon the bad (and there will be tools to help the losers graciously migrate).   The pressure will come from the other users of the plex, in order to be listed you have to use the right topics. I can imagine situations where two similar topics will grow equal in size.  Thats okay.  Clever software can work out that they are synonymous by examing their associations with other topics.  And the use of topicThemes will help to prevent unnecessary isolation. And then we reach the blogPlex itself.  At the moment I envisage this as a service subscribed to many blogs or klogs.  Using the data in each along with the topical metadata to create profiles of bloggers and kloggers. The value of the profiles is that they will allow the blogPlex service to match up bloggers who are writing about similar concepts - who are not already linking to each other.  This is a key point because it is this that enables new communities to form.   http://matt.blogs.it/entries/00000160.html Fixing intranets with klogs Sun, 18 Aug 2002 22:31:55 +0100 <A href="http://www.steptwo.com.au/columntwo/archives/000166.html">Fixing intranets</A>. It's interesting how the same issues seem to come up in bunches. Over the last month, I have now talked... [<A href="http://www.steptwo.com.au/columntwo/">Column Two</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » James has written an interesting post about some of the common problems with intranets that he encounters with his clients.  As someone interested in how klogging (I'll use the term for now!) could affect the role of intranets and content management his issues seem particularly relevant to me.  In preface to my remarks I should point out that I am choosing to address static content rather than the possible dynamic web applications you might find on a typical intranet. The issues, re-ordered slightly to suit my responses, are: <OL> <LI>The intranet has grown over time. <LI>Manual processes (using Frontpage or Dreamweaver) are used to publish pages. <LI>A lot of information has been published, but the site isn't being used. <LI>There is little high-level structure, and users are not able to find information. </LI></OL> 1. If you want a logical hierarchical structure then organic growth is a problem.  It's like running water, it flows down along the path of least resistance and doesn't care about the direction.  Same with people, they'll squirrel stuff anywhere that makes sense today (have you taken a good look at your my "My Documents" directory lately?).   Of course if you're klogging then this organic growth is part of the package.  Whether that bothers you is probably a factor of points (2), (3), and (4).  2. This is most obviously solved by klogging software.  It's one of the fundamentals. 3. Hard to say but I guess much of the information published may be of low quality.  In my experience no matter how hard publishing to an intranet can be, creating information is harder still.  This leads to variable quality in that information.  Variable quality leads to low usage.  Low usage provides little incentive for new information to be created and so on. Klogging address this in two ways I think: <UL> <LI>When you have something to publish it's dead easy: click, type, click. <LI>You can publish in bite-size chunks.  This means that if you have a small but useful piece of information you can just klog it.  You don't have to pad it into a long document to make it worthwhile.  You also don't have to find "just the right place" for it to go, it just gets klogged.  That chunk can exist in it's own right, waiting for the day someone needs it.</LI></UL> Which brings us rather neatly to (4) 4. As it stands klogging is a decentralizing technology that doesn't encourage a formal hierarchical structure.  You klog and, if all goes according to plan, people will subscribe to you and they will link to you.  Will they be the right people?  Does it make information any easier to locate?  Not automatically no.  But then hierarchical structures don't necessarily make life any easier.  Once a hierarchy is more than about 2 levels deep it can cause it's own navigation issues. Some people might argue that a healthy klogging culture coupled with a Google search appliance (or any search engine that has a pageranking algorithm I guess) could well make it easier to find what you're looking for.  I think theres something to be said for that. My own approach is to allow for easy metadata-enabling of klogs.  My hope is that combining klogs with topic maps will allow new structures to be grown from them automagically.  This can complement the pagerank based search and provide new ways of finding and traversing group knowledge. So should you scrap the intranet and replace it with klogs? I don't think so.  But perhaps you should think carefully about what you want your intranet to achieve and whether some of your goals for information publishing and dissemination couldn't be better achieved with a klogging strategy.</BLOCKQUOTE> http://matt.blogs.it/entries/00000347.html Entropy, big-KM, klogging and the wheel Tue, 20 Aug 2002 19:57:17 +0100 <A href="http://www.rolandtanglao.com/2002/08/18.html#a2630">Roland's Natural Klog Progression.</A>. I spoke of <A href="http://dijest.com/2002/08/13.html#a1927">four klogging roles</A> last week: catalyst, coach, armorer, practice leader. <A href="http://radio.weblogs.com/0107808/2002/08/19.html#a287">Matt Mower</A> advocates the the role of "Intranet Editor:" <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> Much as the users of a Wiki should occasionally re-factor pages that are becoming "busy" I think that a good intranet editor should be grooming the klogs in their organization and drawing together useful strangs to form part (or all) of the static intranet.</BLOCKQUOTE> <A href="http://www.rolandtanglao.com/">Roland Tanglao</A> builds on this: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> I think <A href="http://www.rolandtanglao.com/categories/radiouserland/2002/06/02.html#a2066">a natural progression for knowledge</A> is: <OL> <LI>blog breaking news <LI>harvest it periodically (say weekly) into an FAQ and/or other knowledge base type of documents <LI>Put the link into a a directory that supports transclusion like Manila style directories. </LI></OL> K-Log => (FAQ or other knowlegebase article) => directory.   K-Logs need to be periodically (at least once a month) harvested for content that should go into an FAQ or other knowledgebase document and links that that should go into a directory. This is the job of a K-Log editor :-)! I have been trying to do this with VanEats but after a klog gets to a certain size, it really needs to have some time set aside for it.</BLOCKQUOTE> Practice Leader is probably the closest to a dedicated multi-author editor. Summarizing work in a field, showing the aggregate progress and useful threads. Structuring knowledge into FAQs or other KM systems may be a natural progression, especially as klogging tools and KM tools build bridges. Entropy, bad. Fighting entropy, expensive, slow.  Self-review is a powerful tool for learning. Going over my own posts for the past week, month, and quarter has shown patterns I missed, ideas I was skirting but never wrote outright. It reinforced brief social connections, blogs to which I linked to and people with whom I briefly corresponded. It takes concentrated time and effort. It helps me to print out all the pages on my blog for that period; something about shuffling through paper. Folks are trying hard to automate this work. Summarizers. Cluster analysis. Text to Structure converters. Taxonomy systems. But the expert author of the original content is often the best judge of relevance. [<A href="http://dijest.com/aka/">a klog apart</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » I think one of the things about klogs is that are no better than any other KM system when it comes to entropy.  In fact they are likely to be a hell of a lot worse -- it's just the entropy matters less.  Any information system that isn't properly maintained has the potential to quickly deteriorate into chaos. The fact is that most people don't want to have to find just the right place to put something.  Most people aren't going to review what they have done.   You can force this behaviour, you can encourage it.  But is it really necessary that everyone has to become a librarian in order to function in a knowledge environment? My alternative is that we recognize and promote the value of good editing (and, hence, good editors).  Have an editor/practice leader to head each area whose responsibility it is to aggregate good knowledge.  Then reward them when they do it well.   Example:  Look at the number of search engine queries for specific keywords.  Tie those keywords to projects/areas.  If the number of searches trends downwards something is working.  Okay, too simplistic? Then suggest something better! An area I have been thinking about is how I would integrate the idea of uploading files to a KM system when klogging.  One approach would be to provide some kind of clever dialogue to allow the user to specify where they want the file to end up.  That sounds like hard work for me & for the user. Alternative strategy:  Allow the user to put a file in an enclosure.  Radio will upstream it to the KM server as part of the RSS feed.  The KM server will toss the file into an upload bucket in an area based upon the metadata of the post (ala liveTopics).  It's then up to the practice leader for that area to decide where the document actually belongs and move it there (or indeed if it belongs at all). Is this less efficient?  Maybe so.  Is it more effective?  I think so. Agree? Disagree?  Ideas?</BLOCKQUOTE> http://matt.blogs.it/entries/00000389.html For a well baked blog, add topics Sat, 28 Sep 2002 12:59:52 +0100 <A href="http://www.networkcomputing.com/1320/1320buzz2.html">Michael DeMaria</A> over at Network Computing wants weblogs to have topical lists of posts.  He points out that the time-based format isn't the easiest thing to use when looking for specific posts on selected topics.  There are obviously two ways find posts contain a specific topic: 1) Use a search engine.  This is the best approach to use when people are resistant to entering metadata.  2) Use a metadata tool like LiveTopics by <A href="http://radio.weblogs.com/0107808/">Matt Mower</A>.  Matt has built a tool for Radio that makes it easy for authors to enter in metadata with each post.  This makes it easy to provide directories that list post by topic (through use of the outliner).   Basically, Livetopics can create a simple list of topical links to posts, or a complex hierarchy of topical links.  Matt has a complex hierarchy on his site. [<A href="http://jrobb.userland.com/">John Robb's Radio Weblog</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » With thanks to John for the link. Clearly I think Mike makes a very valid point.  Weblogs make great diaries, but the by-date navigation structure sucks for locating topical information.  More information about liveTopics can be had by either clicking the liveTopics see-also reference under this post, or going to the <A href="http://www.novissio.com/products/liveTopics/liveTopics.html">liveTopics</A> page on the <A href="http://www.novissio.com/">Novissio</A> website.</BLOCKQUOTE> http://matt.blogs.it/entries/00000618.html What's the difference between topics and categories? Sat, 28 Sep 2002 17:05:23 +0100 With more people interested in liveTopics the question is coming up: "What is the difference between topics and categories?" I think Rick Klau <A href="http://www.rklau.com/tins/2002/08/21.html#a448">sums it up</A> excellently on his weblog (thanks Rick). What categories do best is act as a channel to route content to different places.  This allows you to, for example, run multiple weblogs from one copy of Radio, or have RSS feeds for specific purposes (e.g. I have a feed dedicated to liveTopics announcements, there is no HTML just RSS). But, as Rick points out, categories are a poor choice for organising the metadata for your posts.  They are too inflexible and too hard to setup.  They require choices (e.g. theme) that aren't relevant to metadata and impose limitations (both of interface and duplication of content) that are unwelcome. On the other hand liveTopics are very simple to use.  You create a new topic by using it.  Just type it's name into the field provided when you edit your post.  You can remove topics just as easily. <IMG alt="Weblog Post Form with liveTopics" src="http://www.novissio.com/static/weblogPostForm2.png" border=0> When you publish a post, liveTopics automatically creates a table of contents that contains every topic you have used, and links to each post using each topic.  You also get a number of handy macros to display topics on your weblog.  For example, here is the output from a macro that shows your "Hot Topics" (i.e. the ones you use most often). <IMG alt="hot topics" src="http://www.novissio.com/static/hotTopics2.png"> So that's what topics & liveTopics can do for you today.  Tomorrow?  That's another story.   If you want to see for yourself, click the button and download liveTopics today. <A href="http://www.novissio.com/Downloads/liveTopics/livetopics.html"><IMG alt=Download src="http://www.novissio.com/downloadLT.png" border=0></A> http://matt.blogs.it/entries/00000622.html XFML and the weblog Sat, 05 Oct 2002 10:38:06 +0100 <A href="http://radio.weblogs.com/0110772/2002/10/04.html#a393">An overview of faceted classification</A>. Peter over at <A href="http://poorbuthappy.com/ease/">Ease</A> provides a short overview of what's happening now in <A href="http://poorbuthappy.com/ease/000481.html">faceted classification</A>. Worth looking at if you're interested in metadata and taxonomies. Peter writes: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> tool availability is coming, and that's good because that will allow us to experiment and then refine the theory.</BLOCKQUOTE> This is precisely how I think it should happen. It's a bootstrap process. [<A href="http://radio.weblogs.com/0110772/">Seb's Open Research</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » The forthcoming 1.0.5 release of liveTopics will have a built in XFML exporter.  However, in a sense, this is nothing more than the simple XTM exporter already present (although somewhat buried). To see a sample of the XFML from a liveTopics enabled weblog take a look <A href="http://radio.weblogs.com/0107808/outlines/topics/xfml-map.xml">here</A>.  As you will see we have only one XFML facet generic defined to which all of the topics belong. In considering my own ideas for theme support in liveTopics I think they can be mapped to XFML 'parent topics' and so we won't really be using XFML facets at all. This then begs the question:  Of what use is XFML faceted classifaction in a weblog?</BLOCKQUOTE> http://matt.blogs.it/entries/00000646.html XFML 1.0 (CORE) Published today Tue, 08 Oct 2002 15:33:15 +0100 <A href="http://petervandijck.net/">Peter Van Dijck</A> has published the <A href="http://xfml.org/spec/1.0.html">XFML 1.0 Core specification</A> today. Important points about XFML: <UL> <LI>XFML lets you exchange hierarchical faceted metadata.</LI> <LI>It also lets you indicate topics in different published XFML documents are equal, thus allowing you to reuse indexing efforts.</LI> <LI>Finally, XFML lets you build connections between different XFML maps, by indicating that a topic in one map is equal to a topic in another map: we call this connecting topics, or that a topic is described on a certain resource (a webpage usually), we call this published subject indicators.</LI></UL>   http://matt.blogs.it/entries/00000675.html XTM and XFML: more cousins than competitors Tue, 08 Oct 2002 22:34:19 +0100 <A href="http://radio.weblogs.com/0110772/2002/10/08.html#a420">A faceted classification standard</A>. <A href="http://radio.weblogs.com/0107808/2002/10/08.html#a464">XFML 1.0 (CORE) Published today</A>. [<A href="http://radio.weblogs.com/0107808/">Curiouser and curiouser!</A>] Does this have the same purpose as XTM (topic maps)? What are the differences? [<A href="http://radio.weblogs.com/0110772/">Seb's Open Research</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » Whilst XTM and XFML do have many similarities (and theoretically you could represent any XFML document using XTM -- I think) they are different. XTM was designed to be a generalized format for representing arbitrary topic relationships. The upshot is that XTM, whilst expressive, is relatively complicated.  XFML is more focused and so, IMO, easier to get going with.  XTM can support arbitrary, complex, relationships among topics.  XFML supports fewer simpler relationships.  Don't go getting the idea that XFML is inferior though. One of XFML's guiding principles is that it be focused and easy to implement.  In this I think it succeeds admirably.  The spec is only about 8 or 9 pages long. In an XTM document everything is a topic or relationship.  This means you can model arbitrary structures, but this very power makes XTM quite complex and an individual XTM document is not necessarily easy to understand. By contrast XFML defines just three structures: <UL> <LI>topics (can belong to a single facet)</LI> <LI>facets (can group many topics)</LI> <LI>pages (can have topics as occurrences)</LI></UL> For most web-based applications these three concepts are sufficiently expressive.  Topics can have a parent (but only 1, which must be within the same facet).  A facet thereby is a hierarchy of topics.  So an XFML document contains a number of topic hierarchies which each define a seperable metadata concept. To understand this idea imagine you define topics under the facet Date of Publication like: 1999 2000   Jan 2000     1 Jan 2000     2 Jan 2000     ...   Feb 2000     ...   ... ... Each page in the XFML document will have an occurence of a topic like "1 Jan 2000" indicating its date of publication. Another facet could be Author with topics like: InfoWorld   Jon Udel   Bob Lewis Novissio   Matt Mower and again each page in the XFML document will have an occurrence of the appropriate author topic. The first thing to notice is that it probably doesn't make sense for a topic from the Author facet to appear in the Date of Publication facet (and vice-verca)  They really are orthogonal concepts. The other thing is that because the topics are hierarchical we can start off with a general filter and drill down.  These two facets would allow you to immediately restrict the range of pages you were looking at to: <UL> <LI>only those published by InfoWorld (or Novissio)</LI> <LI>only those published in a specific year</LI></UL> Drilling down further into either facet will filter to an even narrower (more focussed) set of results.  This is a very powerful tool if you have the right facets and appropriately defined topic hierarchies (for your application). For a much clearer and more succint definition read  <A href="http://www.highcontext.com/">David Gammel's</A> recent post to the xfml group <A href="http://groups.yahoo.com/group/xfml/message/145">here</A>. The other powerful concept embodied directly in XFML is the idea of connecting topics together.  This allows me to say, within my map, that: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> my topic X = your topic Y</BLOCKQUOTE> Which is a very powerful, decentralised, way of sharing your indexing efforts without requiring that everyone use the same topics/terminology.  For building real-world topic maps among groups of disconnected people (such as those in different organisations) this could be essential. Okay I've about run out of steam for the moment.  Hopefully this was useful though.</BLOCKQUOTE> http://matt.blogs.it/entries/00000682.html Ad hoc group forming with liveTopics and BlogPlex Wed, 09 Oct 2002 16:42:14 +0100 <A href="http://radio.weblogs.com/0110772/2002/10/09.html#a426">Making group-forming ridiculously easy</A>. Now, the idea is this. When I come across a post on an interesting theme that seems like it might have lasting value, I want to be able to <OL> <LI>Create a topic, with a title of its own and a definition or description in plain English (which may contain arbitrary hyperlinks). Just "where" the topic is stored is unimportant. The important thing is that it is a public entity. <LI>Subscribe to that topic. Subscribing has two effects: it adds the topic to a personal topic list of mine, and it means I'll get posts by other people on that topic in my RSS aggregator because each topic is associated to a shared RSS feed. <LI>Post to that topic whenever I talk about it in my weblog. This has to be *easy*, like checking a box or selecting from a drop-down menu displayed under the box where I write my posts. <LI>Access an archive of posts on that topic somewhere on the Web. <LI>Let anyone edit the description of the topic when important things are added to the "state of the art" on the topic, or when other related topics spring out of the discussion, to let people know where the conversation has branched off.</LI></OL> Basically, from where I stand, this sounds a little like a witch's brew of <A href="http://radio.weblogs.com/0107808/outlines/liveTopics.html">liveTopics</A>, <A href="http://www.movabletype.org/news/2002_08.shtml#000571">standalone TrackBack</A>, and this peculiar brand of editable web sites known as <A href="http://www2.iro.umontreal.ca/~paquetse/cgi-bin/om.cgi?Wiki">wikis</A>. [<A href="http://radio.weblogs.com/0110772/">Seb's Open Research</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » What you are describing sounds very like the idea behind the <A href="http://radio.weblogs.com/0107808/2002/05/31.html#a63">BlogPlex Server</A>, for forming ad hoc communities, I put forward a little while back and is the start and endpoint for liveTopics. In order to form BlogPlexes you need enough good metadata in someones weblog to being to make connections between them.  When I looked around I realised categories weren't going to cut it, AI wasn't ready and hence I began working on liveTopics. Obviously since those initial thoughts (which I don't claim are particularly original) I have come across lots of other new ideas like RSS, XFML and so on.  These will all feed in to the design and I think improve it.  For example in considering item (5) one of the powerful features of XFML is to allow us to connect topics together.</BLOCKQUOTE> http://matt.blogs.it/entries/00000692.html Faceted searching Sat, 26 Oct 2002 22:10:31 +0100 <A href="http://www.searchtools.com/info/faceted-metadata.html">Faceted Metadata and Search: New SearchTools Report</A>. Full-text search is a wonderful thing, but some kinds of information have extensive structure and meaningful attributes for each record. Traditional interfaces for structured data have required users to type into forms or choose from popup menus, but these are often confusing and don't provide enough feedback -- there's no way to tell if the choice is useful. A new way to search and browse using attributes, "faceted metadata", is providing dynamic and interactive access to complex information structures. [<A href="http://www.searchtools.com/news.html">SearchTools News for 2002</A>] <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> » Doesn't mention XFML but still some interesting links about faceted searching & metadata.</BLOCKQUOTE> http://matt.blogs.it/entries/00000782.html liveTopics in RSS2.0 Wed, 27 Nov 2002 09:52:54 +0000 Is <A href="http://radio.weblogs.com/0107808/gems/aaa.xml">this</A> the first <A href="http://aggregator.userland.com/validator?url=http%3A%2F%2Fradio.weblogs.com%2F0107808%2Fgems%2Faaa.xml">valid RSS feed</A> with topic metadata? Today I've finished the experimental RSS generator for Radio that exports the associated liveTopics with each post in the RSS feed.  At the moment topics are contained in a "liveTopics" XML namespace. This will enable a smart aggregator to use the topic's for filtering & combining feeds together.     http://matt.blogs.it/entries/00000863.html liveTopics RSS, RDF and the Dublin Core Fri, 29 Nov 2002 08:55:46 +0000 liveTopics RSS2.0 feeds now use a vendor neutral XML namespace: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> xmlns:rsstopics=<A href="http://purl.oclc.org/NET/rss-topics/">http://purl.oclc.org/NET/rss-topics/</A></BLOCKQUOTE> which is currently pointed at <A href="http://www.novissio.com/resources/rsstopics/">http://www.novissio.com/resources/rsstopics/</A> So each <item/> now comes with an <rsstopics:topic/> definition for every topic it is associated with.  These <topic> tags will soon be pointing back to their ToC entries and optionally to their definition within the XFML version of the weblog. I have taken a quick look at the work done on the RSS1.0 taxonomy module with defines an RDF syntax for specifying topics and advises the use of Dublin Core metadata for adding information.  I'll certainly be persuing the use of DC tags but does anyone think I should be trying to re-use the RDF module & syntax? http://matt.blogs.it/entries/00000904.html More on BlogChannels and topics Fri, 29 Nov 2002 14:52:45 +0000 <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <A href="http://radio.weblogs.com/0110772/2002/11/20.html#a580">BlogChannels for loosely joining webloggers?</A>. There's a dual way to look at blog channels. They provide a sociality-driven incentive for bloggers to apply metadata tags to their posts. By tagging X on a post you're in effect hanging out a bit with the X crowd.  "Metadata has never been more fun!" Well, that's perhaps an exaggeration, but I'm personally much more interested in metadata that means something for people other than me. This is what I find most interesting in this scheme: metadata is shared - that's built into the design. The meaning of the shared term takes shape through the efforts of several people. Contrast this to what currently happens with individual blog categories, where we often have a hard time making sense of each other's categories. UNQUOTE [<A href="http://radio.weblogs.com/0110772/">Seb's Open Research</A>] [<A href="http://radio.weblogs.com/0107846/categories/brainToBrain/">Al Macintyre: Brain to Brain</A>]</BLOCKQUOTE> Al groks it.  Adding metadata is a way of self-selecting the crowd you want to hang out with. And the problem of differences in metadata can be overcome by building shared taxonomy (e.g. using an XFML map) to relate your topics to each other.  By building it out in the open you encourage other people to adopt the same terminology (this is what liveTopics topic rolls will be all about). http://matt.blogs.it/entries/00000921.html Exploring topics in RSS2.0 Sat, 05 Apr 2003 10:38:33 +0100 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 <A href="http://matt.blogs.it/rss.xml">implemented</A> a very simplistic protocol.  Within each <item> is a tag <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <topic id="topic_id" type="topic-type" source="url">topic name</topic></BLOCKQUOTE> for each topic associated with the item (post).  A concrete example (using the rsstopics namespace): <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <rsstopics:topic rsstopics:id="the_state" rsstopics:source="http://matt.blogs.it/topics/topicsT.html#the_state" rsstopics:type="generic">the state</rsstopics:topic></BLOCKQUOTE> 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: <UL dir=ltr> <LI> <DIV><A href="http://www.w3.org/TR/rdf-primer/">Resource Description Framework (RDF)</A> </DIV> <LI> <DIV><A href="http://www.topicmaps.org/xtm/1.0/">XML Topic Maps (XTM)</A></DIV></LI></UL> 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 <A href="http://dublincore.org/">Dublin Core</A> metadata) that asserts me as the owner of my weblog might look something like: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <rdf:Description rdf:about="http://matt.blogs.it">     <dc:Creator>Matt Mower</dc:Creator> </rdf:Description></BLOCKQUOTE> If you cut away the syntactic fluff what this says is: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> Matt Mower is the Creator of <A href="http://matt.blogs.it/">http://matt.blogs.it</A></BLOCKQUOTE> 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: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <item rdf:about="permalink">     <topic id="topic_id" type="topic-type" source="url">topic name</topic> </item></BLOCKQUOTE> 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 <A href="http://www.xml.com/pub/a/2001/05/02/semanticwebsite.html">article</A> by <A href="http://www.xml.com/pub/au/74">Eric van der Vlist</A> discusses this very subject and refers to the RSS1.0 taxonomy module. Somewhat counter to what you would expect <A href="http://backend.userland.com/rss">RSS2.0</A> does not follow on from <A href="http://www.purl.org/rss/1.0/">RSS1.0</A>, 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 <A href="http://www.purl.org/rss/1.0/modules/taxonomy/">Taxonomy module</A> which is intended to allow classification of RSS channels & items. Using the taxonomy module you create something like: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <item rdf:about="permalink">     <taxo:topics>         <rdf:Bag>             <rdf:li resource="topic-uri-1"/>             <rdf:li resource="topic-uri-2"/>         </rdf:Bag>     </taxo:topics> </item></BLOCKQUOTE> 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: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <taxo:topic rdf:about="http://matt.blogs.it/topics/topicsT.html#the_state">     <taxo:link>http://matt.blogs.it/topics/topicsT.html#the_state<taxo:link>     <rsstopics:type>generic</rsstopics:type>     <dc:title>The State</dc:title> </taxo:topic></BLOCKQUOTE> 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: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <topic id="topic_id" type="topic-type" source="url">topic name</topic></BLOCKQUOTE> 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: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <topic id="the_state">     <instanceOf>         <topicRef xlink:href="http://www.purl.org/rss-topics/rss-topics#generic">     </instanceOf>     <baseName>         <baseNameString>The State</baseNameString>     <occurence id="the-state-item">         <instanceOf>             <topicRef xlink:href="http://www.purl.org/rss-topics/rss-topics#story">         </instanceOf>         <resourceRef xlink:href="<permalink-uri>">     </occurence> </topic></BLOCKQUOTE> Again this encodes the same information, using a standard format and only one required namespace (that of XTM itself).  A URI such as <A href="http://www.purl.org/rss-topics/rss-topics#generic">http://www.purl.org/rss-topics/rss-topics#generic</A> 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 <A href="http://www.topicmap.com/topicmap/tools.html">topicmap.com</A>).  However there also a number of problems with this representation when you attempt to embed it within another XML format such as RSS. <UL dir=ltr> <LI> <DIV>It's not clear whether an XTM fragment such as this is valid when used in this way</DIV> <LI> <DIV>Each time a topic is used we will be duplicating it's details, bloating the markup & potentially creating invalid entries</DIV> <LI> <DIV>The <occurence> relation within the <topic> element is technically redundant.  The enclosing <item> indicates the occurrence.  </DIV></LI></UL> 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: <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <item rdf:about="<permalink-uri>">     <rsstopics:topic>http://www.example.org/myTopicMap.xtm#topic-id</rsstopics:topic>     </item></BLOCKQUOTE> or <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <item rdf:about="<permalink-uri>">     <rsstopics:topic>#topic-id</rsstopics:topic>   </item></BLOCKQUOTE> 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. http://matt.blogs.it/entries/00001352.html Announcing: ENT v1.0 Easy News Topics for RSS2.0 Fri, 11 Apr 2003 13:59:53 +0100 <A href="http://www.purl.org/NET/ENT/1.0/"><IMG alt="Easy News Topics" src="http://matt.blogs.it/specs/ENT/1.0/ENT10.gif" border=0></A> <A href="http://paolo.evectors.it/2003/04/11.html#a1567">Paolo</A> and I are pleased to announce the release of the first public draft of the <A href="http://www.purl.org/NET/ENT/1.0/">Easy News Topics (ENT) specification</A>.  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: <UL> <LI>group posts from many feeds by interest. <LI>filtering posts I don't want to see <LI>scoring & promote posts <LI>recombine different feeds dynamically.</LI></UL> 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 <A href="http://creativecommons.org/licenses/by-sa/1.0/">Creative Commons License</A>) 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. http://matt.blogs.it/entries/00001377.html A thought about nested facets Sat, 01 May 2004 11:01:52 +0100 Quick thought about <a href="http://poorbuthappy.com/ease/archives/002822.html">nested facets</a> while I was in the shower.  Paolo and I have chatted numerous times about typed RSS feeds.  The idea being that when <code><item></code>s don't come from blogs we may get different information about them.  For example an item corresponding to an event will have useful metadata which might correspond to some nested facet.  An item from a database feed of helpdesk tickets could have different (or possibility similar) metadata. Hmmm... http://matt.blogs.it/entries/00002162.html When is a calendar not a calendar? Wed, 18 Aug 2004 07:03:04 +0100 <blockquote>Here's an example <a href="http://www.rsscalendar.com/rss/feed.asp?t=m&k=19b1b73d63d4c9ea79f8ca57e9d67095">feed</a> from <a href="http://www.rsscalendar.com/rss/">RSSCalendar</a>. Looks pretty good. [<a href="http://www.scripting.com/">Scripting News</a>] </blockquote> I'm confused. Where is the metadata? http://matt.blogs.it/entries/00002454.html