So is this OpenEvents?

Greetings from sunny San Diego.  Morning after posting Google/Internet Archive, Meet Mr. Event we threw the kids in the WRX and headed south for some R&R with friends and family.  So now that I've snuck into the local wifi cafe I'm very gratified to discover more people, projects, and conversations about this events vision.   For sake of clarity, from now on I think I'll start using Marc Canter's OpenEvents moniker -- seems like the same/right philosophy, and appears to still be a green-field project.

Here are just a few additional links I've found related to OpenEvents vision, although I haven't had time to fully dig through all this yet:

• EventsML, an IPTC effort for an XML vocab standard for, "event publishing, event planning, and event coverage."



• ESS  the "Event Share Specification" for, "assisting in the publishing and distribution of event (e.g. meetings,
  conferences, holidays) information."



• WhizSpark's broader thoughts on social networking and events



• CivicSpace are some veterans of the Dean campaign building a, "...platform that empowers collective action inside
  communities and cohesively connects remote groups of supporters."



• Who What When Where XML is headed up by Hanan Cohen, who believes, "people should be able to publish where and when they will be, and
  others should be able do discover those facts and arrange to meet them."

Among many others!  I haven't yet digested the comments/trackbacks/new info, but clearly people are looking and addressing events from many different angles and biz models. And it's all "just software," so it's doable.  Hard part is herding cats, aligning interests so collaboration, real work, and follow-through happen.

Still getting my mind around all this, but I'm looking forward to continuing to connect with interested and engaged parties.  But my main event right now is quality time with family until the new year, so I think I'll idle my mind and keyboard until '05.  Have a great holiday if you're still reading this!

Google/Internet Archive, Meet Mr. Event

In the spirit of "tags are the new black," here's a vision for how event and calendar management should be handled by 2006:  Wouldn't it be grand if all events in the world, from a garage sale in Lexington to a tech conference in SF, could be automatically discovered (Google), stored in one central, public domain, web services accessible database (Internet Archive), where the events could then be categorized (Topix), community rated and recommended (Amazon/Netflix/Last.FM), personally tagged (Flickr/del.icio.us), and ultimately custom-fed (PubSub) directly to your calendar device of choice (Calconnect)?

Cool, where do I sign up? I Could have used this to promote our now defunct SF Web Services SIG, which was done "by hand," one site/email list at a time.  Not to mention the relative difficulty when you go searching for a good event in your area...(not to knock workit.com or craigslist.org -- thanks guys!)  But I want this uber event service now!

So past and current pains combined with threads followed, dots connected, and small wheels turned since last week's Berkeley Calendar Project post create this mashup event service vision.  Actually, people are talking about this vision in so many words.  Dr. Bob Glushko and Allison Bloodworth et al are leading part of the effort by trying to bring sanity and sharing to the 80+ event calendars of UC Berkeley.  Tantek Çelik and other folks working on hCalendar talk about using your web site as your API,

"...bloggers can discuss events in their blog(s) in such a way that spiders
and other aggregators can retrieve such events, automatically convert
them to iCalendar, and use them in any iCalendar application or service.",

Kevin Hughs at zLab writes,

"The potential for applications that make use of networked, time-driven information is
huge. Today's portals have no concept of event personalization or collaboration.
Today's applications have only the most basic concept of integrating with or subscribing
to time-driven data. And there are no providers of horizontal event-based services. ... Software and
the Internet has freed online music from its proprietary data and application jails, why
not do the same with events? The traditional calendar interface deserves a overhaul.",

Marc Canter chimes in,

"I wonder if they wanna help put up shared XML servers of Events - scraped from throughout the web?",

the Calconnect.org folks proclaim,

"Our members’ intent is to enable calendaring and scheduling tools and applications to enter the mainstream of computing," said Dave Thewlis. "After email, the World Wide Web, and instant messaging, calendaring and scheduling capabilities are what business people and consumers will really care about.",

and many many others I have yet to discover [add more in comments].  Yes, A few people are already doing similar stuff, like upcoming.org, rsscalendar.com, openeventscom, whizspark.com, evdb.com(?), and most likely Google Labs (?) [any more?].  But for starters, from what I can glean these efforts rely on people coming and manually submitting events, rather than auto-discovery and aggregation via spidering --> problem of db critical mass.

