How to get started with the Logical Studio?

How to get started with the Logical Studio?

With the Logical Studio, you setup a branch in your data product for saved and reusable logic blocks.

When you start the Logical Studio for the first time, it presents you a guide for setting up a new branch (data workspace) with a specific logic schema for stored logic data.

The guide helps you create the following:

  • A new branch called _logic_main that will contain your stored logic
  • A WOQL schema for the stored logic
  • An example query to get started with.


How to write and use stored logic

The Logical Studio allows you to create two types of stored logic: one with parameters and one without. However, please note that in the initial version, parameters are not yet enabled.

The stored logic is crafted using WOQL, a datalog language integrated into the TerminusDB data products you build with the data product builder for logical twins. All of your stored logic is securely stored in the _logic_main branch and can be effortlessly executed through the user-friendly interface.

A quick intro to WOQL

Here's an example of stored logic that you can use to retrieve all documents in a data product branch and their respective types. Additionally, this query includes filters to exclude subdocuments and lists from the results.

select(
"v:object",
  "v:type",
  and(
  triple("v:object", "rdf:type", "v:type"),
  not(quad("v:type", "sys:subdocument", "v:nil", "schema")),
    not(eq("v:type", "rdf:List")),
  ),
)

The v: prefixes indicate that they are variables (think of them as lists of values). If they are not constrained, they will try to match as widely as possible amongst the subject, predicate and object parts of a triple. Each variable will be returned as a column in the tabular response, unless select is used to only select the specific variables to return.

The rdf:type predicate connects the type of a triple to the subject.

To delve deeper into the details of writing WOQL, please consult the comprehensive TerminusDB documentation.

Here are some good pointers to start with:

Some specific things to be aware of:
  • The editor supports the Javascript flavour of WOQL, without WOQL. prefix
  • The true and eval terms need to be prefixed as _true and _eval to work
  • Variables use the v: prefix. A variable would be referenced as "v:object above".

Good luck!


    • Related Articles

    • Use TerminusCMS data products in DFRNT

      Additionally to DFRNT hosted data products, you can connect and collaborate directly on data products hosted at TerminusCMS from DFRNT, using TerminusDB API keys. DFRNT.com helps you manage data products that are either hosted in DFRNT through the ...
    • Overview of DFRNT data modelling

      The data model in DFRNT data products follows the TerminusDB graph metamodel 1:1, and enables easy data modelling and advanced visualisation The data modelling capabilities of DFRNT.com involves five categories of data structures: Records, ...
    • The DFRNT Data Product Builder

      DFRNT is a data product builder with knowledge graph visualisation, modelling and management, with version control, API access and a datalog engine. With DFRNT data products, digital architects, cybersecurity professionals, data practitioners and ...
    • How can I learn more about DFRNT

      Learning about DFRNT is closely connected to leveraging the open source TerminusDB data product engine, for which DFRNT is a UI and hosting provider. DFRNT is a user interface and hosting provider for the open source TerminusDB data product ...
    • Data product translations as branches

      The recommended way to maintain data product translations is to use the branching method, where each branch corresponds to a language, and use a common schema where each label is translated as part of the schema documentation. Data product ...