| |
Call for technical participation in a proposal for LEGO enthusiast content
sharing.
BACKGROUND:
I’ve been working on a project for a couple of months that extends the RSS spec
to encompass envisioned needs of specific communities, specifically LEGO-related
communities. This project, the LEGO Enthusiast News Network Initiative (LENNI),
is very roughly spec’d and has a sample
implementation[1].
This content and sample[2]
is an earlier iteration of the project’s scope, which has changed recently. RSS
geeks will notice it’s a bit half-baked; I’ve been doing more research into RSS
and have a slightly greater understanding of RSS now. But I’m even more
convinced LENNI will help solve the perceived issues.
Note: The LENNI site linked above is unfinished and will likely be completely
overhauled. I’m linking for completeness only at this point.
THE COMMUNITY NEED:
During BrickFest 2004, several discussions about community needs took place, and
I was involved in one or two. Ashley Glennon is shepherding
overall discussions on those
points[3], and I’ve talked with him and several others about this subset.
Specifically, how to “share” or distribute news and other information so it’s
easy for LEGO enthusiasts to keep updated? Obviously there are a ton of
resources online - LUGNET, 1000steine, and many many more (177,000 if you search
for “lego fan” on Google[4]). But what about a way to gather the stuff you’re
interested in so you don’t need to visit a bazillion web sites daily to find out
what you need?
One way is by sites publishing news feeds via RSS, Really Simple Syndication,
which a handful of brick-related fan sites are beginning to do. A short list is
available at the new LEGOFan[5] web site. This is a great start, but to me, there’s so much more
you can do with this type of content, such as calendaring.
I may be way off base, but to me it seems apparent that if content is made
available, it’s possible for tools to be created that present the content in a
customized, updated view. Yes, there are a ton of RSS aggregators available, and
they do a good job at presenting latest lists of content. But you still need to
know where the content comes from, and how to find, download, install, and
configure an aggregator before it becomes useful. This requires a fairly high
level of geekage, setting the bar high for implementation (both in publishing
and reading content).
BTW, “content” is an overall name for news items, personal blogs, pictures, set
lists, market information, or whatever other information somebody can collect
and disseminate. RSS has lately become closely associated with blogs, but that’s
really a subset of all content.
THE CHALLENGES & POSSIBILITIES:
Traditionally-published and aggregated RSS might be able to handle a growing
percentage of LEGO-specific content, but there are several challenges associated
with this particular niche. I’d like to solve as many of those challenges as
possible by using RSS as a base and extending the spec to accomodate the special
requirements of this community. The LENNI spec should be a community reviewed
and approved project.
- Publishing - A lot of people and groups regularly publish content on the web or via email. Some are beginning to use RSS (see LEGOFan.org). However, as stated above, the learning curve is initially steep on implementing RSS. LENNI should help reduce that curve.
- Reading (Aggregating) - Easier than publishing, but still requiring a propeller beanie. It’s up to each individual to find the feeds, install an aggregator (from many available), and keep up on all the feeds. Reading content should be made as simple as possible.
- Filtering Content - Current RSS specs don’t have an easy way to deal with different audience needs. It’s all the same, with little or no filtering of content based on LEGO-specific criteria. Some types of potential filtering include: • AFOL / KFOL / FOL - filtering by age. Is it appropriate for adults, kids, or everyone? • Theme - Pirate, Town, Space, Castle, Trains, Bionicle, Mecha, Micro, SNOT, Mosaic, Sculpture, etc. • Geography - Important for club-specific types of publishing, as the audience base grows beyond the point where everybody knows most other people. Language alone (currently supported by RSS) isn’t specific enough.
- Calendaring - Content delivery via RSS-style XML is seemingly perfect to create calendar of events. Extending the spec to include some information can make a multi-source calendar feasible, when combined with additional information (see C above). Some types of calendar-specific information include: • Start date • End date • Location • Cost
- Evangelism - “RSS” is cryptic techspeak that takes five minutes to explain to a layman just to get the basic idea across, and is a description of the mechanism used - not the benefit. “LEGO news sharing” is a far more end user friendly description, which naturally leads to more questions if that person is interested. “Powered by LENNI” could be linked on all applicable feeds back to an explanatory page, so people can understand just what this project is all about. Also, making it LEGO-specific (or brick specific) brings the community together and identifies this as a “just for us” project.[6]
- Content Management and Security - One of the biggest problems with distributing content from multiple sources is maintaining control. Using RSS allows a publisher to keep the content on their site, but let it be “sucked” into other places. The content creator retains all rights of creation, as well as the power to update or cancel the content at any time.
- Simplicity - Creating an RSS module to define LEGO-specific extensions, and providing XML writers and aggregators in various languages[7], should greatly simplify the getting started process for both content creators and content consumers. LENNI will also provide a mechanism to list all available LEGO-related RSS feeds, LENNI-enhanced or not (possibly using OPML).
- Extensibility - Many different types of aggregators or XML writers could be created using the LENNI spec, including custom calendars, customized “my LEGO news” pages, and other things as yet unforeseen. For example, a web-based news aggregator could ask for favorite themes in order, and a newspaper-style display could aggregate news from those themes, with that person’s favored themes receiving bigger headlines and prominent positioning.
WHAT I’M ASKING FROM YOU
Now that you (hopefully) have a clearer idea of the issues I’d like to address,
and an overview of the method I’d like to use, I would like to get a “reality
check” and suggestions from people who know more about RSS than I do. This could
involve a simple post with “RSS does something like this, you might want to
check URL x...” or as complex as coding a sample LENNI parser in ASP, or
something in between.
Here are some specific questions:
- Given the objectives listed above, is RSS the best platform to use in solving these issues?
- Is a modified RSS spec (e.g. using a custom namespace[8]) the best method of solving these objectives? If not, what else would be?
- Does RSS need to be extended at all to meet these needs? Is there another way of using standard RSS to solve these objectives?
- Assuming the answers on 1-3 are “yes”, is RSS 2.0 the best version to work with? (I think it is, since it’s relatively simple like 0.91, but can use namespaces without having to include a ton of RDF crud like in v1.0.)
- What extensions should be included in the initial LENNI spec? I envision at least the following item-level additions: • Age (AFOL / KFOL / FOL) • Theme (how would this be standardized, enforced, and updated?) • Calendar Start Date • Calendar End Date • Calendar Location • Calendar Cost (how to deal with different currencies?)
- Syntax: I’m still learning about syntax, but right now I’m thinking something like the following might be best:
<rss version=”2.0” xmlns=”http://blogs.law.harvard.edu/tech/rss”
xmlns:bricks=”http://www.anagrafyxx.com/lenni/bricks#”>
<channel>
<title>LENNI Specification</title>
<link>http://www.anagrafyxx.com/lenni/</link>
<item>
<title>A simple example</title>
<description>A simple example</description>
<bricks:fanage>AFOL</bricks:fanage>
<bricks:theme>Trains</bricks:theme>
</item>
</channel>
</rss>
- Should the updated syntax be channel-level or item-level?
- Should or can Themes be multiple choice?
- What type of “approval” process should be put in place for either news or calendar events, if any? What’s to prevent a malicious person from entering XXX type of content on a KFOL feed?
- What have I missed? Any other suggestions? Is there something like this already in existence?
Any discussion or tips you’d like to share would be appreciated. The final home
for this project is TBD, I’m using my local anagrafyxx.com server as an example
and (possibly) temporary home. I plan on doing the actual spec draft and program
a parser/aggregator in PHP.
Thanks for your help and feedback.
Kelly McKiernan
BrickFest Webmaster | LUGNET Transition Team | LPRIZE Webmaster
BZPower | PNLTC | ILTCO | Space Bricksploration
[1] http://www.anagrafyxx.com/lenni/
[2] http://www.anagrafyxx.com/lenni/channeltest.php
[3] http://news.lugnet.com/people/?n=4078
[4] LUGNET comes up first!
[5] http://www.legofan.org/Default.aspx?tabid=107
[6] Although I have a feeling that if this catches on, other similar
initiatives may pop up in other communities.
[7] PHP, ASP, Cold Fusion, Perl,
etc.
[8] http://www.disobey.com/detergent/2002/extendingrss2/
|
|
Message has 3 Replies:
 | | Re: Attention all RSS geeks!
|
| (...) Sounds like a great initiative. Thanks! My site has, coincidentally, been recently converted to use blog software (blosxom) to deliver content. That means there is automatic RSS support. My RSS feed for Lego postings is at (URL) would say that (...) (20 years ago, 23-Aug-04, to lugnet.publish)
|
31 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
