Abstract class inserted into instance document

[timathom]

Describe the bug My schema defines a subdocument class (E33_E41_Linguistic_Appellation) that inherits from an abstract (subdocument) class (tdb:IdentifierOrNameType). Instance documents that conform to the schema display correctly in DFRNT.

A record looks like this:

{
  "P1_is_identified_by": [
    {
      "@type": "E33_E41_Linguistic_Appellation",
      "@id": "E21_Person/1d142ce2-31e9-4a42-b534-bf8a13b347b9/P1_is_identified_by/E33_E41_Linguistic_Appellation/Qtu9CVZg2B49B9tm",
      "P190_has_symbolic_content": "William Blake"
    }
  ],
  "rdfs:label": [
    "Blake"
  ],
  "@type": "E21_Person",
  "@id": "E21_Person/1d142ce2-31e9-4a42-b534-bf8a13b347b9"
}

However, when I try to edit the record and add a new subdocument entry for P1_is_identified_by, the abstract class is inserted as the @type:

{
  "P1_is_identified_by": [
    {
      "@type": "E33_E41_Linguistic_Appellation",
      "@id": "E21_Person/1d142ce2-31e9-4a42-b534-bf8a13b347b9/P1_is_identified_by/E33_E41_Linguistic_Appellation/Qtu9CVZg2B49B9tm",
      "P190_has_symbolic_content": "William Blake"
    },
    {
      "@type": "tdb:IdentifierOrNameType",
      "P190_has_symbolic_content": "Testing"
    }
  ],
  "rdfs:label": [
    "Blake"
  ],
  "@type": "E21_Person",
  "@id": "E21_Person/1d142ce2-31e9-4a42-b534-bf8a13b347b9"
}

When I try to save the edited record, an error is thrown (see screenshot).

To Reproduce Steps to reproduce the behavior:

1. Load the schema (below)
2. Load the instance record (above)
3. Edit the record to add a new subdocument entry for P1_is_identified_by
4. Try to save the record
5. See error

Expected behavior When one or more classes inherit from an abstract class, there needs to be a way to select the specific class that is desired as the object type. In my example, I should be given the option to select E33_E41_Linguistic_Appellation (or it could be inserted as the default, since in this case it is the only class that inherits from tdb:IdentifierOrNameType).

Screenshots

Info (please complete the following information):

• DFRNT.com (QA environment)

Additional context Schema

