Jim Moore’s blog: Innovation, Strategy, Public Policy

We each have an interest in the knowledge in the professions. Medicine, in particular, touches each of us and every family member. Knowlege management in medicine is a matter of life and death.

The outline is central to providing access to knowledge. The annotated bibliography, the reading list, the journal citations, the directory of research literature, the citation indexes, and so on are core structures for the organization, sharing, teaching and learning, and use of knowledge in professions.

I believe that organizational learning has been vastly enriched by access to online sources.

On the other hand, the abundance of materials available to us today cry out for organization and structure–something more constructive–or better said, more constructed–than lists of search engine results.

One answer is found in the creation of digital directories–the online, digital versions of indexes and annotated bibliographies.

The special opportunity with OPML is that it is a computer language created for outlines. Thus as the OPML tool set is expanded, we are making a world where outlines can be more and more easily used. And the hope, at a higher level, is that this in turn makes knowledge more easily used.

So here is a profoundly interesting and useful OPML-based reference application created by Philippe Campeau and posted tonight on The Online Metabolic and Molecular Bases of Disease Blog.

The OMMBID Blog » Blog Archive » Journal articles
Created using Internet Explorer 7, Google reader, Intelligentteams.com and Grazr. Use the buttons on top of the reader to change the view or open in a new window. Have updates of these feeds emailed to you using RMail.

Philippe Campeau

Wrap your mind around this: The collective expertise organized in this application is immense. Yet today’s tools, using OPML, make it a relatively simple matter to make an active, continuously-current, and automatically-updated widget that provides near instant access to this collection of materials. This widget, in clone, can be easily placed on any blog, start-page, web-page (say, Google Pages) or web site. And wherever it lives, it will stay in touch and current with its OPML source.

And all this can be done by the professional him or herself.

Thanks Philippe!

OPML Search shows a fun example here of open playlists–do you like Blues music?

The Playlist Layer of the Web

The structure of the web ecosystem is changing rapidly, with a new layer emerging on the web: the playlist layer. At this point the playlists that make it up are fragmented and mostly proprietary, but a world of open playlists is as inevitable as the commoditization of any other layer of the web.

In the next world, meaning now, folks do not want “search results,” they want playlists. They want these playlists to be easy-to-use, dynamically-updated, relevant, of high quality, and easily accessible. They want these playlists to be open to innovators–that is, to content producers who may not work with mainstream media companies. On the other hand, they appreciate “curating” and list editing, reputation services, and in general, human intelligence (humint) applied to sorting out wheat from chaff.

The iPod is not a music player. It is a playlist manipulator. It is the most elegant playlist machine available. Tivo is not a video recorder, it is a video playlist machine.

The competitive evolution of Playlist Ecosystems

The ecological elements necessary for a successful playlist experience include much more than the playlist. The experience includes search, “playing” and display, etc. Indeed, it includes much more than those even. The experience system, the value chain, begins far upstream, with creative communities. And it moves far downstream, or rather, it moves closer and closer to the user/experiencer–it literally moves into the earbud or video display.

Each of the major playlist leaders is seeking to maximize the effectiveness of its playlist ecosystem. As we will see below, many elements are necessary.

Each leader must find one or more dimension of the ecosystem to excel on, in order to gain customer interest. Each leader must make sure that its ecosystem is not seriously deficient in some aspect of the ecosystem, such that it cannot meet basic customer needs.

Each ecosystem must achieve operational integration to function reliably and efficiently.

The ecosytem must achieve “experience integration” so that the customer can be as passive as possible and yet gain the experience he or she wants–including, ironically, interactivity. Does the person with the iPod want to groove on the music, or play with the controls? Note, by the way, the success of the iPod shuffle. No controls, all groove.

All of this effort comes together at the customer experience–and indeed, the customer experience has multiple dimensions, including pre-purchase, use, and use-justification and sharing..but that is another story yet again.

For now, consider that each of the major playlist competitors is seeking to maximize the “wow factor” in its version of the sytem. The wow includes the “intimacy factor.” A furniture maker recently said to me that the thing that architects don’t understand about furniture is that a piece of furniture defines a world of intimate textures, of touch and smell and color, of feel and heft and a range of postures..furniture is intimate.

