Decision tree

[zembrowski]

Dear all,

does a schema for a decision tree structure exist?

I'm wondering whether it's reasonable to output the whole decision tree (with all questions, decision possibilities and answers [the whole tree with all branches]) in the ld+json format.

Moreover, does it makes sense to nest it, like the following example:

Question Choice __ Answer Choice __ Question __ Choice ____ Answer __ Choice ____ Answer cf. https://jsfiddle.net/zembrowski/q50L7t6f/

or

make it completely flat (with or without dependencies), like this example:

Question1 Question2 Choice1_1 Choice1_2 Choice2_1 Choice2_2 Answer1 Answer2 Answer3 and add a parameter to each element with the correlation. cf. https://jsfiddle.net/zembrowski/hevu3jof/

Would be more than happy to read your thoughts on this topic.

Thank you in advance.

Best regards, Krzysztof

[js-choi]

Schema.org isn't necessary to express a decision tree in JSON-LD. All that is required is creating a bunch of new URLs for the relationships you need, putting them into a JSON-LD context, and load the context into your JSON-LD library. In addition, JSON-LD can express the same data in nested or flat forms. Flat forms might require naming blank nodes. JSON-LD libraries can even automatically convert data between nested and flattened forms.

The benefit of shared linked-data vocabularies like Schema.org is that they improve interoperability, crawlability, and discoverability of data between independent computer systems, such as websites and search engines, through mutual agreement on names and their meanings. But shared vocabularies aren't necessary for private information. A useful analogy is to YAML's local versus global tags; the latter are useful only when two independent parties need to exchange data.

Have independent parties have needed to share simple decision trees with each other on the web? There appears to have been at least some interest in expressing things like finite state machines in linked data (http://www.tmrfindia.org/ijcsa/v7i12.pdf, https://www.researchgate.net/publication/289867778_Towards_an_Ontology_for_UML_State_Machines, etc.). And I can imagine bots on messenger platforms like Telegram, Facebook, etc. being useful to exchange in open formats. But there's a short jump from those to fully Turing-complete programs, which are of course much more complex to express, and which are already exchanged on the web as JavaScript and WebAssembly targeting web APIs. I don't know if there's yet much demand specifically for exchanging or crawling simple decision trees.

But you don't need Schema.org to use JSON-LD for decision trees anyway. You can express anything using JSON-LD by making up URLs for any type of relationship you need—as long as your computer programs, as well as the systems with which they interoperate, agree on what meanings those URLs have.

[zembrowski]

Dear @js-choi,

Thank you for the detailed answer.

I fully understand, that neither schema.org nor JSON-LD are necessary to build the backbone of a decision tree.

Currently the decision trees I use have a custom nested XML structure and are not crawlable or understandable (standalone) for machines. They are visualized (question by question/choice by choice) dynamically using JavaScript (jQuery). Due to the dynamic visualisation the whole decision tree is loaded into the browser using one certain URL. There is no communication with the server while making a choice and there are no URLs for the specific questions/choices in a decision tree, because the whole decision path/data is already loaded in the browser. Currently I am not planning to use prerender.io or SEO.js to make the decision tree crawlable. Therefore I asked my initial question, as I wondered whether a schema for a decision tree already exists, or at least a way to translate the XML nested decision tree into crawlable JSON-LD.

I am convinced, that having a decision tree schema is very useful. On one hand a decision tree is a logical and easy to understand way to visualize the decision making process (for humans). On the other hand it is a logical path for the machine to make a decision (using the human logic defined in the decision tree/schema).

In my specific case: translating paragraphs of legal acts/documents into a decision tree is firstly comprehensible for humans, secondly it is a path for decision making for machines whenever they have enough input information.

I understand your point, that machines won’t talk to each other using decision trees, but I believe decision trees are the easiest way to teach machines how our human (legal) decision making logic works.

Would be more than happy to read your further thoughts.

Best regards, Krzysztof

[nicolastorzec]

Summarizing discussions that happened via emails and mailing lists below.

Goal:

• Krzysztof's goal is to "make legal/law decision trees crawlable and understandable for machines using a set standard (i.e. schema.org)."
• Beyond the "Legal domain", and "decision trees", it seems to be about being able to identify and markup rules in Web pages, especially their antecedent and consequent.

Suggestions so far have been to look at:

• RIF, or Rule Interchange Format, is a format designed to exchange formal rules (e.g. business logic rules) expressed via logical statements.
• PMML, or Predictive Model Markup Language, is a format designed to exchange machine-learned predictive models (such as decision trees) between machines.
• StratML, or Strategy Markup Language, is a format designed to exchange "strategic plans".

Notes:

1) schema.org already has generic support for lists via ItemList and ListItem (i.e. one could encode trees via recursive lists) but nothing specific for rules. 2) Supporting rules would require to introduce one or more new classes to capture the rules' antecedents (i.e. the "if" part that describes the context/conditions) and consequents (i.e. the "then" part that describes the consequences: context update, actions, etc).

Cheers. -Nicolas.

[github-actions[bot]]

This issue is being tagged as Stale due to inactivity.

[RichardWallis]

See issue #7 for the context of the move from the main Schema.org issue tracker to this repository.