Gorka Puente

Harvesting models from web 2.0 databases

Data rather than functionality are the sources of competitive advantage for Web2.0 applications such as wikis, blogs and social networking websites. This valuable information might need to be capitalized by third-party applications or be subject to migration or data analysis. Model-Driven Engineering (MDE) can be used for these purposes. However, MDE first requires obtaining models from the wiki/blog/website database (a.k.a. model harvesting). This can be achieved through SQL scripts embedded in a program. However, this approach leads to laborious code that exposes the iterations and table joins that serve to build the model. By contrast, a Domain-Specific Language (DSL) can hide these “how” concerns, leaving the designer to focus on the “what”, i.e. the mapping of database schemas to model classes. This paper introduces Schemol, a DSL tailored for extracting models out of databases which considers Web2.0 specifics. Web2.0 applications are often built on top of general frameworks (a.k.a. engines) that set the database schema (e.g., MediaWiki, Blojsom). Hence, table names offer little help in automating the extraction process. In addition, Web2.0 data tend to be annotated. User-provided data (e.g., wiki articles, blog entries) might contain semantic markups which provide helpful hints for model extraction. Unfortunately, these data end up being stored as opaque strings. Therefore, there exists a considerable conceptual gap between the source database and the target metamodel. Schemol offers extractive functions and view-like mechanisms to confront these issues. Examples using Blojsom as the blog engine are available for download.

Model-aware Wiki analysis tools: the case of HistoryFlow

Wikis are becoming mainstream. Studies confirm how wikis are finding their way into organizations. This paper focuses on requirements for analysis tools for corporate wikis. Corporate wikis differ from their grow-up counterparts such as Wikipedia. First, they tend to be much smaller. Second, they require analysis to be customized for their own domains. So far, most analysis tools focus on large wikis where handling efficiently large bulks of data is paramount. This tends to make analysis tools access directly the wiki database. This binds the tool to the wiki engine, hence, jeopardizing customizability and interoperability. However, corporate wikis are not so big while customizability is a desirable feature. This change in requirements advocates for analysis tools to be decoupled from the underlying wiki engines. Our approach argues for characterizing analysis tools in terms of their abstract analysis model (e.g. a graph model, a contributor model). How this analysis model is then map into wiki-implementation terms is left to the wiki administrator. The administrator, as the domain expert, can better assess which is the right terms/granularity to conduct the analysis. This accounts for suitability and interoperability gains. The approach is borne out for HistoryFlow, an IBM tool for visualizing evolving wiki pages and the interactions of multiple wiki authors.

Refactoring affordances in corporate wikis: a case for the use of mind maps

The organisation of corporate wikis tends to deteriorate as time goes by. Rearranging categories, structuring articles and even moving sections among articles are cumbersome tasks in current wiki engines. This discourages the layman. But, it is the layman who writes the articles, knows the wiki content and detects refactoring opportunities. Our goal is to improve the refactoring affordances of current wiki engines by providing an alternative front-end tuned to refactoring. This is achieved by (1) surfacing the structure of the wiki corpus as a mind map, and (2) conducting refactoring as mind map reshaping. To this end, we introduce WikiWhirl, a domain-specific language for wiki refactoring. WikiWhirl is supported as an extension of FreeMind, a popular mind mapping tool. In this way, refactoring operations are intuitively conducted as actions upon mind map nodes. In a refactoring session a user imports the wiki structure as a FreeMind map; next, conducts the refactoring operations on the map, and finally, the effects are saved in the wiki database. The operational semantics of the WikiWhirl operations follow refactoring good practices (e.g., authorship preservation). Results from a controlled experiment suggest that WikiWhirl outperforms MediaWiki in three main affordance enablers: understandability, productivity and fulfillment of refactoring good practices.

Wikipedia customization through web augmentation techniques

Wikipedia is a successful example of collaborative knowledge construction. This can be synergistically complemented with personal knowledge construction whereby individuals are supported in their sharing, experimenting and building of information in a more private setting, without the scrutiny of the whole community. Ideally, both approaches should be seamlessly integrated so that wikipedians can easily transit from the public sphere to the private sphere, and vice versa. To this end, we introduce WikiLayer, a plugin for Wikipedia that permits wikipedians locally supplement Wikipedia articles with their own content (i.e. a layer). Layering additional content is achieved locally by seamlessly interspersing Wikipedia content with custom content. WikiLayer is driven by three main wiki principles: affordability (i.e., if you know how to edit articles, you know how to layer), organic growth (i.e., layers evolve in synchrony with the underlying articles) and shareability (i.e., layers can be shared in confidence through the wikipedians social network, e.g., Facebook). The paper provides motivating scenarios for readers, contributors and editors. WikiLayer is available for download at http://webaugmentation.org/wikilayer.xpi.

WikiLayer: annotation for Wikipedia

Reading Wikipedia is the entry to more involved activities such as editing. However, the jump from reading to editing could be too big for some wikipedians who can be intimidated by exposing their content to public scrutiny. Annotating might foster not only reading but also be the prelude to editing. Different annotation tools exist for the Web (e.g., Diigo, A.nnotate). Being a Web application, Wikipedia can benefit from these tools. However, general-purpose annotation tools do not make annotation a natural gesture within Wikipedia. That is, annotation editing, rendering or retrieval in e.g. Diigo is dissociated from the edition, rendering or location of articles in Wikipedia, hindering the role of annotation as the prelude to article edition. WikiLayer is a Wikipedia-specific annotation tool. The implications include: (1) wikinotes (i.e. annotations on Wikipedia articles) might be WikiText formatted; (2) wikinote rendering is seamlessly integrated within the Wikipedia front-end; (3) wikinote editing, management and sharing is achieved without leaving Wikipedia (no separated annotation repository). WikiLayer is available for Firefox and Chrome.