MoC Glossar

Definitions of terminology we use in the MoC Project

- document model
- equality model
- scala
- MoC graph
- Semantic Diff
- Change impact analysis (CIA)
- propagation

MoC – a list of possible tasks

Possible prototypes within the MoC Project

- Eclipse plugin with extended workspace (incl. documents) to create interaction graphs via drag & drop
- Eclipse plugin for a semantic diff
- Graph visualization a la thinkbase – dynamic brousing of documents
- Word plugin to add annotation and links to other documents
- structural and semantic Word Graph extractor
- DB-Diff that triggers changes between table versions and different schemes
- Excel Diff based on equality models

MoC Meeting – Notes vom 26.07.2011

Anbei eine Zusammenfassung von unserem Meeting. Freue mich auf unser nächsten Treffen!

## Was sind die Bausteine des MoC Systems?

Momentan sehen wir 3 Komponenten
- MoC Kernel: stellt Änderungsbeschreibung zur Verfügung
- Lenses/Views: visualisieren diese Änderungsbeschreibungen (Eclipse Plugin fürs Diff, Webseite mit interaktiven Graphen)
- Dokumenten Modelle: liefern die Abhängigkeiten, Berechnungsinformationen, Definition von Graphen an den MoC Kernel

Dokumenten Modelle
- sind hybride Dokumentendefinitionen (über Dokumentenkollektionen)
- teilweise lassen die sich berechnen
- teilweise müssen wir sie manuell identifizieren
– mithilfe von Web2.0 Technologien: Empfehlungen, Taggen, Annotationen
– in Form von Dokumentenmarkup (Tags in XML einfügen und dann parsen/extrahieren)
– in Form von speziellen Java Annotationen für Markup im Code

Social Media
- zum Anreichern von Änderungsinformationen (twitter, Blogs zur informellen Beschreibung einer Änderungsbegründung)
- zum Externalisierung von Knowhow aus den Köpfen von e.g. Mitarbeitern in das MoC System (was hängt wie warum zusammen)
- Social Medial Inhalte bieten eine alternative Darstellung von Verkettungen, Abhängigkeiten
- Reputationssysteme (Punktesysteme) um Mehrwert zu schaffen

## Wie kann ich an MoC mitwirken?
MoC ziehen wir als Open Source Projekt auf. Für uns ist es am wichtigsten, dass jeder Spass dabei hat. Es gibt ganz viele Baustellen. Wir definieren unsere Arbeitspakete aus unterschiedlichen Perspektiven:

Komponenten-bezogen
- Kernel
- Dokumentenspezifisch (Word, Excel, HTML)
- Applikationsspezifisch (Eclipse, Web)

Themen-bezogen
- Formale Methoden, Type Theory, Category Theory (für diff, cia, …)
- Visualisierung, Darstellung
- personalisierte Sichten
- Extraktion (z.B. von Markup-Information)
- Spezifikation von Änderungs-/Berechnungsinformationen, Markup, Graph-Repräsentation
- Suche entlang des Graphen/ Filtern von relevanten Informationen
- Analyse, Auswertung, Voraussagen
- Infrastruktur für unsere Zusammenarbeit definieren/implementieren
- Architektur des MoC Systems definieren

Technologie-bezogen
- GIT, Darcs
- Scala, Java
- PHP/jQuery
- Flash
- …

Ideen für MoC Umsetzung sammeln
- GIT, Darcs Theorie verstehen
- …

Anwendungsfälle:
- Kostenanalyse (Gozintograph);
- Konsistenzprüfung (syntaktisch als auch semantisch) von kontextsensitiven Grammatiken, insbesondere hinsichtlich Einheiten (h, EUR, …)
- Mindmap (see Thinkpedia) mit Suche/Browsen

Going live Issues
- PR für MoC in Blog etc
- MoC erfolgreich in einem Unternehmen einsetzen (Was sind Prozess-bezogene, organisatorische, technologisch, People Issues?)
- …

## Wie gehen wir vor?
- regelmässige Meetings, weil wir woll’n vorwärts kommen
- Vision immer und immer wieder diskutieren
- Anwendungsfälle sammeln
- Prototypen bauen und erklären
- Mehr Leute dafür begeistern
- Feedback sammeln (Barcamp)
- MoC irgendwann mal wo einsetzen/ einführen

