Handling logical relationships between model entities

[stuartasutton]

On Wednesday's deep dive, @robinsonkwame asked about handling logical relationships between model entities. I gave a long-winded comment about the distinction between handling them algorithmically (smart system/dumb data) or through the data modeling (smart data). I've created a couple of figures on how we might handle such relationships directly in the model: (1) a revised subsection from the domain model; and (2) a cartoon that illustrates how the modeled entities could work to support logical relationships (and/or).

Model snippet

This snippet from the data model does the following: It fleshes out the properties directly referencing education, experience and credential entities to include naming aspects that better define some in terms of their relationships to others--e.g., the use of "preferred", "minimum", "alternative", "equivalent". Second, there is a new Condition entity used to cluster related entities. A Job Description/Posting can have more than one Condition entity and any Condition entity can have "alternative" Condition entities.

Cartoon example

In the cartoon below, we have a Job Description/Posting that provides an experience option (left branch alternative condition) for fulfilling requirements as well as an education option (right branch alternative condition). While the cartoon is a bit tidy, nothing precludes alternatives mixing education, experience and credentialing. In this example, the education option ORs together minimum credential and a preferred credential. The experience branch is more difficult since it includes two levels of branching--one ANDing and the other ORing choices.

[robinsonkwame]

@stuartasutton this would be extremely useful to include in the data model and it's straight forward to apply. The cartoon clarifies the application of this quite well.

On the same deep dive I remember it was mentioned that the alternative to smart data would be to embed the logic into the application (e.g, smart system).

I think I may have come upon a third way, of sorts, that may be of interest: embed the logic not into the application but into the data as a separate element, outside of the JDX schema and into the actual .json-ld file. By doing so the JDX schema needs no changes and a dumb system, if you will, can also evaluate a job description described by both the schema and the embedded rules.

To illustrate, a rough example for “The successful candidate will have a bachelor degree or obtain a bachelor’s degree before 9 months of starting and also have completed an internship," is given below:

    {                                                                    
        "@context": [ "http://schema.org/" ,
                {"jdx": "http://jdx.org/terms/"}
            ],
        "@graph": [{
            "jdx:title": {"en": "Software Engineer"},
        ... // includes educationRequirements for bachelor degree, internship
            }],
        "description_logic": {
            "rules": { "and" : [
                        {"<" : [ { "var" : "bachelor_degree.months_to_completion" }, 9 ]},
                        {"==" : [ { "var" : "internship" }, "True" ] }
                        ] }
        }                                                                
    }

The above uses the JDX schema with no modifications to describe the job description while also providing a description_logic to describe how the description can be logically interpreted, to determine if a given applicant meets requirements. I see this approach as a third approach since it includes the logic, the system just has to extract applicant variables carry out the description_logic.

Given all of this, what might you see as pros and cons of the "smart data" vs. "smart system" vs. this third approach?