Semantic Time Travelling - Tagging and branching knowledge with SMW (a vision)
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?
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Semantic Time Travelling - Tagging and branching knowledge with SMW (a vision)
Similar to Semantic Time Travelling - Tagging and branching knowledge with SMW (a vision) (20)
Recently uploaded
Recently uploaded (20)
Semantic Time Travelling - Tagging and branching knowledge with SMW (a vision)
- 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
- 9. Per-page Revisions with Approved Revs 9
- 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