Lex Sulzer

From semantic-mediawiki.org
Jump to: navigation, search
Name  Sulzer
First name  Lex
Photo  SAM 6293 Lex Sulzer.JPG
Social links  
About me  

I understand and consider my computer systems as co-workers rather than ordinary tools. In the spirit of Take the time to go fast I am into any approach allowing me to mould creative solutions into code and keep myself free for forcefully creative development and further education. If you asked me for a single resource summing up my mind-set in this regard, it would be Demanding Software Professionalism: A Critical Management Imperative by Robert C. Martin (Uncle Bob).

Publish?  Yes
Events  SMWCon Fall 2015, SMWCon Fall 2016, SMWCon Fall 2017

Edit Icon.svgedit Attendee

Talk DescriptionEvent
Taking the first step towards a Semantic Information Retrieval System (SIRS)Taking the first step towards a Semantic Information Retrieval System (SIRS)SMWCon Fall 2017
Practical experience and derived best practices about miscellaneous topics chosen by the audienceSMWCon Fall 2016
Semantic MediaWiki Organization Pattern "Three-Ontologies-Method"SMWCon Fall 2016
SMW high availability for disaster recovery and production-data-based developmentA good setup for a Semantic MediaWiki including backups, updating and upgrades, migration and Virtual Machines. Get it running in no time and focus on content.SMWCon Fall 2016
Semantic MediaWiki real-world use cases and their underlying conceptsThis tutorial gives an overview of the central aspects and elementary use cases that make Semantic MediaWiki appear at its best.SMWCon Fall 2015
Front-end Acceptance Testing using Cucumber and CapybaraThis talk will give an introduction and demonstration of Interaction Acceptance Testing using the tools Cucumber and CapybaraSMWCon Fall 2015

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.



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.

Why user interaction automation on SMW?

Smwuia why.png

The philosophy behind Cucumber as an acceptance testing tool

Smwuia cucumber.png

How is it implemented?

Smwuia how.png

The ontology necessary for testing the implementation of the customized step definitions

These tests are planned to be integrated with the Semantic Forms codebase.

Smwuia main test object.png

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. "{{<feature_part>|<instance_identifier>}}".

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.

Smwuia test feature.png

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.

StepDefs.png StepDefsCode.png

Managing SMW access credentials

Smw-cindykate viewexampleprofile.png

smw-cindykate: a Ruby command line application for running Cucumber features against SMWs

smw-cindykate --help

Smw-cindykate --help.png

smw-cindykate cucumber --help

Smw-cindykate cucumber--help.png

smw-cindykate cucumber feature --help

Smw-cindykate cucumber feature--help.png

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.

Smw-cindykate cucumber feature run--help.png

Testing the implementation of the customized step definitions

Smw-cindykate test.png

Running a customers' user interaction playbook for visualization, testing and promotion reasons

Notice that smw-cindykate runs the Cucumber features in an Xterm.

Smw-cindykate solverra.png

Work in progress on smw-cindykate cucumber


(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.

A specific view on SMW

SMW4KM A specific view on SMW.png

My understanding of an enterprise program ontology for managing the knowledge about teaching/promoting SMW4KM

(not meant to be self-explanatory)

SMW4KM Enterprise Program Ontology.png

A simple way of managing "knowledge"

SMW4KM Atomized information.png

SMW adds semantics for factorized/structured information, i.e. knowledge

(not meant to be self-explanatory)

SMW4KM Factorized and structured information.png SMW4KM Data Input and Storage What is it It is a This.png

The power of data facets for grasping data and information as knowledge

SMW4KM Facetting.png

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)".

SMW4KM facetting et from top.jpg SMW4KM facetting et from side.png

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
    • choose title according to your corresponding page naming policy
    • decide on the object’s generic category/type and add corresponding template (“main single instance template”)
    • add fields to main single instance template except holds-template-fields (they shall be added in the next implementation iteration step)
      • include template name in field name (this facilitates text replacement jobs)
    • add (multiple) field value(s) (ideally specify delimiter)
  2. Create the main single instance template page
    • add generic category
    • add wikitext
      • use arraymap/arraymaptemplate to display multiple values
      • incorporate wisely chosen property names
        • use a verb and include template name in property names as a prefix (this facilitates text replacement jobs)
  3. Create category page
    • specify default form
  4. Create properties pages
    • specify type
  5. Create useful queries in connection with the object
    • test the queries
  6. Create form for the main single instance template (this comes after template and queries because output is the goal, while input is the means)
  7. Edit properties pages
    • add sophistication in accordance with form functionality needed
  8. …continue implementing by adding complexity iteratively

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:

Define development environments in Vagrant

CDSMW vagrantfile.png

Ansible's main playbook for deploying a standard SMW

CDSMW deploy SMW.png

The appliance and customer profiles drawn from a master SMW

CDSMW appliance profile.png CDSMW customer deploy profile.png

Ansible's main task with examples for installing and restoring SMW and injecting ontologies through a custom Ansible module

Main Ansible tasks

CDSMW maintasks.png

Ansible install SMW task

CDSMW install SMW.png

Ansible restore SMW task

CDSMW restore SMW.png

Ansible inject SMW content task using a custom module

CDSMW inject content.png

Deploy a standard SMW using Ansible

CDSMW run ansible.png