Skip to main content

Emergent Language for Data Entry

Combine a wiki with code assist, templates, syntax checking, relational technology, a query language, semantic mapping and Google Suggest. What do you get?

An emergent language, that's what. A domain specific data entry language uniquely tailored to the information at hand through continued use and extension. The IDE features in the background are there to help in achieving consistency, but the user entering the data is really free to just enter it. This is the point. Make it easy to enter data and assist in making it valuable, ie. mineable. When it's hard or awkward to enter data, nobody enters it.

In the background, the system constantly analyzes existing data entries for commonalities to be exploited as structural information. These are then used in code assist proposals to further their consistent use. Code assist could also offer templates for common constructs.

Key elements to recognize in the data would be traditional relational concepts: attributes and associates. In particular, bidirectional associations with defined role names.

With this information, it is possible to implement sophisticated queries against the data store, even bringing relational technology to bear for large data stores.

The structural information could also be associated with semantic concepts (manually or maybe partially automatic). This in turn would enable the mapping of local semantics to more global semantic frameworks and thus, global queries across multiple WikiBases.

Given the performance of Google Suggest and auto-complete in Google Mail, it seems reasonable that a WikiBase client could be implemented in the browser so the basic user experience would be the same as for traditional wikis.

Comments

Popular posts from this blog

Threaded chat article and demo

While nothing major, managing threaded conversations in chat has bothered me for quite a while. Yesterday I had an idea on how to improve matters: Works using existing chat infrastructure. Needs only augmented clients. Plays well even if other party uses a non-thread aware chat tool. Separates threads automatically based on interaction patterns. I've written an article and have created an online demo about it. Discussion welcome.

Access 2003 and the DCOM Server Process Launcher

Here's a hint: Don't disable the "DCOM Server Process Launcher" service on XP SP2. It may look like one heck of a vulnerability when you really don't use DCOM at all, but, unfortunately, Microsoft Access 2003 does. It will simply open an instant message box stating "A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX Control." if the service is not running.

Beyond TDD: Documentation Driven Development

There are quite a few articles extolling the virtues of test-driven development these days ( here's one ). And for good reason, too. Having done TDD for quite a while, I recently started combining it with documentation-driven design. This is what my open-source tool, JCite , is all about. With this approach, I sketch out the most important use cases, combine them into the index of a tutorial (links plus teasers summarizing the use-case), flesh out the tutorial topics (and thus use-cases) one by one, develop the use-case tests in parallel to each topic, cite the important parts of the tests as actual code samples into the topic, and only then start doing the implementation (this last step is accompanied by more tests, which are now more like unit-tests). In all, this is like literate programming, but of the use-case tests rather than the implementation code. TDD already helps to make you focus on the user during API design. DDD takes the effect further by making you tell consistent ...