@mereolog I need to look at these on a case by case basis as there are a few that we may want to retain. For example, in LCC we have the definition of an identifier, which by definition must identify 'something', but we don't know what precisely. It will be qualified where it is used, but not at the highest level. In other cases, like with EntityLegalForm, the target is either an xsd:string or language tagged string, so we've left that to default to Literal. One option would be to create a datatype for a text value that is the union of xsd:string and language tagged string, but I would have to do some research to see how much work it would be to do that in the various cases where this happens. Could be that several of these reflect that case.

Ok, shall we say that we park this test for a while?
(I am asking because I am about to raise an issue about updating the ontology guide so that it fits the current set of tests).

@mereolog Hi Pawel, yes - leave it here as an open issue so I can check where these occur, and maybe raise issues to fix those that are "fixable", and identify which ones need to stay as they are. Then we can decide if you should implement it but allow a couple of exceptions, or not.

I cannot find mention of (un)qualified restrictions in the Ontology Guide. t10 is about rdfs:comment

Yes, it was t10 in a previous version of the guide, but the point here is to discuss and decide whether we need it or not.
For the reference, I include the original text below:
For the most part in FIBO, we have used qualified cardinality restrictions, which help with understanding as well as with identifying data quality issues in mapped back-end resources. Extensions to FIBO should use qualified cardinalities wherever possible, and use of unqualified cardinalities must be justified when the additions are under review.

There are 3 ontologies that include minCardinality (unqualified) - RegistrationAuthorities in FBC, and Assessments and Arrangements in FND. There are no cases of maxCardinality in any FIBO ontology. 5 ontologies include unqualified exact cardinalities - CorporateBodies, IdentifiersAndIndices, Ratings, Roles, and Analytics. Per Pawel, these need to be reviewed to make sure that they are appropriate, as we've limited the usage of unqualified cardinalities to those that are needed in very general cases.

I think where the cardinality is exactly zero (i.e. the property should not be used with the subject class) then having a qualifying class on the restriction is unnecessary and misleading.

More generally I believe that adding the qualification actually loosens the restriction., probabyl beyond what non-experts would expect.
If we have:
[a owl:Restriction; owl:onProperty :rP; owlMaxCardinality 2]
then that limits :rP to 2 values, period.
Adding onClass :RC:
[a owl:Restriction; owl:onProperty :rP; owlMaxQualifiedCardinality 2; owl:onClass :RC]
limits only the number of instances of :RC and allows any number of instances of other classes.

I believe we intend to say there should be max 2 values and they should all be instances of :NC.
Which I think would need two restrictions:
rdfs:subClassOf
[a owl:Restriction; owl:onProperty :rP; owlMaxCardinality 2] ,
[a owl:Restriction; owl:allValuesFrom :RC ] ;