1. Summary
The AdaptiveBlogosphere is the result of a ComponentBlog. Packages of structured data are becoming post components. [PhilWolff]
2. Description
The virtue of blogs has been their simplicity. Each post only needs one field, and maybe a title and url.
Not everyone is served well by this lowest common denominator. Sometimes you have a burning need for more structure, at least some of the time.
When you know a subject deeply, and your observations or analysis recur, you may be best served by filling in a form. The form will have its own metadata and its own data model.
Consider a school soccer coach. An after game report typically includes:
-
which teams played,
-
where and when,
-
officials, and
-
a list of game events
-
who scored (and when and how),
-
who received penalties (when and for what), etc.).
Wouldn't it be handy for your blogging tool to:
-
understand this structure,
-
present an editing form,
-
render the form in html to your blog, and
-
render the post (including the form) to your rss feed?
News aggregators and news readers should be able to:
-
Autodiscover an unknown schema.
-
Notify the user that a new schema is available.
-
Learn the schema, including entry forms, pick list sources, rendering guidance, and default style sheets.
-
Make it available when the blogger is ready to write.
3. Use Cases and Potential Applications
I don't want to put a cap on this. It's like saying "web pages will be used for..."
Recipes and Golf Scores:
You should be able to define your own structure. The most common use of Microsoft Excel is making lists of things. No reason blogs can't give similar freedom to define a new package. Build from scratch or on the shoulders of other package definitions. Just for diversity sake:
-
What I'm listening to now. (with enough info that a newsreader could find and play that tune, when the package comes in via RSS.)
-
Concert review. (3 points for lighting, 2 for sound, 4 for audience involvement, ...)
-
Strange things in my referral log. (A real blog)
-
Beer reviews. (A real blog)
-
Dating reports. (6 stars on manners, 9 on heat, 2 on wardrobe, ...)
Interop with enterprise applications:
So I define a "new customer bio" structure. My customer relationship management system writes RSS for me that includes new customer info. Not only can I cite that post in my blog, but:
-
my blog can notify the CRM via trackback
-
the CRM can take note of the permalink of my post (for CRM users), and
-
the CRM can append changes to data I made with my blogging tool ("He's not really the decision maker.").
Along the way...
-
information locked inside an enterprise system become visible to our intranet search engine via my blog.
-
more useful content finds its way into enterprise systems.
-
transactional data takes on context.
4. Architecture
You should be able to pass along anything. There should be sufficient wrapper of the thing so:
-
the Atom Consumer can discern if this kind of thing is understood by the Consumer,
-
the Consumer is pointed to human readable documentation about the thing's type, the better to guide users what to do with the package (Do I want to open this? Where can I get a viewer?).
-
the Consumer can look up the XML semantics, if present; the better for the Consumer to learn a new well formed structure.
-
a Consumer, if so inclined and with user permission, can retrieve the default rendering html template and style sheet for this kind of thing, and anything else that might help with editing, presentation, or storage.
-
a Consumer can look up something that might tell how to authenticate that this thing really matches the claimed mime/type.
-
a Consumer can inspect the version, build, release or mod date of this structure/thing's definition. The better to check for updates (do I need a new version of the newsML renderer?)
Packages:
-
Envelope
-
Descriptive stuff about contents (names, how many packages, etc.)
-
URL of structure definition
-
Version / Release / Modification Date of structure definition
-
Package(s)
-
URL of structure definition
Package Syndication:
-
Blogging tools should be able to wrap each structure in RSS, RDF or whatever we're using for syndication.
Package Discovery: I'm thinking we could follow the example of:
-
Little orange XML links (on pages and with rendered packages)
-
the RSS AutoDiscovery metatag form
Package Aggregation and Analysis:
-
Aggregation
-
Why should anything be different?
-
Analysis
-
We now have comparable data! I subscribe to all the local soccer RSS feeds in my league. An aggregator can show trends, averages, rankings, etc.
-
Rendering
-
Edit Form
-
Didn't Mozilla put out a protocol for defining simple UIs?
-
HTML
-
Templates?
-
RSS
-
RSS namespaces?
5. Examples
-
Sub-schemas describe activities (golfing, commuting) and reviews (movies, marijuana). You can see how this creates more comparable data (show me all the movie reviews by warbloggers rated 4 out of 5 stars). Coming soon are trend charts so you can see if you golf game is getting better or getting worse, or if you commute times are better on some days.
-
The Lafayette Project (2003 Q2?)
-
From Meg Hourihan's talk at Reboot (20 June 2003)
-
Today, you can review a book on your blog and a review on Amazon. It would be better if you could just tell Amazon about the review on your site. More distributed. It would be cool to link recipes/reviews to Epicurious and collaboratively filter that info (people who cooked this, also cooked this). You get to own your content but connect with others, retain copyright but still participate in your discussion.
6. Discussion
[PhilWolff] This extension may be out of scope per Sam's blog post
-
[KenMacLeod, RefactorOk] I think it's within scope of "Let everyone know what are essential requirements for your application", especially how it gets modeled alongside, as a ContentModule, or instead of content.
[AaronSw] I did some work on this once; I called my system a Data Management System to go with my Content Management System. I think it might be sort of out-of-scope right now, since there aren't many deployed systems, and if there were any, they'd probably be very different from the weblog software that we're aiming at.
Would these be ContentModules or WellFormedEntry extensions? It would seem these structures would be more easily expressed as extensions to the WellFormedEntry, alongside or instead of more substantial content. In the case of "instead of content", it may mean that content should be optional. In other words, the WellFormedEntry is, itself, the content.
-
[MarcCanter] We've actually worked with this idea a lot, and I agree with Phil that thinking of it as a form - is the right way to go. But, Phil glosses over details needed to make this idea fly. Alf Eaton has released his RVW spec - he uses RVW to create blam! reviews. Alf then has a reciprocal 'reviews server' that is publicly available.
[Moof, RefactorOk] It gets a bit sticky when you try to work out the difference between Data and MetaData, though. For example, if you have a Recipe blog is the cooking time Data or MetaData or both? How about whether it's sweet or savoury? I think it's fair to say that an ingredients list is semantically different to the method of cooking. Is it fair to then have to jumble it together into a less semantically rich XHTML format for content? Especially as the syndication may be going out to a recipe client which could support some standard recipe interchange format. This is the sort of thing CSS and XSL were designed for, maybe we should start using them? A standard (and probably optional) metadata tag could point towards a stylesheet that shows an XHTML display module how to display an entry. If we start allowing arbitrary media in these feeds, there's no reason to disallow an XML representation of standard form data.
[PhilWolff] There's a concern that blog components may be "the semantic web" in sheeps clothes. Perhaps. I want to assure Echo has the hooks, flexibility, and extensibility to permit new kinds of xml packaging. There are solid business reasons for adding packages to an existing syndication mechanism. Let's make sure it happens around Echo.
[AdamRice] Rumor has it (http://www.movabletype.org/news/2003_02.shtml#000783) that the upcoming Movable Type Pro will allow users to define arbitrary fields in their blogs, and a quick perusal of the MT support boards will show this is an urgently desired feature. So this might be in support of features that don't exist today, but well may before Halloween. Whether there's a need to provide recipes and soccer-match results as structured data to aggregators is one thing, and it's possible that once the feature exists in MT, nobody will use it, but if !Echo is going to provide good interop, this would be a Good Thing. It could also remove pressure to over-define the base spec with tags.
-
[PhilWolff] Glad to hear it. Just remember that what's needed are not just tags, but structures of elements.
Related was originally a simple linking mechanism. Maybe we should consider it as a simple use case of DefinedDataModel + SyntaxExtensionMechanism + ComponentBlog. Please help to refactor the issues there to better understand the issues facing the larger issue of Semantic Web Logs.
[JonathanSmith] Does the ContextSensitiveServicesFramework under development have any bearing on this or other related discussions?
-
Interesting find. I can't tell how it might apply. The metadata they use applies to books, journals, dissertations, patents, ....
[AsbjornUlsberg] This extensibility will be fairly covered with the ExtensibilityFramework, and for all common extensions to Atom, there should be provided use-cases and well-formed Profiles. Such profiles should exist for XHTML, SVG, MathML etc.
Original author: PhilWolff
CategoryArchitecture, CategoryInterop, CategoryMetadata, CategoryModel, CategoryRss, CategoryExtension