Semantic MediaWiki is a natural fit for many knowledge management needs. It enables communities to collaborate on a growing and evolving body of knowledge. This is a Good Thing, but at the same time poses some interesting questions - especially in an enterprise setting. Many organizations have quite strict procedures for approving certain 'versions' of the body of knowledge. In our architecture consultancy, for instance, we frequently encounter the situation that an architecture board formally and periodically determines the contents of a new version of the architecture. Even though there are several extensions (such as ApprovedRevs and FlaggedRevs, Semantic History or Semantic Watchlist) that support this kind of approval cycle to a certain extent, this support only goes so far. There is an interesting analogy to be drawn with the way code development works. Here, too, we see communities (of developers) that contribute to a shared body of knowledge (the code base). And unlike the knowledge management community, the coding community has several proven tools to manage the release of new versions. Most serious development efforts are supported by version control systems such as Git, Subversion and CVS. When a new version of the software is released, the code is 'tagged' so that the state of the code base at the time of release can always be reproduced. The code base can also be 'branched out' to maintain earlier releases or to try out new ideas without disturbing progress of the main development. This is what we need for knowledge too! In this talk, I would like to explore with the audience the possibilities to 'travel through time' in Semantic MediaWiki, borrowing concepts and ideas from version control systems. What does it mean to 'tag' and 'branch' knowledge? What are the use cases? And what would it take to implement this in SMW?

1. Semantic Time Travelling
Tagging and branching knowledge with
SMW (a vision)
Dr. Remco de Boer
CTO @ XL&Knowledge
rdeboer@xl-knowledge.com
Consultant @ ArchiXL
rdeboer@archixl.nl
SMWCon Fall 2013
Tuesday, October 29th 2013
Berlin, Germany

2. About us…
• ArchiXL
–
–
–
–
Independent Dutch Consultancy specialised in Enterprise Architecture (EA)
Located in Amersfoort
Customers mainly public sector
Started using SMW internally for EA repository
• XL&Knowledge (“Excellent knowledge”)
– Knowledge management label for ArchiXL
– Knowledge management world is much larger than only EA
– SMW as knowledge management platform
2

3. SMW in Enterprise Architecture
3

4. A typical (many-stakeholder) architecture process
Formal decision
Public consultation
Steering
committee
Advice on decision
Advisory
board
Prepare architectural
decisions
Public
Architect
Expert peers
4

5. We sometimes encounter some tension between ‘the
new world’ and ‘the old world’
Wiki
Documents
•
•
•
Ease of use (browse, query)
Engages other stakeholders
Live knowledge base; ‘always’ up to
date
•
•
•
Formal status (approval)
Editing procedures (architecture
board)
‘Release management’
Feels intangible
•
Feels tangible
•

6. Version management in SMW – what do we have?
• Page history
– Show individual revisions
• Approved Revs
– Distinguish approved revision from latest revision
• Semantic History
– ‘Semantify’ edit history
• Semantic Watchlist
– Monitor changes in semantic properties
• Versioning in the knowledge model
– Add semantic properties to store version-related information
6

7. Page History:
Per-page Revisions in (Semantic) MediaWiki
7

8. Approved Revs
8

9. Per-page Revisions with Approved Revs
9

10. Semantic History
10

11. Semantic Watchlist
11

12. Versioning in (architecture) knowledge models
• ‘Version’ attribute
– Increase with each new (major) version of an architectural knowledge entity
(i.e., design decision, model element, etc.)
• ‘State’ attribute
– Model life cycle of an architectural knowledge entity (e.g., tentative, decided,
approved, obsolete)
• Multiple elements
– Each version is a first class entity in its own right
12

13. Why isn’t this enough?
• At a single point in time, we may be interested in several manifestations of
the same entity:
– Historic (v1, v2, v2.1, v3, …)
– Actual (‘live’)
– Future (plateaus, gap analysis, what-if scenarios)
• A [historic/actual/future] version of an architectural knowledge entity is only
meaningful in the context of all other entities at the same time.
• IST (baseline) vs. SOLL (target) architecture
– (mostly) the same elements in a different configuration
13

14. Version management in SMW – what do we need?
Back to the Future (IMDb, http://www.imdb.com)
14

15. Question – Who recognizes this?
Cool, that’s exactly what I
need! Wonder if it works
with the version of SF I
have installed…
15

16. What if…
Suppose we could travel through our wiki to a certain point in time
To a specific date / time
OR
to a particular event
Back to the Future (IMDb, http://www.imdb.com)
16

17. Examples of things we could do…
•
•
•
•
Show the documentation for a particular release of a piece of software
Display the contents of the wiki as they were on December 31, 2012
Show one of the formally approved versions of an architecture
Switch between different stages of architectural knowledge in an EA
repository
NB. This wouldn´t apply to just a single page,
• ...
but to the wiki as a whole. This means that for
instance SMW-queries would return results
that are consistent with the selected point in
time.
Think for a minute about what this could mean for your practice.
Share your ideas!
17

18. A useful analogy:
Software Revision Control
• Goal: Tracking and controlling changes in software
– Versioning
– Multi-site teamwork
– Examples: CVS, Subversion, Git
• Useful concepts:
–
–
–
–
Trunk
Tag
Branch
Merge / diff
18

19. Tagging Knowledge in SMW
• Take a ‘snapshot’ of the wiki
• Label page revisions that represent coherent sets of knowledge with logical
names
• NB. A tag applies to the state of all knowledge in the SMW repository on a
certain branch at a certain point in time
• Example use cases for architectural knowledge:
– Produce versions of the architecture, e.g., for approval or reference purposes
– Have different views for different stakeholders (historic, current, future)
19

20. Branching Knowledge in SMW
• (Temporarily) branch off new and/or changing knowledge
• NB. Branches may also contain tagged revisions
• Example use cases for architectural knowledge:
– Separate target future states (plateaus) from current state
– Allow independent development of parts of the architectural knowledge base
– Work out what-if scenarios / tentative decisions + implications; perform tradeoff analyses
20

21. Merging Knowledge in SMW
• Determine the difference between two branches and incorporate changes
from one branch into another
• Example use cases for architectural knowledge:
– Integrate (approved) revisions from separate branches into a coherent set of
architectural knowledge
– Support architecture evolution (integrate plateaus)
21

22. A glimpse into the future?
22

23. A glimpse into the future?
23

24. •
Back to the Future
(IMDb)
How do we get there?
What do we need?
Start small
– Focus on tags and timestamps
– Important design decision: how do you indicate which tag / timestamp you want to see?
•
Build on what we have
– E.g. logic from ApprovedRevs to return the right semantics
•
Store historical property data
– This might have some implications. What about db size? Caching?
•
SMW Core or SMW Extension?
– {{#ask: [[Category:Thingies]] |?Foo=Bar | timestamp=2013-07-09 }}
– {{#ask: [[Category:Thingies]] |?Foo=Bar | tag=version1 }}
•
First next step: collect potential use cases and prepare an RFC?
I’d like to see this happen. And you?
24

25. 25