Remove gist:Address from ranges of gist:toAgent and gist:fromAgent. Fixes #391. #395
Conversation
|
There were someValuesFrom restrictions on gist:Message that repeated the union ranges in toAgent and fromAgent. Rather than removing Address from these as well, I replaced the restrictions with minCardinality restrictions, since there's no sense in duplicating the ranges in the restrictions. The definition of Message was and is out of sync with the specified ranges is reflected in a new issue #396. |
gistCore.ttl
Outdated
| owl:minCardinality "1"^^xsd:nonNegativeInteger ; | ||
| ] | ||
| [ | ||
| a owl:Restriction ; | ||
| owl:onProperty gist:toAgent ; | ||
| owl:someValuesFrom [ | ||
| a owl:Class ; | ||
| owl:unionOf ( | ||
| gist:Address | ||
| gist:Organization | ||
| gist:Person | ||
| ) ; | ||
| ] ; | ||
| owl:minCardinality "1"^^xsd:nonNegativeInteger ; |
There was a problem hiding this comment.
You went an extra step that was not necessary, and has possible downsides:
- min 1 cardinality is less efficient than someValuesFrom for reasoning. This I learned from my FIBO experience, and I put that recommendation in my book.
- the redundancy you are avoiding here can backfire. The min 1 is depending on the range of to(from)Agent. But if that changed, an error can happen. If the classes in the range are explicit like it was to begin with, the error is less likely.
- You could be accused of being a union-buster :-)
A decision to remove such redundancies by using min 1 restrictions is a change that should be considered separately, for all of gist, not done piecemeal in otherwise unrelated issues.
I recommend just removing gist:Address from the two original unions and leave it at that. I.e. put back the unions and leave out gist:Address.
There was a problem hiding this comment.
It can't work that way because if the range of those properties is Person U Organization, it makes no sense to have a someValuesFrom restriction Person U Organization U Address. Given the range, there should be no assertions with object Address.
I understand your preference for someValuesFrom over minCardinality, but when there is no value other than owl:Thing, it is clearer to state it as a cardinality. I have no strong objection to changing the cardinality to a someValuesFrom, but Address is useless and ought to be removed.
There was a problem hiding this comment.
And I still maintain that the values restrictions should not replicate the range of the predicate. I understand your rationale but presumably when someone is editing the predicate they look at all the references to it. Making allowances for not doing so is tantamount to building in bad practice.
There was a problem hiding this comment.
We clarified that in my initial comment above I misunderstood Michael's suggestion, which was in fact what I proposed. We also agreed that the decision about union restrictions duplicating ranges should be addressed in a new issue, now created as #397.
…m the unions As per reviewer request
No description provided.