Philosophy of Bright Content

This page is about the general approach taken by BC developers and users, and not specifics of architecture and design. For that see Bright_Content/Architecture

Bright Content supports many approaches to content organization, and many tools and techniques for content representation and templates, but the developers happen to like, XML, Wiki/structured text, XSLT and Atom, in reasonable doses (some things are just better as RDBMS, JSON and such, and Bright Content supports "low impedance": things should be in the most natural formats possible).

Common vocabulary

The core BC philosophy is primarily articulated in the terminology used in the project. Here are some key terms.

Content element. A content element is a chunk of content that might be assembled into a document.

Document. A collection of content that the reader will usually consider a logical whole.

• XML works well for content elements and documents.

Data element. A very structured piece of data, generally more for processing by programs than for direct reading by people.

Records set. A collection of data elements. Think structured records spreadsheet or relational database tables, CSV and such.

• Good fit for RDBMS, less structured DBMS, JSON or the like, depending on volume, access patterns and such.

Content feed. Content elements and documents that are connected to a logical progression of information. The entries of a Weblog, features in a journal, comments in a bulletin board, songs on a radio station, and so much more

• Atom syntax works well for this.

Page. Representation of a document that stands on its own and is not connected to a logical progression of information (i.e. more static in terms of disposition on the Web and not as constantly updated as a feed)

• A near-presentation-ready format such as XHTML or Docbook works well for this

Presentation Templates. Instructions and utility files for sewing the above into the overall user experience.

• Python+Javascript+XSLT works well, in a mix depending on developer preference

Linking open data

BC embraces the LOD philosophy and movement. LOD is community initiative for moving the Web from the idea of separated documents to a wide information space of data. The key things about LOD principles are that they are simple, readily adapted by Web developers, and complement many other popular Web trends. Learn how to make your data more widely used, by making its components easier to discover, and more valuable, by making it easier for people to reuse it in ways even you did not anticipate.

Annotation

Weblogs and Wikis have popularized the idea that readers should be able to attach comments to various parts of a site. Bright Content supports Weblog-like comments, but also takes a step back to the older and more general approach of annotations. The idea in BC is that you can annotate any resource, and that, say a Weblog comment is just one form of annotation. A renderer and other components may choose to assemble the annotations to content as readily as the content itself.

The W3C's Annotea project is one inspiration for the idea, but rather than a separate annotation server BC just uses a special collection alongside those for content elements and content feed entries. Also XPointer is generally not needed since the link is usually to a content element rather than a document, and can be as granular as the content is authored.

Site organization

People manage Web sites, not bits of content. Every CMS thus has some mechanism to organize content into sites. Some, such as Cocoon have centralized site maps. Others allow you to specify template, published location and such as metadata more closely associated with the content elements themselves. This offers some flexibility, but it leads to the problem of how to associate this metadata with content--most end up inventing proprietary conventions for metadata association. Bright Content already has the general idea of resource annotation, and uses special, administrative annotations to establish site organization. This means it doesn't have to reinvent metadata association.