Profile level relationships between classifications

[azaroth42]

While the code ensures that the domain and range of the ontology level relationships are enforced, there is nothing that either describes nor checks profile level relationships between instances with potentially incompatible or inconsistent classifications.

For example:

• A sales catalog physical object should carry a sales catalog text, not a lottery catalog or a stock book.
• The production of a painting should not have the technique of sculpting.
• A provenance entry activity can have a Payment which is part of it, but a Payment cannot have a provenance entry as a part. (etc)

This seems like it would be beneficial to add, but we need to understand the use cases and motivations first.

In particular:

• automated checking, as per the ontology, of manually created instances being linked together in unexpected ways could emit a warning or error
• classes could be interrogated for possible values per property, beyond just the ontology layer and instead take into account vocabulary
• classes could have APIs that create the default referenced object, link it in the right property, and return it ( vocab.SalesCatalog.make_textual_work() --> vocab.SalesCatalogText )

This issue is for tracking such use cases and ideas.

[kasei]

Regarding the last point, in Sales, Knoedler, and AATA I am often creating parallel hierarchies of LinguisticObjects and HumanMadeObjects. For example, Folio part_of SalesCatalog, with both LinguisticObject variants being carried_by their HumanMadeObject counterpart.

Thinking about how to generalize this modeling pattern, it would be nice to be able to effectively say "construct this parallel hierarchy structure using the AAT codes 300189604 (folio) and 300026074 (sales catalog)".

In the common case of wanting to use the lowest-level LinguisticObject to set as the value of referred_to_by, we might develop an API using crom primitives that would accept AAT codes (or equivalent) as arguments and returns just the most specific LinguisticObject, while adding all instances to a queue for serialization. In the Knoedler code, that look something like:

object_title = vocab.Name("Bay of Naples")
object_title.referred_to_by = sales_folio(book=3, folio=174)

While we could implement sales_folio by hard-coding the equivalences between existing vocab classes (SalesCatalogText ~ SalesCatalog, FolioText ~ Folio), a cleaner implementation would be one that identified just the conceptual need for representing Sales Catalogs and Folios, and let crom do the work of correlating the classes with differing parents (LOs and HMOs).