Class/subdocument "punning"

[timathom]

I'm fairly new to TerminusDB and already a big fan. However, I've run into a pain point in relation to the data model that I need to work with. I'm using a model that's based on the CIDOC-CRM ontology, which was designed to describe cultural heritage materials (e.g., a painting in a museum). Rather than enumerate all the possible kinds of things that could be a cultural object, the model contains abstract classes such as E25_HumanMadeObject, E33_LinguisticObject, and E36_VisualItem, which can then be refined or "classified" using a taxonomy or concept scheme. Example:

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://lux.collections.yale.edu/data/object/4a3d1b7d-9657-46dc-8363-18866dc4a6ed",
  "type": "HumanMadeObject",
  "shows": [
    {
      "id": "https://lux.collections.yale.edu/data/visual/a121e511-e010-40c0-80c7-bad50eff2844",
      "type": "VisualItem",
      "_label": "Portrait of Lynette Yiadom-Boakye, Jacob Morland of Capplethwaite [Visual Content]"
    }
  ],
  "classified_as": [
    {
      "id": "https://lux.collections.yale.edu/data/concept/33175c5f-4d70-4efd-a387-b2b7d3a5030d",
      "type": "Type",
      "_label": "Paintings",
      "classified_as": [
        {
          "id": "https://lux.collections.yale.edu/data/concept/4ea65dc4-76bc-45b7-b54c-a1ca4783d4e2",
          "type": "Type",
          "_label": "Type of Work"
        }
      ]
    },
    {
      "id": "https://lux.collections.yale.edu/data/concept/4a172143-a50e-4d91-a88b-a9931bceecf1",
      "type": "Type",
      "_label": "Visual Works",
      "classified_as": [
        {
          "id": "https://lux.collections.yale.edu/data/concept/3fdac98e-1396-4e75-bb52-33894863c571",
          "type": "Type",
          "_label": "Super Type"
        }
      ]
    }
  ]
}

This approach lends itself to reuse of classes at different levels. For example, E33_LinguisticObject can be a top-level document representing a textual work (such as a book or manuscript), but it can also be a subdocument representing a note, summary, etc. (example).

In TerminusDB, the approach becomes problematic because of the hard line between document and subdocument: the instances of a single class have to be one or the other. Coming from an RDF context, where an individual can be either a resource with an IRI or an anonymous resource, this distinction in TerminusDB seems unintuitive. For example, take a class such as prov:Activity in the W3C PROV Ontology. Depending on the context, you may want to describe an activity as a top-level resource, or as an anonymous resource within a larger process.

I understand that the @unfoldable schema annotation is designed to help address this issue, but it creates a significant burden for data management. This screenshot (from the display in DFRNT) shows the result of importing a single LinguisticObject document. In my schema, I've declared E33_LinguisticObject to be @unfoldable, but every instance of the class is broken out as a top-level document, leaving me with a long list of notes, etc., that are not intended to stand alone as separate records.

As a possible solution to this dilemma, I'd propose turning @subdocument and @unfoldable into property-level annotations rather than class-level annotations, to avoid imposing a global restriction on document structure. For example:

{
    "@id": "crm:E33_LinguisticObject",
    "@type": "Class",
    "crm:P671i_is_referred_to_by":
    {
        "@type": "Set",
        "@class": "crm:E33_LinguisticObject",
        "@subdocument": []
    }
}

Having this kind of granular control over document structure would allow a much wider range of real-world modeling scenarios to be accommodated in TerminusDB.

[hoijnet]

I have been thinking about a similar, deceptively simple, example: PhysicalAddress.

You could easily have the same data structure as a PhysicalAdress instance, indicating a precise location, which could be referenced by many, or use the same data structure a withAddress attached to a shipTo of a lineItem on an Order.

I find the proposal to be an effective way to allow reuse of data structures. I have found it extremely helpful and a core feature of TerminusDB to mostly separate the data structures from the ontology/taxonomy, which enables significant flexibility and elegance.

This would abstract what I already find elegant into a next level.

As for transitioning from the current in the proposal, I believe the core change would be to be able to use a type as a subdocument in some instances. If limiting it to that, I think the transition could be easier and backwards compatible, hopefully.

• You could still set a type as @unfoldable
• The new property annotation, would mean that the type is to be treated as a subdocument in this instance (and since it has a subdocument ID (at least in style), it could be recognized as such.
• Subdocuments could still be used as usual.

Considering the above, subdocuments would still exist, but you could use a type as a subdocument if you want.

I like it, I also see how I could easily make it work in DFRNT if implemented like proposed.

[timathom]

Thanks, @hoijnet, for the additional example and nuance. I think you're right that it could be done in a way that's backwards compatible.

Just to add another layer, in the JSON-LD snippet I included above, there's an IRI reference that appears in a kind of "subdocument" structure. I wouldn't want to unfold the whole document that's identified by https://lux.collections.yale.edu/data/concept/33175c5f-4d70-4efd-a387-b2b7d3a5030d because it is a large document, but I want to be able to show selective information about it in the context of the current document:

{
  "classified_as": [
    {
      "id": "https://lux.collections.yale.edu/data/concept/33175c5f-4d70-4efd-a387-b2b7d3a5030d",
      "type": "Type",
      "_label": "Paintings",
      "classified_as": [
        {
          "id": "https://lux.collections.yale.edu/data/concept/4ea65dc4-76bc-45b7-b54c-a1ca4783d4e2",
          "type": "Type",
          "_label": "Type of Work"
        }
      ]
    }
  ]
}

In this case, it seems that what's needed is the ability to define a shape for unfoldables so that only a subset of relevant properties is displayed. Something like:

[
  {
    "@abstract": [],
    "@id": "ClassificationShape",
    "@type": "Class",
    "rdfs:label": {
      "@class": "xsd:string",
      "@type": "Optional"
    },
    "crm:P2_has_type": {      
      "@class": "crm:E55_Type",
      "@type": "Optional",
      "@shape": "ClassificationShape"
    }
  },
  {
    "@id": "crm:E25_HumanMadeObject",
    "@type": "Class",
    "crm:P2_has_type": {
      "@type": "Set",
      "@class": "crm:E55_Type",
      "@unfoldable": [],
      "@shape": "ClassificationShape"
    }
  }
]

Alternatively, the @metadata section of the class definition might be leveraged to define a target shape for unfoldables.