Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profile level relationships between classifications #157

Open
azaroth42 opened this issue Apr 1, 2020 · 1 comment
Open

Profile level relationships between classifications #157

azaroth42 opened this issue Apr 1, 2020 · 1 comment

Comments

@azaroth42
Copy link
Contributor

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
Copy link
Collaborator

kasei commented Apr 1, 2020

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants