maastrichtu-ids / cbcm-ontology Goto Github PK

I notice that 'involves' has a domain restriction of 'company transaction'. is that intended?

because the problem with that is that "Acquiring company" is inferred to be a Company and a Company Transaction.

actually, lots of things get inferred as a company transaction, including "company employee" etc. just do a DL query for 'company transaction' with a reasoner to find all of them.

I might suggest to add disjoint axioms so as to find potential modeling errors (e.g. unsatisfiable classes and inconsistent individuals) in the ontology. This will also be useful when trying to avoid errors in map the ontology to external ontologies.

The class Company includes a subclass axiom "hasParentCompany some Company", but what makes this universally true? There's no description to guide the usage. I can imagine this is more relevant in the context of some transaction, but I don't think it holds true for any company.

What is the intended role of the data property "transfers" as it seems odd and is not used in any class expression.

In the database schema, we have the is_se field, which indicates whether a transaction concerns the creation of an SE company. According to the excel sheet an SE can be created via merger, conversion, holding-SE, subsidiary-SE, or unsure when this information is unknown.

Would it make sense to represent this information via the transaction's class (aka type) by classifying these transactions as "SECreation" with the following subclasses?

• SECreationConversion
• SECreationHolding
• SECreationMerger
• SECreationSubsidiary

And when we do not know the SE creation subtype (equivalent to "unsure") we would assign the umbrella class "SECreation".

This structure could allow users to write more expressive queries (instead of querying on the boolean is_se and the se_type fields), what are your thoughts on this?

The use of indiscriminate predicates (e.g. involves) to point to individuals (e.g. a specific company) that are assigned role-based types (e.g. Acquiring company, Merging company) will fail as soon as one company is involved in both a merger and an acquisition (are part of different company transactions) - as they will be typed as both "Acquiring Company" and "Merging Company" and it won't be clear what role it had in either transaction. You can avoid this problem by either using specific predicates in the transaction (e.g. "has-acquisition-company" "has-merging-company"), or use transaction-unique instantiated roles ( involves some ('acquisition role'|'merging role' that 'is role of' some 'company').

One option could be to OnToology to identify (and then rectify) common "pitfalls". It can be integrated as a hook with the github repo, so every commit will generate the documentation automagically.

there appears to be a merge of 'annual account' and 'annual report' in the ontology, as both labels and descriptions appear on the URI http://ids.maastrichtuniversity.nl/ontologies/cbm/eu-cm-ontology#AnnualAccount