## Bis zum nächsten Meeting
- GIT aufsetzen (open)
- GIT Theorie (Normen)
- Neues Diff (Normen)
- Booble-Generator Pfeile (Roland)
- Eclipse Plugin “Hello World” (Dani)
- Scala Workspace aufsetzen: Howto schreiben (Tine)
- Extraktor (Tine)

Wer Lust hat bei MoC mitzumachen, einfach via twitter kontaktieren @normenmueller oder @chtinemueller.

MoC Dependency Manager

Worum geht es: Erstellen von Dependance Graphs innerhalb von Eclipse
- Eclipse plugin
- Ausweiten des Eclipse Workspace auf Dokumenten-Kollektionen
- Feingranulare Anzeige von Artefakten (siehe Eclipse Outline/ Package Ansicht)
- Drag&Drop zum setzen der Abhängigkeiten zwischen z.B. Code und Anforderungsdokumenten

Feingranulare Anzeige
- kl. Scala Tool: Simples Word Dokument in (vorerst) strukturellen Graph parsen (Erweiterung der GrGen Graph-Repräsentation um ein Modulsystem: Normen’s phd)
- Visualisierung des Graphen
- Interaktion mit dem Graph: Doppelklick auf Knoten um verlinktes Word-Fragment zu öffnen
- Interaktionsgraphen definieren (Abhängigkeiten zwischen Artefakten unterschiedlichen Typs)
- Integration mit diff – scalaxx

Würde man das verwenden wollen?

MoC: Bedenken

Eine der ersten Diskussion zwischen Roland, Normen und mir beschäftigte sich generelle Bedenken bezüglich MoC. Hier ein paar Notizen.

- MoC sollte Arbeitsprozesse nur bei Bedarf ändern und sich sonst der Umgebung anpassen.
- MoC wird nicht als neue, kompakte Applikation entwickelt sondern integriert sich in bestehende Infrastrukturen und Workflows. (Alternativ hätten wir uns für ein Plugin in Jazz, EA oder Requisite Pro entscheiden können.)
- Es kann hilfreich sein vor der Einführung von MoC bestehende Prozesse/Infrastrukturen zu optimieren oder Verhaltensweisen anzupassen. Zum Beispiel könnte man
– die Menge an Dokumentation reduzieren
– Duplikate/Redundanz verringern (z.B. durch “Single Source” Paradigma)
– kleine, häufiger Commits vornehmen (wobei Inkonsistenten einen Commit nicht verhindern dürfen)
- Werden Nutzer wirklich ausreichend viele und gute Annotationen bereitstellen. Wie geht man mit Inkonsistenten um?

MoC – Bottom up or Top down

Roland, Normen und ich haben vor das MoC Thema sowohl bottom-up als auch top-down anzugehen.

top-down umfasst die MoC Theorie und erlaubt eine Gesamtsicht auf die MoC Vision. Dazu gehören auch …
- Business Use Cases
- Anwendungsgebiete (e.g. ne Online Zeitung)
- Fragen wie “Was wollen wir?” “Was interessiert uns?” “Was brauchen wir?” “Was wird man später mal anwenden?” “Was sind typische Anwendungsfälle?” “Welche Prototypen könnte man bauen?” “Welche (open source) System können wir dazu nutzen?” “Wer macht sonst noch so MoC (oder so)?” “Was wollen wir als erster entwickeln/verstehen?”
- Komponenten des MoC Systems
- Gesamtarchitektur (zentraler MoC Kernel)

bottom-up heisst einfach mal loszulegen und dadurch Intuitionen zu MoC zu sammeln. Dazu gehören auch …
- der Bobble-Geneator
- locutor
- ein Excel Diff z.B. basierend auf poi.apache.org
- Eclipse/ Word plugins
- panta rhei

Intuitionen können wir auch bei Kollegen sammeln
- thinkpedia or thinkbase by Christian Hirsch

MoC Vision

Normen, Roland and I just launched MoC as open source project. Finally, I have found some time to sketch the vision of our joined efforts.

Social media is all around us nowadays. I just created my Google+ account and two circle for scala and social media. I already found most people that I also follow on Twitter in these areas. For me these tools are a valuable source of information in the first place: Following the scala people on Twitter has provided me with many great blog posts, papers, slides — their tweets and posts provide me with a notion of which information on the web is relevant in that area. Their activities provide me with triggers on latest news — on what has changed. They relieve me from collecting information, from having to cope with management of change (moc) on my own. And this is where the MoC Vision starts.

