Personalised product Technical Documentation made simple !
Digital transformation helps organisations to tailor personalised products that fit with client specific requirements by providing business agility and responsiveness all along the product life cycle from its design to its maintenance.
But what about the product technical documentation ? Because of the personalisation, product documentation can now be composed of multiple content parts, each being applicable on specific contexts (depending on the client, the serial number, the actual product options, etc.).
The effectivity of a content part can be converted into a query.
MarkLogic being a multi-model database, the links can be represented with triples and stored in the document themselves.
Continuous documentation updates : MarkLogic being able to perform "real-time" data ingestion, the documentations can be updated continuously to provide always up to date documentations to the clients.
Documentation as the service : The documentation being secured by Role based Access Control and automatically filtered based on client context (vie effectivity), the documentation data hub can be opened to third parties in order for them to deliver connected services.
But what about the product technical documentation ? Because of the personalisation, product documentation can now be composed of multiple content parts, each being applicable on specific contexts (depending on the client, the serial number, the actual product options, etc.).
If we consider the maintenance of a car, and train or an Aircraft, clients and maintenance team also expect to get the documentation tailored for the product they have to repair/maintain. Based on this documentation they then need to perform searches to find and extract relevant sections depending on their needs.
In this article, we will describe how MarkLogic can deliver high scalable and elegant solution with a simple architecture.
Assumptions
Let's consider the documentation is based on content parts, each being associated to a Table Of Content (TOC) entry and in a specific order in this entry.
Each content part has metadata, content (e.g. SGML, XML, binary, etc.), relations (with illustrations, part list, etc.) and an effectivity.
For more details about effectivity you can have a look at a previous post about Manufacturing 4.0.
How can we store all this content related data ?
With a document store, the approach is quite simple. Actually, they all fits into a document.
We can indeed load content part data into an XML document inside MarkLogic.
MarkLogic can load in a single document :
Metadata : XML storage allows any metadata to fit into the document
Effectivity ?
We already presented in a previous post how to leverage MarkLogic to manage part effectivity in a product structure (PLM). Here, we'll do the same.
The effectivity of a content part can be converted into a query.
The query can contain any condition on the product configuration, product serial, owner, etc.
This query is then serialised in the Effectivity XML section of the content part document.
The magic of the reverse queries is to allow a query based on data as an input. So instead of creating a query based on content part data conditions, we give the product configuration and MarkLogic can find all peace of content applicable for the product context (actually the content part whose serialised query is positive to the product configuration in input).
Here with the part effectivity exemple :
Everything is linked
The documentation is based on content building blocks, mainly XML parts assembled to deliver the final documentation. But the documentation also contains internal and external links to other objects or concepts (Parts, resources, diagrams, etc.)
MarkLogic being a multi-model database, the links can be represented with triples and stored in the document themselves.
In the Data Hub, content parts and other types of data/content can coexist and be linked with these triples.
Query principles
The content part being a atomic object with all its metadata, content, relations and effectivity, it's now easy to create a query that will position conditions on all these dimensions.
Meta, full-text and relation conditions will be provided as a standard query (boolean expression) and the configuration will be provided as an input also to allow reverse queries execution.
On a generated documentation sample with 600K content parts and 5 millions effectivity conditions, MarkLogic answers in 50ms on a laptop (Could be bigger but probably not relevant for a single product documentation). It can also build the faceted TOC during the same amount of time.
Key benefits ?
- simple is beautiful : single environment and single object to store and query text content, metadata and effectivity.
- Scalability: MarkLogic is a shared nothing architecture and can easily deal with hundreds of millions of document parts
- Security: MarkLogic is common criteria certified supporting multiple access control scenario (at document or even property) but it also supports encryption at rest using internal keys or external KMS and redaction.
- Enterprise capabilities: of course High Availability, Disaster recovery and backups are a must.
- Search and query: the search and query capability is at the core of the product, so the product provides in one product, the schema agnostic storage (to deal with the variety of metadata) but also the full-text search and query (based on structured and unstructured data)
- REST extension at the core: everything is exposed as REST services and can be consumed by internal applications but also client applications
What's next
But MarkLogic can do a lot more with the documentation.
Semantics can be use to facilitate content search :
- Semantic enrichment (via third party) can be performed on the content to extract concepts and facilitate the search
- Ontology can be used to expand automatically the queries
XML Content Query : If the content is itself partially structured using XML or SGML tagging, MarkLogic can perform queries in the content to extract specific sections or values. We had a use case before where maintenance operation durations were written in the text itself, and so MarkLogic was able to restructure it and perform analytics (variation between documentation/Product versions)
Continuous documentation updates : MarkLogic being able to perform "real-time" data ingestion, the documentations can be updated continuously to provide always up to date documentations to the clients.
Documentation as the service : The documentation being secured by Role based Access Control and automatically filtered based on client context (vie effectivity), the documentation data hub can be opened to third parties in order for them to deliver connected services.
