Signed in as:
filler@godaddy.com
Research & Standards
Grounded in established knowledge, not invented terminology
The principles behind good knowledge management, architecture, provenance, security and semantic representation have developed over decades.
Acta Laurel therefore does not treat every new AI or data trend as a new discipline. Where established research, standards or specifications already exist, we use them.
Where Acta Laurel makes its own architectural decisions, we say so clearly.
Research gives us foundations. Standards give us shared rules. Architecture turns both into something practical.
How We Use Evidence
Detail your services
Not every source has the same purpose.
Acta Laurel separates architectural authority into three categories.
RESEARCH ──► concepts & principles
│
STANDARDS ──► technical consistency
│
ACTA LAUREL ARCHITECTURE ──► practical implementation
Peer-reviewed research
We use academic research to understand established concepts, terminology and theoretical foundations.
Formal standards and specifications
We use standards where interoperability, architecture description, provenance or technical behaviour needs to be defined consistently.
Acta Laurel design decisions
Some decisions are necessarily architectural choices.
A research paper does not tell an organisation exactly how to structure a repository, name a folder or separate one client from another.
Those decisions belong to the architecture.
Why This Distinction Matters
Many technology concepts become confusing because research, industry terminology and product marketing are mixed together. A vendor may use a recognised term in a very specific way. A consultancy may introduce its own model. A research community may use the same term differently.
Our approach is simple:
Do not present an architectural preference as scientific fact.
If a concept comes from research, we reference the research. If behaviour comes from a standard, we reference the standard.
If Acta Laurel designed it, we identify it as an Acta Laurel architectural decision.
This makes the architecture easier to challenge, improve and trust.
Knowledge Management
Knowledge architecture starts with Knowledge Management.
One of the most influential foundations for our approach is the work of Maryam Alavi and Dorothy Leidner.
Their research describes four fundamental Knowledge Management processes:
KNOWLEDGE CREATION ──► STORAGE & RETRIEVAL ──► TRANSFER ──► APPLICATION
│
└──────────► creates new knowledge
This is important because knowledge management is not simply about storing documents.
Knowledge has to be created, preserved, transferred and ultimately applied.
Key reference
Alavi, M. & Leidner, D.E. (2001).
Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues.
MIS Quarterly, 25(1).
DOI: 10.2307/3250961
Tacit and Explicit Knowledge
Detail your services
Not everything an organisation knows can be stored in a system. People carry experience, intuition, judgement and skills that are difficult to fully express. This is commonly discussed through the distinction between tacit and explicit knowledge.
HUMAN EXPERIENCE ── articulation ──►EXPLICIT KNOWLEDGE ──► DOCUMENTED &
MANAGEABLE KNOWLEDGE
The Knowledge Lake therefore does not claim to store all human knowledge.
It manages explicit representations of knowledge that people and organisations choose to preserve.
Key reference
Nonaka, I. (1994).
A Dynamic Theory of Organizational Knowledge Creation.
Organization Science, 5(1).
DOI: 10.1287/orsc.5.1.14
Knowledge Lake
Detail your services
The term Knowledge Lake has academic prior art. It was not created by Acta Laurel.
Beheshti and colleagues introduced the Knowledge Lake as a contextualised extension of the Data Lake, combining data with additional context and knowledge-oriented capabilities.
Their work included areas such as:
- contextualisation;
- curation;
- indexing;
- querying;
- provenance;
- security.
Acta Laurel builds on that concept but gives it a particular architectural focus. Our specialisation centres on portable explicit knowledge and the source artefacts from which that knowledge derives.
Key reference
Beheshti, S.-M.-R., Benatallah, B., Nouri, R. & Tabebordbar, A. (2018).
CoreKG: a Knowledge Lake Service.
Proceedings of the VLDB Endowment, 11(12).
DOI: 10.14778/3229863.3236230
Reference Architecture
Acta Laurel describes its work as a Reference Architecture deliberately. A Reference Architecture provides a reusable architectural foundation for a class of systems. It is not the final architecture for every organisation.
Instead:
REFERENCE ARCHITECTURE
│
├────────► Organisation A
│
├────────► Organisation B
│
└────────► Engagement C
The common principles remain stable while each implementation adapts to its own requirements.
This supports the Acta Laurel approach of having a small common core with Personal, Enterprise and Engagement profiles.
Key reference
Angelov, S., Trienekens, J.J.M. & Grefen, P. (2012).
A framework for analysis and design of software reference architectures.
Information and Software Technology, 54(4).
DOI: 10.1016/j.infsof.2011.11.009
Architecture Description
Detail your services
Architecture should be described from the perspective of the people and systems that care about it.
Acta Laurel therefore aligns its architecture work with the concepts established in:
ISO/IEC/IEEE 42010:2022
The standard provides recognised terminology around:
- architectures;
- architecture descriptions;
- stakeholders;
- concerns;
- viewpoints;
views.
This gives us a stronger foundation than inventing our own meaning for words such as architecture, view or stakeholder.
Knowledge Warehouse
Detail your services
The term Knowledge Warehouse also has a research history.
It should not simply mean:
"the good documents in the Knowledge Lake"
Nemati and colleagues described a Knowledge Warehouse as an architecture integrating Knowledge Management with ideas from Data Warehousing, Decision Support and Artificial Intelligence.
Acta Laurel therefore treats the Knowledge Warehouse as the enterprise capability layer through which organisational knowledge is captured, organised, retrieved, shared and applied.
Key reference
Nemati, H.R., Steiger, D.M., Iyer, L.S. & Herschel, R.T. (2002).
Knowledge warehouse: an architectural integration of knowledge management, decision support, artificial intelligence and data warehousing.
Decision Support Systems, 33(2).
DOI: 10.1016/S0167-9236(01)00141-5
Knowledge Graph
Detail your services
Knowledge Graphs provide a way to represent entities, concepts and their relationships explicitly.
They become useful when an organisation needs to answer questions involving connections rather than only documents.
For example:
PERSON ──►TEAM ── owns ──► SYSTEM ── supports ──►CAPABILITY
Acta Laurel distinguishes a simple Concept Link Graph from a richer Knowledge Graph.
A mature Knowledge Graph may introduce stable identity, typed relationships, schemas, provenance, constraints and semantic models.
Key reference
Hogan, A. et al. (2021).
Knowledge Graphs.
ACM Computing Surveys, 54(4).
DOI: 10.1145/3447772
Vocabulary and Ontology
Detail your services
Terminology matters. But not every list of business terms should be called an ontology.
Acta Laurel starts with the simplest useful structure. A controlled vocabulary can define things such as:
- recognised concept types;
- tags;
- relationship names;
- organisational terminology.
Formal ontology becomes appropriate only when richer semantic modelling is actually required. This distinction is supported by established knowledge-engineering literature.
Key references
Gruber, T.R. (1993).
A translation approach to portable ontology specifications.
Knowledge Acquisition, 5(2).
DOI: 10.1006/knac.1993.1008
Studer, R., Benjamins, V.R. & Fensel, D. (1998).
Knowledge engineering: Principles and methods.
Data & Knowledge Engineering, 25.
DOI: 10.1016/S0169-023X(97)00056-6
Concept Identity and Labels
Detail your services
Names are useful for people.
They are not always reliable identifiers.
Two policies may have the same title.
Two people may have the same name.
One system may change its name while still being the same system.
Knowledge architecture therefore needs to distinguish:
what something is
from:
what we currently call it
Work around semantic knowledge organisation, including SKOS, reinforces this distinction between concepts and labels.
Key reference
Baker, T. et al. (2013).
Key choices in the design of Simple Knowledge Organization System (SKOS).
Journal of Web Semantics, 20.
DOI: 10.1016/j.websem.2013.05.001
Provenance
Knowing something is useful. Knowing where it came from is often more important.
Acta Laurel uses two levels of provenance.
Basic provenance
A Knowledge Concept can identify the source material from which it derives.
Rich provenance
More complex environments may also need to capture:
- which activity produced something;
- who or what performed the activity;
- which earlier information was used;
- how one artefact was derived from another.
For this richer model, we use the concepts established by W3C PROV. W3C PROV models provenance using three central ideas:
Entities
Activities
Agents
This provides a recognised model for lineage beyond simple document references.
Open Knowledge Format
Portable knowledge needs a practical representation.
Acta Laurel currently uses the Open Knowledge Format — OKF as its primary representation approach for portable Knowledge Concepts and Knowledge Bundles.
OKF is deliberately lightweight.
It uses human-readable content and structured metadata rather than requiring a specialised platform simply to understand the knowledge.
Important concepts include:
- Concept;
- Concept ID;
- Knowledge Bundle;
- Source;
- provenance;
- actor;
- trust information;
- lifecycle status.
Acta Laurel adopts these terms rather than redefining them unnecessarily.
This supports a core architectural principle:
Knowledge should remain understandable outside the application currently displaying it.
Security and Least Privilege
Detail your services
Security labels alone do not secure information. A file containing:
classification: confidential
is not protected merely because the metadata says so.
Authorisation must be enforced by the system that stores or distributes the knowledge.
This may involve:
- identity management;
- filesystem permissions;
- repository access controls;
- cloud IAM;
- encryption;
- separate environments.
The architecture is also influenced by the long-established security principle of least privilege: access should be limited to what is needed to perform the required function.
Key reference
Saltzer, J.H. & Schroeder, M.D. (1975).
The Protection of Information in Computer Systems.
Proceedings of the IEEE, 63(9).
DOI: 10.1109/PROC.1975.9939
What Comes From Acta Laurel?
Detail your services
Not every part of the Knowledge Lake Reference Architecture appears in a research paper.
That is intentional.
Research gives us concepts.
It does not prescribe the exact architecture required by a particular organisation.
The following are examples of Acta Laurel architectural decisions and conventions:
- a minimal sources/ and knowledge/ core;
- optional workspace/;
- optional vocabulary/;
- Personal, Enterprise and Engagement profiles;
- the Enterprise shared/ and domains/ convention;
- separating lakes where ownership or security boundaries differ materially;
- treating search indexes, vector stores and graph projections as derived infrastructure where appropriate;
- using a file-oriented approach to protect portability.
These decisions are informed by the underlying research and standards, but they remain architectural choices.
We believe that distinction should always be visible.
How the Foundations Fit Together
The full approach can be summarised simply in the diagram. The important point is not the diagram itself. It is that each layer solves a different problem. Knowledge Management research explains how knowledge is created and used. Knowledge Lake research provides architectural precedent. Standards and specifications provide common models and terminology.
The Acta Laurel Reference Architecture turns those foundations into a practical design.
Our Approach
Detail your services
Acta Laurel does not claim that research has already solved every practical knowledge problem.
It has not. Nor do we believe organisations should wait for a perfect universal model before improving how their knowledge is managed.
Our approach is to use established knowledge where it exists, keep architectural assumptions visible and introduce complexity only when the problem requires it.
That means:
- use recognised terminology
- prefer open standards
- preserve provenance
- protect portability
- separate knowledge from tooling
- design around real ownership and security boundaries
- avoid semantic complexity without a purpose
- keep people at the centre of knowledge creation and use
Further Reading
Detail your services
For readers who want to explore the academic and technical foundations in greater depth, the principal sources used throughout the Acta Laurel Knowledge Architecture include:
Knowledge Management
Alavi & Leidner (2001) — DOI 10.2307/3250961
Organisational Knowledge Creation
Nonaka (1994) — DOI 10.1287/orsc.5.1.14
Knowledge Lake
Beheshti et al. (2018) — DOI 10.14778/3229863.3236230
Knowledge Warehouse
Nemati et al. (2002) — DOI 10.1016/S0167-9236(01)00141-5
Reference Architecture
Angelov, Trienekens & Grefen (2012) — DOI 10.1016/j.infsof.2011.11.009
Knowledge Graphs
Hogan et al. (2021) — DOI 10.1145/3447772
Ontology
Gruber (1993) — DOI 10.1006/knac.1993.1008
Knowledge Engineering
Studer, Benjamins & Fensel (1998) — DOI 10.1016/S0169-023X(97)00056-6
Knowledge Organisation / SKOS
Baker et al. (2013) — DOI 10.1016/j.websem.2013.05.001
Security
Saltzer & Schroeder (1975) — DOI 10.1109/PROC.1975.9939
Architecture Description
ISO/IEC/IEEE 42010:2022
Provenance
W3C PROV Data Model
Portable Knowledge Representation
Open Knowledge Format
Built on What Came Before
Knowledge Management existed before generative AI. Knowledge Graphs existed before large language models. Provenance existed before RAG. Enterprise Architecture existed before cloud platforms. Security principles existed before SaaS. The technologies are changing. Many of the underlying problems are not.
Acta Laurel's objective is therefore not to invent a new vocabulary for every technology cycle. It is to combine established thinking with modern engineering in a form organisations can actually use.
Build on research. Follow standards where they help. Make architectural decisions explicit. Keep the knowledge durable.
Copyright © 2026 Acta Laurel - All Rights Reserved.
Your privacy matters
We use essential cookies to operate this website and, with your consent, optional analytics and third-party cookies to understand how our website is used, improve its performance and measure our services. You can accept or reject optional cookies. Rejecting optional cookies will not affect essential website functionality. For more information, please see our Privacy Policy and Cookie Policy.