# A Manifesto "about knowledge/expertise things"
**URL:** https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103
**Category:** Domain Specific Languages
**Created:** [February 9, 2021, 10:25am UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103 "2021-02-09T10:25:49Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@ftomassetti](https://d.strumenta.community/u/ftomassetti)
#### Post date: [February 9, 2021, 10:25am UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/1 "2021-02-09T10:25:49Z")
For the last few weeks, @voelter , @sergej , and I have been working on a Manifesto that we would like to share with you and discuss at the next Virtual Meetup, this Thursday.
You can find it here:
[A Manifesto _about knowledge\_expertise things_ - Google Docs.pdf|attachment](https://d.strumenta.community/uploads/short-url/jOWvo5zMaTvkilm1mK0DNhcxQNF.pdf) (101.7 KB)
Now, why this Manifesto?
In a few words, we have been working for years building advanced DSL solutions for all sorts of clients. While those projects have been successful the ideas we have seen working so well in those projects are still largely ignored by most developers out there.
So we would like to change that. We would like to try explaining the sense of these solutions in a new way, and start a discussion with the community on this topic.
We have shared this document with a very small number of well respected members of the Language Engineering community during last week. The feedback we received has been encouraging, but it is also clear we need to do more work on it.
Some big points remain open:
- Who should we target this Manifesto to
- What format the Manifesto should take: more concise, more opinionated, more detailed, more educative
- How should we name this approach? The term DSL is too general, and we end up confusing people who think about internal DSLs or technical DSLs such as SQL. They are not what we are building
We hope that we can receive feedback from you and put together an improved version of this Manifesto
---
### Author:  [@jos.warmer](https://d.strumenta.community/u/jos.warmer)
#### Post date: [February 9, 2021, 1:14pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/2 "2021-02-09T13:14:45Z")
Why not BSL: Business Specific Languages.
---
### Author:  [@ftomassetti](https://d.strumenta.community/u/ftomassetti)
#### Post date: [February 9, 2021, 1:15pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/3 "2021-02-09T13:15:46Z")
I like this one!
And I need to add more to reach the minimum amount of characters in a post š
---
### Author:  [@Niko](https://d.strumenta.community/u/Niko)
#### Post date: [February 9, 2021, 5:50pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/4 "2021-02-09T17:50:30Z")
I could imagine this steps on SAPās toes. At least in ye olden days, they slapped ābusinessā on everything ā their version of JSP / ASP was called BSP: Business Server Pages. And yep, that meant ABAP embedded in HTML ā¦
---
### Author:  [@jos.warmer](https://d.strumenta.community/u/jos.warmer)
#### Post date: [February 9, 2021, 6:57pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/5 "2021-02-09T18:57:15Z")
I donāt mind stepping on SAPās toes, but I doubt whether they really care. We only need a tiny percentage of their succes to be quite happy :-).
---
### Author:  [@smmribeiro](https://d.strumenta.community/u/smmribeiro)
#### Post date: [February 10, 2021, 3:03pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/6 "2021-02-10T15:03:37Z")
Itāll be difficult not to have some sort of collision with some other concept/word/nameā¦ weāre all working on the same fieldā¦
Hereāre some (somewhat wild) suggestions.
Trying to replace āDomainā:
- FSL: Field Specific Languages
- SFL: Subject Field Languages
Trying to replace āSpecificā:
- SDL: Single Domain Languages
- DOL: Domain Oriented Languages
Giving some visibility to the fact that we can ācaptureā the expert knowledge
- KSL: Knowledge Specific Languages
- KOL: Knowledge Oriented Languages
- DKL: Domain Knowledge Languages
If we abandon the āstandardā TLA world, we could try to bee trendy with:
- DKOL: Domain Knowledge Oriented Languages - and saying that it should be pronounced āD-Coolā (kind of āThe Coolā).
š
---
### Author:  [@ftomassetti](https://d.strumenta.community/u/ftomassetti)
#### Post date: [February 10, 2021, 4:17pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/7 "2021-02-10T16:17:06Z")
Thank you! All of those are great suggestions!
---
### Author:  [@dumdidum](https://d.strumenta.community/u/dumdidum)
#### Post date: [February 11, 2021, 12:16pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/8 "2021-02-11T12:16:35Z")
SEE - Subject Expert Enabler
I would avoid the the term ālanguageā all together because itās way to associated with programming and the whole thing isnāt only about the languages, itās about building tools that allow experts to take their knowledge and work with it. This in almost all cases is much broader than ājustā a language but involves integration with other parts of the overall system.
---
### Author:  [@ftomassetti](https://d.strumenta.community/u/ftomassetti)
#### Post date: [February 11, 2021, 1:03pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/9 "2021-02-11T13:03:23Z")
> [@dumdidum](#):
>
> SEE - Subject Expert Enabler
See could be a nice Acronym. I agree that we could remove the term language. I also agree that it is mostly about building tools, however, some feedback we received warned about putting too much evidence on the term ātoolā, as it could be reductive and just seem an attempt to solve a problem throwing technology at it, without the underlying philosophy/methodology. I also agree that integration is key!
---
### Author:  [@jos.warmer](https://d.strumenta.community/u/jos.warmer)
#### Post date: [February 11, 2021, 2:24pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/10 "2021-02-11T14:24:36Z")
Reading the manifesto, I am not sure who the audience is, and without knowing that, there is no way to write the right text. Assuming that we want to target the business, I would go for a much more business oriented way of describing the various points. To explain what that would mean for this manifesto, attached is an example of how it could be rephrased.
[Support Business Agility by enabling subject matter experts to capture knowledge.pdf](https://d.strumenta.community/uploads/short-url/tNro6Y9jPe45DqvVSdWXBVlvbv9.pdf) (10.0 KB)
---
### Author:  [@jos.warmer](https://d.strumenta.community/u/jos.warmer)
#### Post date: [February 11, 2021, 2:33pm UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/11 "2021-02-11T14:33:50Z")
The style of writing under **Elaborations** for several parts starts out rather defensive: _is this contradicting agile?_, _Will this drive developers and subject matter experts apart?"_. This way the reader starts out with a negative sentiment, maybe it might work better to rephrase this in a more positive way without going (too much) into the defensive. I donāt have examples of this rephrasing, it sounds easier than it is š.
---
### Author:  [@ftomassetti](https://d.strumenta.community/u/ftomassetti)
#### Post date: [February 12, 2021, 8:21am UTC](https://d.strumenta.community/t/a-manifesto-about-knowledge-expertise-things/1103/12 "2021-02-12T08:21:38Z")
Very interesting discussion yesterday!
Thank you to all the participants, to all those who shared ideas here, or by email.
It is great to see how some ideas resonate with many of you.
The feedback has been very useful. We had a good share of positive feedback and constructive criticism š
I think we clarified a few points:
- In short, if experts such rich knowledge, we want to enable those experts to define software products
- We agreed that this Manifesto is targeted at **Subject Matter Experts** , not at technical people. We would expect those in the tranches, who experience the limitations of current approaches, to be the primary recipients of this Manifesto, and then secondarily to reach the other non-technical people, up to the CEO level. While technical people could more easily get it, they are not the primary target of the Manifesto
- The Manifesto is about solutions that address the **core domain of expertise** of a company. While in any not tiny organization there are different types of expertise, there is frequently one that is a core asset for the company, impacting what the company offers. This approach focuses only on supporting those ācore domainsā. For example, a company producing medical applications could also have an IT security expert or a marketing expert. The approach we are proposing would ignore that ancillary expertise and focus exclusively on serving the medical expertise
- This is **NOT** about a specific tool. While many today build these solutions using JetBrains MPS, the principles are more general. 10 or 20 years from now we may use other tools and the principles would still be valid. One could build these solutions using ANTLR, Xtext, ProjectIt, MPS, or other technical means. Also, the reverse is true: one could use MPS to build solutions that have nothing to do with the kind of solutions we want to promote in this Manifesto
- We want to avoid referring to specific implementation techniques or means because those could change over time and because they could alienate our target (non-technical people). So we will not use terms such as MDE, DSL, Model, Language, Editor, Programming
- We want also to avoid terms which are too vague such as _Knowledge_
- The theme āFreedom from ITā and āConfigurable platformā came up
- We discussed the fact we want to offer better comunication, possibility to simulate, automate, and configurability. But there are other approaches making the same claims, so we should be more specific
- We discussed _Business_ vs _Domain_, we may want to avoid _Business_ as it can be see in connection to money more than business logic
- Some connections we make, could not necessarily be the same connections our target recipients would make. For example, if we talk about _expertise_, some of us could think about _expert systems_, but our target could have no idea about that term
- The term _Enable_ and _Empower_ came up, as good ways to indicate what we do
- We liked the idea of putting the experts in control, and discussed the metaphor of driving, being at the wheel, steering
- We discussed the idea of co-creation involving experts and developers
- We discussed the image of providing appropriate tools to experts, like architects could not do their work without CAD, so experts need their own tool
- Some names proposed āDomain Specific Toolsā, āExperts productivity Toolsā