The First Lornet Meeting will be held at the Université du Québec à Montréal November 18-19, 2004. The meeting is part of the NSERC-funded network of canadian researchers working on Learning Objects and has a strong Semantic Web flavor. Among other things, the first SWIG (Canadian Semantic Web Interest Group) meeting will be held as part of the Lornet meeting on November 19th 2004 (Friday afternoon).

All are invited and the fees appear reasonable.

Interesting post by Sean McGrath (not the inDiscover’s Sean McGrath, the Propylon’s Sean McGrath) on how Gmail (Google Mail) was designed. For those who don’t know Gmail is a revolutionary Web mail service à la Hotmail, a step beyond anything else I had ever seen. He explains that Gmail is thin client running thanks to javascript (and not Java!!!).

This bring him to raise an interesting question. Why doesn’t Gmail sends XML back and forth? Indeed, isn’t XML the data format of the Web? Here’s what he has to say:

Web clients carry around a basic, low level programming language called Javascript. The real beauty of Javascript is that it is dynamic - you can blurr the distinction between code and data. You can hoist the level of abstraction you work with in your app by layering domain specific concepts on top of it in the form of functions and data structures. You can sling across data structures already teed up for use on the other end with the aid of the magic of “eval”. You can implement complex behaviour by sending across a program to be run rather than trying to explain what you want done declaratively to the other side.

Now, in such a world - would you send XML data to and from? Developers with a static typing programming language background might be inclined to say yes but I suspect javascriptophiles, lispers, pythoneers and rubyites are more likely to say no. Reason being, it is so much more natural to exchange lumps of code - mere text strings remember - that can be eval’ed to re-create the data structure you have in the XML.

I think he is very much on target in the sense that people who see everything as Java or C# are likely to perceive XML very much differently from people using higher level languages.

The lesson here people is that you should master a range of languages and not one or two. And no, taking a class in Haskell once in your life doesn’t qualify.

Tim Bray who invented XML among other things, takes a stand against Web Services. Here’s what he says:

No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.

I look at Google and Amazon and EBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I can’t help noticing that they don’t seem to need much WS-apparatus.

I’m deeply suspicious of “standards” built by committees in advance of industry experience, and I’m deeply suspicious of Microsoft and IBM, and I’m deeply suspicious of multiple layers of abstraction that try to get between me and the messages full of angle-bracketed text that I push around to get work done.

It should be noted that Tim has recently taken a job with Sun Microsystems. His current employer is very actively involved in Web Services, so I believe he takes this stand despite the current interest of his employer.

Seb sent me this extract of a book. The extract is called So, you want to do a Ph.D.? As usual with this sort of book, it is delightful.

Here’s a fun quote:

One thing which is seldom mentioned is what happens to you after you finish the PhD. A classic story is as follows. A student focuses clearly, submits the thesis and starts looking for a lecturing job, only to discover that they need two years of lecturing experience and preferably a journal publication as well if they are to be appointable for a job in a good department in their field. If they had known this two years previously, they could have started doing some part-time lecturing and submitted a paper or two to a journal.

I haven’t read the entire book, of course, and I’m somewhat worried that the book might not be sufficiently focused on why one does a Ph.D. and might be a tad too cynical. Learning the rules is very nice and very important, and I wished I had learned them when it was time. However, there is also the issue of figuring out whether these rules make sense, and knowing when to break them. Well, I guess that learning the rules to begin with is a very good start.

Nicolas Lecomte started his own blog: L’apprentissage: dimensions individuelles et sociales. Nicolas is a student of my colleague Richard Hotte. He is currently interested in the usage of blogs in education.

Here’s a link to slides from a talk by Roger Magoulas, (O’Reilly Media, Inc.) about building the open warehouse. The talk was presented at O’Reilly Open Source Convention 2004.

Commodity hardware, faster disks, and open source software now make building a data warehouse more of a resource and design issue than a cost issue for many organizations. Now a robust analysis infrastructure can be built on an open source platform with no performance or functional compromises.

This talk will cover a proven analysis architecture, the open source tool options for each architecture component, the basics of dimensional modeling, and a few tricks of the trade.

Why open source? Aside from the cost savings, open source lets you leverage what your staff already knows — tools like Perl, SQL and Apache — rather than having to procure and staff for the proprietary tools that dominate the commercial space.

Data Warehouse Architecture: - Consolidated Data Store (CDS)
- Process to condition, correlate and transform data
- Multi-topic data marts
- dimensional models
- Multi-channel data access

Open Source Components
Database: MySQL
- fast, effective
Data Movement: Perl/DBI/SQL
- flexible data access
Data Access: Perl/Apache/SQL
- template toolkit for ad hoc SQL
- Perl hash for crosstabs/pivot
- Perl for reports

Dimensional Model
- organizes data for queries and navigation from detail to summary
- normalized fact table for quantitative data
- denormalized dimensions with descriptive data
- conforming dimensions available to multiple facts

Performance Considerations
- configuration
- indexing
- SQL-92 joins
- aggregate tables and aggregate navigation

The presentation should provide you with the basic architecture, toolkit, design principles, and strategy for building an effective open source data warehouse.