Apple playlists are very high on intimacy. As are all high fashion accessories. Indeed, the bag, jewelry, shoes and other accessories business–say, Gucci–is about the creation of small, especially delightful worlds of intimate experience.

Core elements of a Playlist Ecosystem

Creative community

Content design

Content production

Content distribution

Device design

Device production

Device distribution

Storage

Addressing

Source targeting

Search

Playlist display

Playlist saving/tagging

Playlist sharing

Play selection

Play

Experience

Grooving

Community grooving

————————————————————-

Ecosystem-to-ecosystem competition

The most important competition in the world is the fight for playlist ecosystem leadership. This competiton is driving billions of dollars of investment, including research, product development, and acquisitions. Why is this fight so important to the competitors? Because it is a fight for control of access to digital culture. That is, access to digital knowledge, digital music and video, digital commerce.

Companies are the strategic movers and investors, but the unit of competition is not at the company level. The companies in turn are seeking to create winning ecosystem designs, ecosystem installed-bases and incumbancies, and ecosystem-supporting-user-communities. The companies are competing, ironically, to collaborate. To win they must collaboratively co-evolve the most powerful and inclusive collection of content, partners, users, and experiences.

Consider some of the major playlist ecosystem definers in this light:

Google, Yahoo, Microsoft are competing with each other to make playlist ecosystems based on their strengths in search results

Their ecosystems produce dynamic playlists that are profoundly inclusive and comprehensive. This is a strength and causes them–or at least Google–to be the first stop on the web for those seeking playlists. It is also a weakness, because results are very broad and of uneven quality.

When you think of a playlist with a million elements, you realise why the end of search-results-as-we-know-them is just a few months away. This problem is an opportunity for Rollyo and other playlist-from-search-results companies.

Google and Yahoo ads are perhaps the most successful of playlist ecosystems. They are richly supported by the “user-generated content” of advertisers large and small.

Essentially, text display ads are small e-commerce playlists, targeted nicely, convenient display, with quality discipline by the advertiser pays business model and the requirement that ads be clicked-through to continue to be shown.

iTunes playlists and the music industry

A playlist ecosystem that found a way to graft onto and extend one of the most important pre-web playlist ecosystems–that of the recording industry. Pay-for-play, payola, “heavy rotation,” “album-oriented-rock”–all playlist inventions of the recording industry working with its marketing arm, radio.

ITunes is a proprietary format, but very open to content producers, including not only the record industry but bloggers. Very good wow factor, intimacy and identity factor at the experience-end. Steve Jobs knows how to combine wow and intimacy.

Mobile phones with music download and streaming playlists

This ecosystem is the big sleeper in the competition. It is grafting playlists onto communication. A very powerful incumbancy. Proprietary formats, proprietary display, inconvenient and comparatively closed to content producers–but with many many many more devices in place than any other platform: an up-and-comer, obviously. iPod has about 90% share of its narrowly-defined class of devices, but it has a very small share of the digital player market–and it has no streaming capability. Phone companies don’t get “wow” very well, but Motorola and Nokia are teaching them.

Steps Toward an Open Playlist Layer

So what does all this have to do with XML and especially OPML?

Create a seamless, interoperating world of playlists and their embedded perspectives

First, we need to be able navigate within a seamless realm of playlists, in order to be able to find content of interest to us.

OPML is a language of playlists, expressed in XML. We need to be able to translate playlists out of their proprietary formats, and into shared formats that allow for mixing, matching, comparing, extending, analyzing and improving playlists. This needs to be done in machine formats, not by having web users read playlists in one format, say iTunes, and type information into another format.

XML was originally designed to connect two or more databases where the formats were incompatible. XML has become much more. It has become a universal language for expressing web content, a language that enables transformation of web content, a way of syndicating across networks (e.g. RSS), and a way of carrying references to content stored in open repositories with permanent addresses (e.g. RSS enclosures and podcast audio and video files, as well as OPML attribute-based references to URLS). XML has always been conceived as dynamic, that is, as constantly changing based on whatever content it expresses or links to. Thus XML is purpose-built to be the core of a dymanic meta-layer above open content on the web.

