There are some properties, such as MinFn, lessThan, etc., which seem to be tailored to make calculations, or to state numerical ratios, and their domain and range is on classes, rather than datatypes.
This is in principle correct, provided that there is also some datatype property that links those classes to actual datatypes; moreover, there should be some method in place to make the calculations and ratios work.
In OWL1, this is somehow difficult, but something can be done by using patterns such as http://ontologydesignpatterns.org/cp/owl/parameterregion.owl.
In OWL2, that can be partly done with n-ary data ranges (you can add facets to datatypes), and custom datatypes.
However, calculation properties and classes in this ontology are not linked to datatype properties, and therefore it can result difficult to practically use them.
The ontology looks too 'monolithic', and a partition performed with the partition tool in NTK shows that this is the case: at least 13 modules emerge, with an interesting import graph (see picture as appendix in the report). The most general architectural issue is that a large part of the ontology contains a quite sophisticated process ontology, which can be self-contained, and imported. Other modules seem to deal with calculations, taxes, some information-related notions, and finally with invoices and transactions.
I suggest to implement a modularization, at least at a coarse grain, in order to make understanding and management of the ontology more intuitive.
Changed version and namespace of DUL.owl and IOLite.owl to their current one.
Some properties do not have a domain or range at all. While a reasoner would simply put owl:Thing by default, certain editors do not provide some services by default in absence of a domain or range. I suggest to put owl:Thing where domain or range is missing.
However, some properties have intuitively a name that would suggest a more specific domain or range, like 'tax': in those cases, I suggest to attempt a more specific characterization.
The property institutionIdentifier has no usage and no axiom in the ontology, therefore it is hard to detect what thematic property can be used to collect it.
Moved quantity-oriented properties under 'numericProperty' for improving clarity of relation space. See also revisionWithSuggestion.
Changing the alignments to DOLCE+DnS or IOLite, to content ontology design patterns would be highly beneficial for the sake of NeOn; however, such alignments need a better understanding of the properties declared in the ontology, and it is difficult to guess their intended usage or requirement from the current ontology.
Probably, each of the classes aligned to dul:Process or dul:Relation can be extracted as individual modules (together with their relevant properties and axioms), and designed as specializations of the Situation pattern: http://ontologydesignpatterns.org/cp/owl/situation.owl.
Three time ontologies are reused: the W3 time ontology (only for the class time-interval), the W3 time zone ontology (only for the class TimeZone), and the time2.owl ontology, which has an ISOCO namespace, but it looks like the OWL-Time W3 ontology derived from Jerry Hobbs' time ontology. I suggest to clarify what the time2 ontology is, how it departs from OWL-Time, and if actually departs, to design it as a plugin to OWL-Time. Alignment to the TimeZone class can stay as it is.
Changed dul:SocialAttribute to dul:SocialObjectAttribute (name has changed in the latest versions of DOLCE+DnS).
No ontology entity is documented: I suggest to add rdfs:comment annotations for each of them.
Corrected spelling of AbsoluteValueFn, SubtractionFn, as well as other property names.
The ontology itself (not only its entities) is not documented: I suggest to add explanations of its motivation and intended usage in ontology annotations. A great enhancement would be to combine documentation and modularization by providing explicit competency questions to each module created e.g. through a partition or a custom modularization.
Properties have not been aligned to reference ontologies (DOLCE+DnS, IOLite, OWL-time). In order to make them more easily retrievable, and to prepare possible pattern-based design evolution, they have been collected under a few 'thematic' properties: invoiceRelation, invoiceAttribute, numericProperty, processRelation, quantityRelation.
Evaluated with suggested modifications by Aldo Gangemi (CNR).
Aldo: I aligned here Transaction to dul:Contract. If you want to include transactions that are not bound in a contract, then this should be changed. However, the subclasses included: betting, buying/selling, commercial services, are all contracts with some amount of money involved. The rationale is: does a transaction involve terms, agreements, can be transferred, etc.? or is it just an event? In practice both views are typically present, and if one, the other, or both should be modelled, depends on the competency questions to be assumed as ontology requirements.
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
invoice attribute
invoice relation
quantity relation
process relation
Aldo: added for giving more structure to the taxonomy of properties.
numeric property