So let's make one!  Let's combine something practical and "standards-based" (ie., iCalendar/XHTML) like hCalendar, but extend it with the rich UBL-inspired semantics of a Berkeley Event Model.  Now that everyone agrees, let's move one.  We need open source tools so event producers (even for my yard sale) can list their events on their blogs/web sites, like they already do, but also be sure to use valid markup.  (Note: people are motiviated to promote their events -- no prodding necessary)  Then we need an open source spider, a bunch of disks and some linux boxes, a REST API, open source recommendation and reputation/rating/tagging engines (eg., tweaked openscrobbler + ??/??/??), and some pub-sub and feed generators.  And to top it off, let's make the database and service usable by all (eg., some kind of creative commons), so we can unleash the creativity of the world to build custom interfaces via our web services API.  Easy stuff in these days of inspiration from  Amazon/Google/PayPal/eBay/SForce, open source, wikis, bugzilla, and PayPal donate buttons.  Right?

The law of ideas says that at least 6 (or is it 8?) people are either building or have already built this exact event service -- and I haven't found it yet.  Any pointers?  If not, anyone want to build this monster?

CalConnect.org Consortium Tackles Calendar Sharing

[Update to Calendar Federation and Syndication at UC Berkeley post]  From Brian Dear comes word of Calconnect.org, a new consortium to promote IETF's calendar sharing standards.  From the press release:

"This isn’t simply about calendar programs," noted Patricia Egen, Interop manager and member of the Board of Directors, who originated the idea of the Consortium. "This is about seamlessly connecting your calendar with others so that your professional and personal life runs more smoothly."

Infoworld notes, "members of the consortium include Duke
University, MIT, Stanford University, the University of Washington, the
University of Wisconsin-Madison and the University of California,
Berkeley. The group also includes NASA's Jet Propulsion Laboratory, the
Mozilla Foundation, the Open Source Application Foundation and IT
vendors Oracle Corp., Novell Inc., Meeting Maker Inc., Symbian Ltd. and
Yahoo Inc."  No Microsoft or IBM...

I applaud this effort and know the consortium has comprehensive and important goals, but there's still a burning question in my mind: given their stated 3-5 year time frame, what kind of ad-hoc, bottom-up, microformat (eg., hCalendar) type "standard" might emerge?  I guess we'll just wait and see... (eg., EVDB)

Video Blogging for Grandmas and the Workplace

From Stuart Henshall I discovered Userplane's free AV Blogger service:

"Userplane's Audio & Video Blogger service is an easy-to-use
system allowing the creation of audio and video recorded messages for
use in blogs, websites and email.

The Userplane AV Recorder
application will automatically detect your camera and microphone, and
allow you to record up to a 10 minute recording. Each recording is
streamed from the Userplane servers, and can be copy-and-pasted into
your web media."

AV Blogger (and apparently others like videoaddon.com) seem to have lowered the bar to capture, store, and broadcast video using common tools and copy/paste code snippets for websites (and their wiki and blog nephews!).  This is a serious boon for distributed teams, grandparents (see Belen's picture blog), eBay sellers, and everyone in between.  (Uh oh, I'm envisioning a thousand talking heads bobbing through the blogosphere...  Maybe we ought to stick to text! ;)

[UPDATE:] Marc Canter points to me-tv (blog), a browser-based feed reader for video in the spirit of podcasting.  This appears targeted for those creating/hosting their own video files, unlike the AV Recorder service, which takes care of everything for you (you just need a webcam).

   

blogazul, a Twist on the Semantic Wiki

I had the pleasure of meeting Jean Sini yesterday.  He's behind a new project called blogazul, which in its current state is an integrated weblog/wiki system similar to SocialText and SnipSnap.  The interesting twist is what Jean is calling a "semantic wiki," but with a different interpretation of Semantic from Platypus Wiki or discussions elsewhere.  Blogazul is leveraging XML Schema instead of RDF.  From blogazul.com:

"The idea is quite simple: while we maintained the “edit-in-place”
principle that makes wiki so easy to use, we added a whole new
dimension: a wiki page can now be structured in XML. And instead of
typing that XML directly, or viewing it in raw form, it is presented,
both for reading and editing, through style-sheets. The goal: you focus
on the content only, and you get the structure, the rich layout, and
the automated functionality derived from the fact that the data types
of the content are known. Just like smart tags, the semantic wiki style
sheets, based on the fact that there is an address in your page,
exposes automated features like yellow pages, driving directions, maps,
etc."

This is an interesting architecture that follows a more formal model-based approach to programming a wiki, which I talked about previously in my Big Red Button post.  Definitely similar in spirit to what JotSpot, Twiki, and XWiki are doing RE: creating application platforms on a wiki base, but instead of user-friendly scripting or programming wiki objects, XML Schemas and XSLT drive the action.