Second, we need to make plain the perspectives embedded in any given playlist. We need to reveal the assumptions implicit in and expressed by a playlist. By contrast, today the most widely-used search engines of the static web and the “meme-trackers” of the dynamic blog world proudly hide their algorythms.

Thus today’s search engines have at best a hidden bias in their results and at worst hidden censorship. When the logic of a search engine cannot be examined, and/or when there is no practical way to compare search engine logics with alternative approaches, authors, and purposes, we are at the mercy of unseen and unspecified/implicit world-constructing-logics. These logics shape our perceptions of the online world, and they do so at the very moment we are least reflective–at the moment that we truly need to know something.

By contrast, OPML playlists can be open, they can have identified authors, and if they are machine-generated their algorythms and rules can be published and examined. The most efficient way to accomplish the meta-analysis of playlists is if they are in the same or similar formats, and XML is the obvious and probably the only reasonable format to choose.

Open up silos of exclusive content

Content elements such as audio and video files, data elements, and digitized texts need to be accessible freely and directly from playlists. Our vision should be that all content elements are reference-able from any playlist in any format operating from any place on the web. We need to clear the fog from the basic stuff of the web.

Currently, most content is isolated into silos. Blog content is an instructive exception, showing us some of what is needed, and proving that an accessible content layer can be achieved.

Blogs content–”posts” are easily reference-able because they have “permalinks” on each post, and these permalinks, as well as the URLs for the HTML pages and the RSS feeds from the site, are open to anyone on the web.

The simplest form of playlist in the blog world is the hyperlink citation from one blog post to another. Indeed, a playlist can easily be developed and maintained with href lists in blog posts.

Aggregators such as Bloglines are playlist management services for users who read blogs.

The web itself is architected to be open in terms of content. Universal access to elements of content, with a universal resource locator system–yes, I’m smiling, this is what a URL is–is the nature of the web. But over the years the open nature of the web has been reduced as search engines and other tools have become necessary but black-box intermediaries between content and user.

Harvard and the Golden Disk

Today the worst silos, from an open culture standpoint, are those where data is exclusively bonded to curation and search. For example, Harvard is digitizing its entire library resources. Currently Harvard is paying the cost of digital cataloguing, physical preparation and shipping of books to a central scanning facility. Google is paying for the actual scanning. For this, Google is returning to Harvard a “golden disk” of digitized material–but Harvard is precluded from making these contents available outside the university unless pays Google for each page thus distributed.

Meanwhile Google is keeping its own copy of the golden disk, and will make available the same pages–but only if they are accessed through its search engines and whatever business model it deems appropriate for itself. Thus the contents of the Harvard libraries will be digitized and stored, but not open to the playlists of the world’s scholars unless those playlists are created within the Google playlist ecosystem.

One would obviously hope that the contents of the second largest (after the Library of Congress) and most global library in the world would be made open to playlists of all sorts.

Indeed, the “right” answer is for Harvard to set up the contents on open servers, with permalinks as in the blogging community, and let anyone with a blog anywhere make their own references to the documents. These blogs in turn would provide the first universal playlists to the world’s richest trove of written knowledge and wisdom. Bloggers could share references and lists of references, and the result would be a universal library, curated by an unlimited number of curators, working from anywhere in the world.

Public Outlines authored by jcorbett, click here to enter a vast and endlessly fascinating ecology of playlist-of playlists providing dymanic, continuously fresh engagement with Irish personalities of the online world.

The base of the web is made up of millions of URLs. Each URL calls forth resources from web servers. In some of the most interesting cases, these URLs go to MP3, video, podcast, and 3d files. Millions of individuals tend to these gardens, making them as varied and delightful and personal as possible.
Search engines search for these files, catalogue them, and make them available to the rest of us.

