Gorka Puente

From WikiPapers
Jump to: navigation, search

Gorka Puente is an author from Spain.

Tools

Tool Description
Wiki Scaffolding Language
WikiWhirl


Publications

Only those publications related to wikis are shown here.
Title Keyword(s) Published in Language DateThis property is a special property in this wiki. Abstract R C
Harvesting models from web 2.0 databases Data re-engineering
Databases
Harvesting
Model-driven engineering
Web2.0
Software and Systems Modeling English 2013 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. 0 0
Refactoring affordances in corporate wikis: a case for the use of mind maps Affordance
Corporate wikis
FreeMind
MediaWiki
Mind map
Refactoring
Enterprise Information Systems English 2013 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. 0 0
Wikipedia Customization through Web Augmentation Techniques Web Augmentation
Wiki
DSL
WikiSym English August 2012 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 wikipedian’s 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. 0 0
Wiki Scaffolding: Aligning wikis with the corporate strategy DSL
FreeMind
Mind map
Wiki
Wiki management
Information Systems English 2012 Wikis are main exponents of collaborative development by user communities. This community may be created around the wiki itself (e.g., community of contributors in Wikipedia) or already exist (e.g., company employees in corporate wikis). In the latter case, the wiki is not created in a vacuum but as part of the information ecosystem of the hosting organization. As any other Information System resource, wiki success highly depends on the interplay of technology, work practice and the organization. Thus, wiki contributions should be framed along the concerns already in use in the hosting organization in terms of glossaries, schedules, policies, organigrams and the like. The question is then, how can corporate strategies permeate wiki construction while preserving wiki openness and accessibility? We advocate for the use of "Wiki Scaffoldings", i.e., a wiki installation that is provided at the onset to mimic these corporate concerns: categories, users, templates, articles initialized with boilerplate text, are all introduced in the wiki before any contribution is made. To retain wikis' friendliness and engage layman participation, we propose scaffoldings to be described as mind maps. Mind maps are next "exported" as wiki installations. We show the feasibility of the approach introducing a Wiki Scaffolding Language (WSL). WSL is realized as a plugin for FreeMind, a popular tool for mind mapping. Finally, we validate the expressiveness of WSL in four case studies. WSL is available for download. © 2012 Elsevier Ltd. All rights reserved. 0 0
Wiki refactoring as mind map reshaping DSL
End-user
Mind maps
Refactoring
Wiki
Lecture Notes in Computer Science English 2012 Wikis' organic growth inevitably leads to wiki degradation and the need for regular wiki refactoring. So far, wiki refactoring is a manual, time-consuming and error-prone activity. We strive to ease wiki refactoring by using mind maps as a graphical representation of the wiki structure, and mind map manipulations as a way to express refactoring. This paper (i) defines the semantics of common refactoring operations based on Wikipedia best practices, (ii) advocates for the use of mind maps as a visualization of wikis for refactoring, and (iii) introduces a DSL for wiki refactoring built on top of FreeMind, a mind mapping tool. Thus, wikis are depicted as FreeMind maps, and map manipulations are interpreted as refactoring operations over the wiki. The rationales for the use of a DSL are based not only on reliability grounds but also on facilitating end-user participation. 0 0
WikiLayer: Annotation for Wikipedia Annotation
Personal knowledge management
Wikipedia
WikiSym 2012 English 2012 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. 0 0
WikiWhirl: Wiki refactoring made easy DSL
End-user
Mind maps
Refactoring
Wiki
WikiSym 2012 English 2012 Wikis' organic growth inevitably leads to wiki degradation and the need for regular wiki refactoring. So far, wiki refactoring is a manual, time-consuming and error-prone activity since refactoring is conducted at the same level that editing: the article. This results in no performant wikis and the frequent abandon of wiki projects. We argue that refactoring requires a broader view of the wiki structure, where the impact of splitting, moving or merging extends beyond a single article. This demo shows WikiWhirl, a tool that visualizes and manipulates wikis via mind maps. Built on top of FreeMind, WikiWhirl (i) imports a wiki from MediaWiki, (ii) displays its structure as a mind map, (iii) supports refactoring operators as mind map node manipulation, and finally, (iv) saves those changes back to the wiki ensuring authorship and readership. 0 0
Model-aware Wiki Analysis Tools: the Case of HistoryFlow WikiSym English 2010 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. 8 0
Model-aware wiki analysis tools: The case of HistoryFlow Analysis tools
Collaboration
Information visualization
Interoperability
MDE
Model-driven
Visualisation
Web 2.0
Wiki
WikiSym 2010 English 2010 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. 0 0