Accounting for Lunch with JiffyBill.com

It's the age old "problem" amongst frequent mealtime friends: splittin' the bill.  The folks at Orbeon used PayPal standalone, but talked about a better way all the time over lunch.  It's finally here: JiffyBill.com. (by way of Judith Meskill)  They layer a nice bill splitting/presentment layer on top of PayPal.  From their Why JiffyBill? section:

Have you ever gone to lunch with a group of friends or co-workers but did not have the correct change to settle the bill?  Often in such situations one person will offer to pay the entire bill, and the others can pay them back later.  Sometimes a person will "forget" to pay and it is easy to lose track of the debts the longer they go unpaid.
      

Or perhaps you are a professional looking for a simple, low-cost way to bill your clients. Billing software can be expensive and difficult to setup and maintain.  And such packages  typically do not facilitate communication with the client.
      

JiffyBill.com is here to help!  We make it easy to record a bill, including all of the items or services and who should pay for each.  We even auto divide tip and taxes for you, if applicable.  The bill is then sent via email to each of the responsible parties, who may view it, add comments, and record payments.
      

      
      
      
      

Tool Tips for Entrepreneurs (or "that's soooo 2004...")

By way of Steve Shu I found Paul Allen's (of Infobase Ventures) nice little cheat sheet for entrepreneurs.  These are really Paul's proxies to ensure entrepreneurs seeking his ear have put some basics in place before contacting him.  But yes in general, they're excellent tips, and he encourages the use of some great new(ish) services.  I excerpt my favorite 4 here:

• You must be using LinkedIn.com
  and have at least 10 connections and 2 endorsements. That way there
  is a good chance that I will know someone who knows you. It will be
  easier for us to gain mutual trust this way.



• You must have an advisory board of 3 or more successful
  business people (preferably 6-10) who believe in you and are willing
  to meet with you monthly or bi-monthly to dispense advice and help you
  with your challenges.



• If your company is at revenue stage, you must be using Quickbooks Online Edition
  so that I can review your financials with you as needed. This costs
  only $19.95 per month and gives 3 users access to your data. I need to
  see the real picture and not just hear about the big ideas.



• If you do have publicly traded competitors, you must have a My Yahoo portfolio listing all their stock symbols, so you can stay current with their news and financial status.

Read them all!

Calendar Federation and Syndication at UC Berkeley

Jon Udell and others are having a discussion about the sorry state of calendar sharing, both standards activities and clients/platforms (see also Ted Leung and previously Lisa Williams).  The particular discussion is centering around Mozilla and Chandler and how to use WebDAV/CalDAV as a transport for calendar sharing.  But at the end of his first post, Jon writes:

"I wish there were a middle ground between this model and the dedicated
calendar server. Imagine a WebDAV implementation that could map
collections not just to whole-file resources, but to XML elements
within files. Given an XML flavor of the iCalendar format, you could
achieve more finely-granular control over calendar data. But the same
model would work for other applications using other XML formats. And
you'd have the option of searching with XPath or XQuery, again
leveraging infrastructure not bound to any application domain."

He summarizes nicely some of the goals of the Berkeley Campus-Wide Event Calendaring Project, headed up by Allison Bloodworth and others from Berkeley and the CDE.  The project was motivated by the fact that there are something like 75 different calendars at Berkeley, and there's no way to easily share events or create user-friendly views or feeds.  (BTW their work just won the best presentation/paper award at XML 2004 -- kudos!) 

So their focus is to apply Document Engineering techniques to create the XML data model that accomplishes Jon's wishes, and then apply model-based app techniques using XML/XSLT/XSD to create software and glueware to manipulate those events (eg., create calendars).  Borrowing from their XML 2004 presentation, they summarize their solution:

• A standard XML data model of an Event (Scott says: think UBL for events) http://dream.berkeley.edu/EventCalendar/Events.xsd



• A centralized repository of Event information



• A calendar management tool



• Manage events in the repository



• Customize a visually compelling, dynamic web-based calendar



• A design for a system architecture allowing XML feeds to and from the repository for calendars who choose to maintain their own website & repository

They have the XSD schemas and have some software built.  This is important related work if you're interested in calendar sharing and syndication -- check it out.

[UPDATE:] From Adam Rifkin's excellent Microformats post I found hCalendar:

"hCalendar is a 1:1 mapping of iCalendar to semantic XHTML. ...bloggers often discuss events on their blogs -- upcoming events, writeups of past events, etc. With just a tad bit of structure, bloggers can discuss events in their blog(s) in such a way that spiders and other aggregators can retrieve such events, automatically convert them to iCalendar, and use them in any iCalendar application or service."

This Microformat philosphy is pragmatic == I like!.

BzzAgent and Word of Mouth Marketing: Ripe for Open Source?

Fascinating recent NY Times article "The Hidden (In Plain Sight) Persuaders". Read this one with awe and a hint of unplaced fear.  BzzAgent and a few other firms "hire" small armies of every day folks to stealthily promote products to their friends in casual conversation. Fascinating because while these people are hired (or more correctly "admitted") to become BzzAgents, they don't do it for $$. Instead the program taps in to people's inner needs to "belong to something bigger," be the "first kid on the block to know about XYZ," and maybe even as a form of therapy:

"In essence, they told Balter that there was nothing wrong with the
rewards; it was just that the rewards weren't really the point. Even
now, only about a quarter of the agents collect rewards, and hardly any
take all they have earned." and,

"What, I asked her, if not the potential to get some free prizes for
effort, made her bother to volunteer with BzzAgent? First, she told me,
she gets the chance to sample new products shortly before they hit the
stores, so she gets to feel a bit like an insider. Second, she has
always liked to give people her opinion about what she's reading or
what products she's using, and BzzAgent gives her more to talk about.
Third, if she does like something, then telling other people is helpful
to them. So participating is both a chance to weigh in and be heard,
and also something close to an act of altruism."

and a woman speaking about her husband's involvement as a BzzAgent,

"She said she thought it had made him more open to other people. He used
to be the kind of guy who just hated to call a mechanic about a noise
the car was making; he would wait until the car actually broke down and
he had no choice but to bother someone about it. He was in a shell. But
that has changed..."

Nothing wrong with those motivations. Sounds like much of what drives open source software. And apparently the program works like gangbusters for BzzAgent's clients. But for how long?  It's probably just another immunity people will erect to deal with marketing overload (see also Marqui's use of paid bloggers), but this one could prove a hard strain to resist.  Lots of good discussion and commentary going on at Hugh Macleod's post around these issues.

So what's the problem, other than worrying about being duped by a BzzAgent, and adjusting to yet another marketing channel?  From the same post, Hugh offers one opinion,

"Jack, I'm not dissing BzzAgents because I think it's "wrong" or
"immoral". If people want to squander their social capital on pimping
supermarket-level products, fine. It's their life. I think BzzAgents is a "crap" idea simply because it doesn't solve
the client's fundamental problem i.e. nobody sincerely wants to talk
about their product."

But it apparently does solve this fundamental problem of kick starting chatter for BzzAgent clients, even if we're uncomfortable with it. So until we're immune or 60 Minutes outs the program, after which BzzAgents run the risk of becoming social pariah's when discovered, it will continue to be a viable sink for marketing dollars.

But there is a kernel of a wholesome, everyone-can-get-behind idea here. An "Open Source BzzAgent" approach comes to mind, where people honestly excited about products can get hooked up with other such folks for laughs and rewards (eg., I'd sign up to somehow formalize or benefit from my tireless Flickr invitation habit). This would have to be very grass roots and bottom up/decentralized, but sounds doable with enough free time and experimentation. This idea and/or project has to be out there already -- I'll hunt around and report back.

Browser-Based Application Architectures

Oliver Steele of Laszlo Systems recently posted a good history of various browser-based application architectures.  Most interesting is his definition of "client-side web applications" in contrast with Model 2 (or Model 2X) and other evolutions he calls Model3 and 4:

"In a client-side web application, a single web page (or its application equivalent) is downloaded.  This application can generate a sequence of views on the client.  Sometimes the client application requests a new dataset — typically in XML, or a protocol (RPC, SOAP) that is serialized to XML — but this dataset is read into the client application; it doesn’t replace it."

While a good definition and fine architecture, Oliver is making client-side web applications sound newer than they are.  Wasn't this the whole idea behind Java Applets?  Granted the first applets didn't have all the architectural pieces right (eg., port 80 issues and server architecture needed to be home grown), but many people who committed to applets in the late 90's ended up exactly as Oliver mentions.  At Inovie our entire TeamCenter product was a judicious mix of java applets (Swing -- gag!) and HTML, all done as HTTP over port 80.  For portions of the app that really benefited from a rich interface, a single applet was loaded, and as new views were requested, the applet communicated with the server to get new data. Great post, just adding some additional context.