But since the early days of the web there has been another way to find resources: Directories. Indeed, before search engines there were directories. Think Yahoo. Many directories have persisted and grown, despite their lack of visibility.

Lately directories have made a comeback. Podcasts, podcast directories, reading lists, Apple iTunes playlists are all directories. Why are directories helpful? Frankly, they can be much more targeted and helpful than search engines, their structure is transparent, and complex sets of results can be ordered and made available in a practical manner. You can with relative ease traverse a directory tree down three or four or more levels. And we are now seeing cool directory-enhancing software like Grazr, which is specifically intended to facilitate “grazing” across levels of deep and rich trees. Trees are coming back.

OPML is the open language of trees. OPML is the Open Playlist Markup Language of the web. OPML is the leading edge of an XML layer that is growing inexorably across the web, on top of and as an alternative to conventional search engines. Indeed, most of the innovation in search now is putting search results into trees–Rollyo–as well as using trees to limit and focus searches. Hybridization of trees and search.

Finally, the rise of “direct navigation” promoted by companies like Name Media is a direct assault on search engines by companies that provide branded directories, such as Photography.com. As these sites have proliferated users have responded, with increasing frequency typing search terms directly into the URL bar, and typically hitting a directory run by one of the direct navigation companies.

The web is changing once again. A new layer is developing. That layer is all about directories as a primary structure for organization access to web resources. It is about separating resource objects from structures. It is about having multiple structures pointing to the same resources. It is about the web as a layer of objects, “described” by outlines. It is about venn diagrams as the new way to think about the web. Venn diagrams that surround sets of resources. Venn diagrams that overlap each other. Venn diagrams that themselves can be searched and sorted and made sense of. And most important, Venn diagrams that are the results of user creativity, collective user creativity, of millions of people.

At the top of this post I highlight the Open Irish Directory, a famous and important set of sets written by James Corbett. Enjoy!

What is peace? Well, it is at least the presence of connections. The food web of life is rich and varied. Energy and structure are moved and created, transformed and broken down, renewed and extended.

The web of a thriving economy is subtle, laced with trust and contracts, protected by the strong hand of the law–especially contract law and other “everyday laws” we sometimes take for granted.

The web of society is deep, rich and robust, when the peace has held and human creativity and commerce and care has been free to thrive.

War tears up connections. Sometimes, like surgery, war may be unavoidable. But ask those who actually fight wars what is involved. They, like surgeons, hesitate to offer their services unless truly needed. Tearing up the fabric of life is a tragic remedy.

Peacemakers make connections.

People want to make their own connections across the web. They want direct access to the gems and jewels distributed there. Teams and groups want to assemble libraries and the digital equivalent of card catalogues of the material most relevant to themselves. They don’t necessarily want to access the most popular, the most linked-to material on the web. Indeed, they want to establish their own special sources, they want to make and share discoveries. This sort of activity is not encouraged by general-purpose search systems. The world needs DIY intelligence. Open, plain connections. Unlimited in scope and scale.

The following chapter is a work in progress.

My intent here is to convey the power of OPLM by revealing its structure, while setting aside for the moment how the language expresses this structure.

OPML, like any successful language, has been pushed by the developer community beyond what it was originally intended to do.

It has been “generalised” and its general capabilities, its most profoundly important capabilities, are being revealed as people continue to push its application.

It has been my experience that a good way to help others see this potential is to explain OPML in the most general terms. Once you see the general structure, which is both simple and powerful, I believe that many of you will then be able to envision even more new creative uses of the format. So here goes:

In structure, an OPML file has looks like this:

Node, Frame, Procedure list

Node, Frame, Procedure list

Node, Frame, Procedure list

Node, Frame, Procedure list

Nodes: Nodes are elements in an outline. The indenting of the nodes enables the author to set up outlines, with a root node, nodes, sub-nodes, and so on as far as you like.

The power of the outlline structure of is that it can act as the definition of a relation–as in relational database. When combined with the node’s ability to reference other code, by way of frames and what frames give access to, and procedure lists and the actions they evoke, OPML can become a vastly open way of reaching out to resources across the entire web.

