User:Lex

= Home =

Inter alia I studied information management in Zurich, Madrid, London and Havana.

I currently focus on:


 * developing and managing Ansible Playbooks for deploying and restoring virtual machines for purposeful SMW applications
 * automatically testing constellations of the MediaWiki core in cooperation with sets of dedicated extensions for compatibility
 * engineering ontologies for SMW by defining all terminological elements like categories, templates, properties, forms, concepts, modules, query templates, etc.
 * developing and testing SMW user interfaces optimized for the context at hand
 * developing and managing general and specific help articles and best practices for setting up, using and administering SMW for usecases covering the user groups of users, designers and administrators
 * developing and managing SMW tools for data migration, ontology comparisons, comprehensive text replacement, ontology injections, Cucumber-based forms interaction for demonstration and testing purposes as well as concrete visualizations of ontologies (terminological and assertive) using GraphViz
 * integrating SMW as active and passive micro services
 * operating SMW: data quality management, experienced-based optimization of forms systems, full backup loop monitoring (scheduled and ad-hoc) by comparing recent changes, and supporting all SMW users at our customer sites

I run the company dataspects GmbH in Zurich, Switzerland. You can contact me at lex at dataspects dot com.

Addressing comprehensive aspects on Semantic Web in general and SMW in particular I operate https://smw-cindykate.com as my knowledge repository.

Regards

Lex

= SMW User Interaction Automation =

This is the protocol of the talk I held at SMWCon Fall 2015 on user interaction automation (SMWUIA).

SMWUIA is implemented as a command of my broader SMW toolset called "smw-cindykate". As explained below there remains work in progress for a release candidate.

The ontology necessary for testing the implementation of the customized step definitions
These tests are planned to be integrated with the Semantic Forms codebase.



The test feature file which specifies the Gherkin steps to be run
The final test feature file is compiled from feature parts which are split into groups of interaction elements in order to facilitate testing all elements in randomly combined instantiations of single and multiple instance templates.

Note that these feature parts are not stored on SMW pages, but at smw-cindykate/feature_parts/. The feature parts can be included in feature files in the same way as templates are included in SMW, i.e. "".

Upon compiling, the final test feature file is (re)placed as smw-cindykate/features/smwuia_test.feature.

This file is executable documentation as it also serves as a catalogue of SMWUIA's user interaction DSL.



The customized step definitions
Due to


 * 1) the select2 implementation of many of the more complex form inputs (e.g. tree, tokens, combobox, etc.) as well as
 * 2) the highly probable occurrence of ambiguity on the global DOM level (which can only be resolved by introducing implicit scopes/contexts or to-be-avoided explicit wrappers)

Capybara's built-in selectors are not sufficient.

That's why smw-cindykate contains many custom step definitions used for mapping the Gherkin steps. These make heavy use of Capybara's and Jquery's xpath (and Jquery's native) selecting and execute_script capabilities.



smw-cindykate cucumber feature run --help
smw-cindykate cucumber will contain options for optimizing the user interaction automation for


 * 1) user interaction testing,
 * 2) general and customer-specific SMW promotion,
 * 3) feature debugging as well as
 * 4) educational uses.



Running a customers' user interaction playbook for visualization, testing and promotion reasons
Notice that smw-cindykate runs the Cucumber features in an Xterm.



Work in progress on smw-cindykate cucumber


= Teaching and Promoting SMW =

(SMW4KM = Semantic MediaWiki for Knowledge Management)

This is some very rudimentary background material of the workshop I held at SMWCon Fall 2015 on Semantic MediaWiki real-world use cases and their underlying concepts. An introductory blog post (currently only in German) can be found at Wissensmanagement: Fliegen wurde erst erfolgreich, als man aufhörte, Vögel zu imitieren.

My understanding of an enterprise program ontology for managing the knowledge about teaching/promoting SMW4KM
(not meant to be self-explanatory)



SMW adds semantics for factorized/structured information, i.e. knowledge
(not meant to be self-explanatory)



An example
In spite of the fact that both facets depict the same object, notice that when looking at the left one your brain needs to go through several "parsing loops" deriving the object from clues. When looking at the right facet however, you instantly recognize the object. This is the reasoning behind what I call the KM Principle "Quick concept recognition (QCR)".

A rudimentary suggestion for the KM Practice Pattern "Test-driven ontology engineering on SMW"

 * 1) Create an object instance as a page in main namespace
 * 2) * choose title according to your corresponding page naming policy
 * 3) * decide on the object’s generic category/type and add corresponding template (“main single instance template”)
 * 4) * add fields to main single instance template except holds-template-fields (they shall be added in the next implementation iteration step)
 * 5) ** include template name in field name (this facilitates text replacement jobs)
 * 6) * add (multiple) field value(s) (ideally specify delimiter)
 * 7) Create the main single instance template page
 * 8) * add generic category
 * 9) * add wikitext
 * 10) ** use arraymap/arraymaptemplate to display multiple values
 * 11) ** incorporate wisely chosen property names
 * 12) *** use a verb and include template name in property names as a prefix (this facilitates text replacement jobs)
 * 13) Create category page
 * 14) * specify default form
 * 15) Create properties pages
 * 16) * specify type
 * 17) Create useful queries in connection with the object
 * 18) * test the queries
 * 19) Create form for the main single instance template (this comes after template and queries because output is the goal, while input is the means)
 * 20) Edit properties pages
 * 21) * add sophistication in accordance with form functionality needed
 * 22) &hellip;continue implementing by adding complexity iteratively

= SMW Deployment using Vagrant/Ansible/Cucumber =

Note: Please understand this as a brief presentation of "SMW through Ansible". A general Ansible SMW role is still under construction as the one I'm currently using is heavily dependent on our individual infrastructure.

Vagrant | Ansible | Cucumber

The purpose of this approach is to mould your carefully crafted SMW setup into easy-to-maintain idempotent computer-executable declarations which allow you to:


 * 1) test and develop "everything SMW" on development environments which are born at the stroke of a key and are identical to production environments "by DNA"
 * 2) deploy entire production environments to plain vanilla Linux machines with a single-line command
 * 3) test backups through CI servers allowing end-to-end comparisons (if you accept comparing recent changes as sufficient proof)
 * 4) easily provide customized prototype and sandbox environments for sales pitching
 * 5) define your environments on a layer-by-layer basis, each one being agnostic of the one above

Here are some exemplary screenshots:

ConferenceManagementOntology
Category:ConferenceManagementOntology

AspectCodesTagCloud DEV

 * Module:AspectCodesTagCloud
 * Module:AspectCodesTagCloudDEV

(Manage)

 * Manage ConferenceContributions
 * Manage AspectCodes
 * Manage AspectCodesGroups

Behind the curtain

 * Ontologies

Contributors
__SHOWFACTBOX__