[
  {
    "@base": "https://lux.collections.yale.edu/data/",
    "@schema": "http://www.cidoc-crm.org/cidoc-crm/",
    "tdb": "terminusdb:///schema#",
    "@type": "@context",
    "@metadata": {
      "DFRNT": {"defaultLabelProperty": "rdfs:label"}
    },
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  {
    "@abstract": [],
    "@id": "tdb:EntityType",
    "@type": "Class",
    "P1_is_identified_by": {
      "@class": "tdb:IdentifierOrNameType",
      "@type": "Set"
    },
    "rdfs:label": {
      "@class": "xsd:string",
      "@type": "Set"
    }
  },
  {
    "@abstract": [],
    "@id": "tdb:IdentifierOrNameType",
    "@inherits": "tdb:EntityType",
    "@type": "Class",
    "@subdocument": [],
    "P190_has_symbolic_content": {
      "@class": "xsd:string",
      "@type": "Optional"
    }
  },
  {
    "@documentation": {"@label": "Person"},
    "@id": "E21_Person",
    "@inherits": "tdb:EntityType",
    "@key": {"@type": "Random"},
    "@type": "Class",
    "@unfoldable": [],
    "P98i_was_born": {
      "@class": "E67_Birth",
      "@type": "Set"
    }
  },
  {
    "@id": "E53_Place",
    "@inherits": "tdb:EntityType",
    "@key": {"@type": "Random"},
    "@type": "Class",
    "@unfoldable": []
  },
  {
    "@documentation": {"@label": "crm:E67_Birth"},
    "@id": "E67_Birth",
    "@key": {"@type": "Random"},
    "@subdocument": [],
    "@type": "Class",
    "P7_took_place_at": {
      "@class": "E53_Place",
      "@type": "Set"
    }
  },
  {
    "@id": "E33_E41_Linguistic_Appellation",
    "@inherits": "tdb:IdentifierOrNameType",
    "@key": {"@type": "Random"},
    "@subdocument": [],
    "@type": "Class"
  }
]

[timathom]

I just tested editing functionality for inherited (top-level) classes in TerminusCMS. The schema below produces the following editing form in TerminusCMS:

Here, I am able to select an inheriting class as my instance type.

However, in DFRNT, I do not have this option:

See the inheritance_test data product in DFRNT to reproduce.

[
  {
    "@base": "https://lux.collections.yale.edu/data/",
    "@metadata": {
      "DFRNT": {"defaultLabelProperty": "rdfs:label"}
    },
    "@schema": "terminusdb:///schema#",
    "@type": "@context",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#"
  },
  {
    "@abstract": [],
    "@id": "EntityType",
    "@type": "Class",
    "rdfs:label": {
      "@class": "xsd:string",
      "@type": "Set"
    }
  },
  {
    "@documentation": {
      "@label": "My Record",
      "@properties": {
        "rdfs:label": {"@label": "_label"}
      }
    },
    "@id": "MyRecord",
    "@inherits": "EntityType",
    "@key": {"@type": "Random"},
    "@type": "Class",
    "@unfoldable": [],
    "references": {
      "@class": "EntityType",
      "@type": "Set"
    }
  },
  {
    "@documentation": {
      "@label": "Place",
      "@properties": {
        "rdfs:label": {"@label": "_label"}
      }
    },
    "@id": "E53_Place",
    "@inherits": "EntityType",
    "@key": {"@type": "Random"},
    "@type": "Class",
    "@unfoldable": [],
    "P1_is_identified_by": {
      "@class": "E33_E41_Linguistic_Appellation",
      "@type": "Set"
    }
  },
  {
    "@documentation": {
      "@label": "Name",
      "@properties": {
        "P190_has_symbolic_content": {"@label": "content"}
      }
    },
    "@id": "E33_E41_Linguistic_Appellation",
    "@key": {"@type": "Random"},
    "@subdocument": [],
    "@type": "Class",
    "P190_has_symbolic_content": {
      "@class": "xsd:string",
      "@type": "Optional"
    }
  },
  {
    "@documentation": {
      "@label": "Person",
      "@properties": {
        "P1_is_identified_by": {"@label": "identified by"},
        "rdfs:label": {"@label": "_label"}
      }
    },
    "@id": "E21_Person",
    "@inherits": "EntityType",
    "@key": {"@type": "Random"},
    "@type": "Class",
    "@unfoldable": [],
    "P1_is_identified_by": {
      "@class": "E33_E41_Linguistic_Appellation",
      "@type": "Set"
    }
  }
]

[hoijnet]

This is great input. Looks non-trivial to fix immediately, but will be updating as I find solutions to it.

Some additions based on reflections and conversation:

• Types of existing subdocuments should be respected and kept, not set to type selected in the model, inherited subdocument types should be handled too
• The additional properties beyond the ones of a top-level selected type should be supported
• The UI should provide a selector, in which types that can be supported according to the model should be selectable
• The selection should then update the document, and update the document form accordingly
• A more specific JSON Schema should be possible to export that match a specific document configuration (so that additional properties beyond the minimum can be checked against). This enables specific type configurations to be checked against by providing a sample document according to a more constrained type configuration, compared to the top-level more relaxed checking that, if running in strict mode, would fail due to extra properties in for example AJV.

If you can consider more of the specifics @timathom, they would be great to add here. I consider that types from the document would be checked to both be valid, and if valid according to the schema, a custom validator instance would be created for it, so that the form follows the form of the document, given selectors for subdocument types, if more than one option is possible.

There are some implications that will need to be weighed here. At least the problem definition starts to become clear.

[hoijnet]

There is now a fix in the QA environment which now properly recognises both abstract subdocuments, and allows specific type selection when multiple selections are possible:

• If only an abstract subdoc/trait type is available, it falls back to the abstract type, to have something at least
• If there is one trait that inherits from the abstract type, offer that one for selection
• If more than one traits are possible for the subtype, give the ability to select the specific intended type
• If no ambiguity for which type to render the form for, the type is not shown/selectable

Please test to ensure it works as you expect! I created a branch philippe_issue_16 where I tested a bit! I even created an additional inherited one, and they behave as expected now.