But before we get there a few more thoughts on research papers. Research is great and allows you to make so many helpful assumptions. One assumption that both, Normen and I, made in our work was to simply assume that users will provide us with all the data we need to do these fancy computations. For Normens work, this is a complex multi-dimensional graph, where nodes correspond to units of informations (infoms) and edges denote the typed dependencies between these notes. Given the graph, locutor can do all these nice semantic differencing (diff), change impact analysis (cia), propagation and (semi) automatic adjustments. But where do we get this graph from in the first place?

Wouldn’t it be nice if we could apply social media activities (some of us are already used to in private and professional life) in order to create a moc graph from documents? Providing us with interlinked snippets of code, requirements documents, test cases, … and their interrelations. Allowing us to easily search, filter nodes and edges to provide different views (aka lenses). And then, at some point, providing the basis for Normen’s smart mod computations?

So what Roland, Normen and I have in mind is a two fold tool. A Web Frontend that allows users to create a graph (see Roland’s posts) and a backend that takes a graph and provides services like diff, cia, propagation.

The frontend should be
- social
- easy to use, intuitive
- adaptable (e.g. in terms of colors, layout)
- accessable (html5 + jquery rather than java or flash)

It should allow users to
- create, label and type nodes
- create, label and type edges
- load/safe a graph
- query for service provide by the backend

The backend should be
- performant
- secure
- reliable
and compute
- difference to previous versions of the graph
- filter the graph and the differencing (lenses, equality model)
- compute impact of changes along the edges of the graph
- propagate changes …

Well, still very abstract. But we will get more concrete as we go along. So please don’t yet blame me.

Intelligent Book Project

Christoph Lange pointed me to the intelligent book project (see also blogspot or the official website), I wished I had known about during my PhD. William H. Billingsley PhD thesis from 2007 provides some information on this project. (He is now working at NICTA in Australia.)

According to this site the main idea is a collaborative authoring approach (original author and readers): “most of an intelligent book is dynamically constructed and accumulated through conversations with its readers”. The main idea (the subject matter) is provided by the author, readers can enrich it with examples, their discussion or references to other supplementary materials.

In particular the content model in Billingsley’s thesis relate to my proposal of enriching document content with variants in order to provide dynamics (or flexibility, adaptability if you wish) and with this the foundation for an adaptation service.

TopicMap Approach

Christo Dichev introduced me to a former project in his group. It seems related to my paper. In his group, they applied the concept of TopicMaps, which basically models all subject in the real world as topics in the computer world and associates these topics via various relations (like part-of, is-a/type-of, illustrates, describes/defines) etc. The group has looked at a course on Java programming and created topics for each narrative component in the course: Chapter nodes are link via the “part-of” relation to their segments. They furthermore added “type-of” relations to associate further topics in the course, e.g., a “class variable” and an “instance variable” are both “type-of” the topic variable. Further relations where explored, e.g., exemplifying topics where added to the topics. The basic idea here is that users navigate through a topic structure. The topics have a number of links (called occurrences) to content. So in contrast to my work (or the Dita approach, in general) in the context of Christo’s work a topic is not an atomic snippet of content. It is rather a term or category that corresponds to something we talk about and which can be link to various occurrences of contents (e.g., wiki pages, blog entries etc).

Christo sees the challenges of his approach in making a system attractive for the users. For him right now, tags seem to be a much better approach since they do not force the user to select from a specific structure but give full flexibility in the classification of a text’s core ideas.

It will be interesting to look at the TopicMap approach and to use it as a different perspective when explaining/describing my approach.

SmartBook Project

At S3T I came across a quite interesting project (SmartBook), possibly related to my work. The motivation is to enrich the experience when reading e-books. In collaboration with the Ontotext company, the Sofia University is interested in exploring how authors can be supported in semantically annotating their books. Users can import any kind of document, from informal text up to XML. The document is processed within the KIM-System, which implements a data mining approach designed by Ontotext. Eventually, the output is a document in which some keywords (or list of keywords) have been associated with the system’s ontology. This ontology is called the global knowledge base, while the annotation of the document are called local knowledge base: each document has such a local knowledge base. This knowledge base can be enriched with manual annotations by the users — users also have the opportunity to add their definitions of concepts that have been automatically identified. Optionally, users can publish their annotations (their ontological concepts) to the central knowledge base and thus make it available to the outside world. I still have to fully understand how the content is stored, the only thing I know is that a Lucine database is used and that everything seem to be kept in memory only.

The project has several interesting services in mind. After the initial prototypes have been implemented, it will be interesting to see what features are of interest to the project members. I see high potential for collaborations here!