When to create a new subproperty

One way to keep the ontology simpler and easier to understand is to reduce the proliferation of properties whose core meaning is the same, the only difference being the domain and range.  For example, a property hasMember say of a collection. You could create a new property for every kind of member. hasSmartMember, hasNobelPrizeWinningMember, hasUSCitizenMember etc, where the range for the latter properties would be SmartPerson, NobelPrizeWinner, USCitizen, etc. 

A common example is introducing hasBrother and hasSister rather than just having hasSibling. The core meaning of the relationship is the same, the only difference is the gender of the sibling. By having a single property instead of multiple ones, it greatly simplifies things, and there is no loss of information.  

An example in loans arose today. For a LoanContract, there is often collateral, so we have a property called hasCollateral. There is no need to have separate properties for different kinds of collateral (e.g. hasCollateralCar, hasCollateralProperty) for carloans and mortgages.

This can go too far, of course, it is a balance to be struck.  Sometimes I have broken this rule just to make the ontology easier to read and understand. When there are commonly used terms of art, the client often want to see those names in the ontology.  

We can strike a balance by erring on the side of NOT introducing new sub-properties at the conceptual level. When building applications, people may wish to add those subproperties there.

I propose that we add a hygiene rule that checks to see if a subproperty differs only from the superproperty by having only a more restricted domain and range.  This may throw up too many false positives, since there is not that much one can say about the meaning of a property in OWL. Sophisticated NLP would help, if the definitions were well written, but that is a bit ambitious.  Even with the false positives, it might be useful to find them all and go through them and decide. It would even be possible (thoguh probabaly a bit overkill) to have an annotation that explicitly overrides the convention, then the hygine code can ignore that the next time around.

Examples

There is no need to creaete separate properties for say hasDate, hasAddress, hasAccount, you can instead have restrictions on clases such as "has some Date" "has some Address" and "has some Account". 

For dates, it might work the other way around.  hasStartDate, hasSubmittedDate etc.  Why not apply the above principle? Well, because there is nothing different about a StartDate or a SubmittedDate, so it makes no sense to create classes for those. Just creat a new property with the same range (Date) but which specifies the rel between the thing and the date. There is are real difference in meaning between start date and submitted date. 

So in the first case, the difference in meaning is in the classes, and in the second case, the difference in meaning is in the properties.

A similar example is for MonetaryAmounts. There is just one kind of MonetaryAmount, not many. But there are many different relationships to a MonetaryAmount, e.g.: hasAnnualSalary, hasCreditLimit, hasNoteAmount, monthlyPayment, etc