OPML becomes, with an OPML interpreter, a database controller that takes the entire web as its dataset.

Frames: Frames are like picture frames. They carry HTML and anything that can be conveyed to a browser by an HTML call. This includes widgets. This includes the YouTube and Google Video “embed code” that shows a movie by invoking a flash/shockwave viewer. Frames can display flash animation, animated gif graphics, and Second Life addresses. Frames can show anything that a conventional web page can display.

Procedure lists: Procedure lists are can act as an procedural programming language, interpreted at run time. They are general lists of actions. In OPML these have traditionally been used to refer to other files, either other OPML files, or perhaps RSS sources, podcast lists, and so on.

But the actions in the list can do much more. For example, they can apply CSS to the display in the frame. They can contain Creative Commons and related copyright license information. They can contain meta tags and microformats. They can contain name/value pairs and feed other instructions.

Thus an OPML file has three important structural parts, each of which can be used by a creative programmer to accomplish complementary aims.

In practice, one must work around what I consider a bit of legacy terminology. This is not, I want to emphasize, much of a problem once one understands the basic structure of OPML. But it must be dealt with.

Nodes: Once again, an OPML file represents an outline with one or more nodes. When these nodes are indented relative to each other in the file, they are treated by OPML viewers as hierarchically-organized–i.e., as an outline of nodes and subnodes. This is OP as in “Outline Processing,” Dave’s original and still official meaning for the acronym. The hierarchical nature of OPML makes it possible to express complex relationships among the nodes in an OPML file, as well as among the items referenced by the nodes.

Nodes, in an OPML file, are called “outlines.” In Dave’s OPML terminology an OPML file is composed of many outlines. Nodes are called outlines, according to this parlance, because at each level in a file a node/outline can carry/include sub-nodes below it in the outline. What I might call a single node would be called, in these terms, an outline with only a single top-level member. I am not against this nomenclature and in some ways I agree with its conceptual elegance. On the other hand, after two years trying to explain to others how OPML works, I find that calling each element a “node” seems to work better for most folks. And I note that the same issue exists in everday non-digital outlines, and over time, folks have standardized on having a distinct term–usually “outline”–for a collection of nodes, and another term, sometimes “node,” “element,” “line” and so on, for individual nodes.

Frames: Each node has a field that is not treated as XML by an OPML viewer. Instead, the material in this field is passed through to the HTML interpreter in the associated web browser. This means that this field becomes a frame within which complex HTML can be embedded, and this complex HTML will be enacted when the frame is read by the Web browser. Further, one can embed scripts into the frame field of a node, and these scripts can in turn call Flash and Shockwave viewers as well as other widgets designs.

This frame field is called “text” in OPML. It was originally designed so that what was in the text field not be interpreted as XML. The contents of the “text” field is sent on, raw, to the browser for display to the user. Over time, with HTML, embed code, etc. etc. this text can represent and invoke in the browser a vary wide range of rich text, especially audio and video.

Procedure lists: In OPML, what I am calling procedures are called “attributes.” By convention, if the program reading the OPML knows what to do with an procedure, it does so, and if it does not know the procedure specifically, it ignores it.

Also, by the nature of the spec, the universe of procedures can be added to by the person writing the OPML file.

These two generous provisions bring imporant benefits for innovation in the OPML community. One can write an OPML file with procedures that are widely recognized in the ecosystem of code for rendering OPML, and be sure that these will be treated as you wish. At the most fundamental level, references to OPML, RSS, and HTML files are always supported.

One can also add procedures that are outside of the current universe, and they will be ignored in the positive sense. They will not choke the current generation of code.

On the other hand, if procedures that are added are proven to be useful, they will spread across the community, across the ecosystem of code for interpreting OPML, and will become widely available. The OPML ecosystem is open to profound innnovaton.

In the actual OPML spec, what I am calling “procedures” are called “attributes.” A specific node can have an unlimited number of such attributes.

——————————————————–

I hope this has helped. I find it useful to think in terms of these simple structures. I find it exciting to explore the possibilities opened up by the general use of OPML.