In this project, the ranges of subproperties are programmatically enforced: the JSON Schema of a subproperty validates a document only if the JSON Schema of its superproperty also validates. In other words, since <event> <sdo:sponsor> <brand> fails validation (because sdo:Brand is not in the range of sdo:sponsor), then there is no syntactic possibility for <event> <sdo:funder> <brand> to validate.
However, the domains of subproperties are not enforced programmatically, but only through human knowledge and discipline. For example we would like to ensure that the domain of sdo:funder is equal to or more restricted than the domain of sdo:sponsor. That is, we would like to make sure that the only classes that have sdo:funder as a member either (a) also have sdo:sponsor as a member, or (b) extend a superclass that has sdo:sponsor as a member.
Currently though, it is possible to give an arbitrary class, say, sdo:City, a member of sdo:funder (even though that class has no such member in the specification), without receiving an error. And therefore it would be possible for <city> <sdo:funder> <organization> to validate even though <city> <sdo:sponsor> <organization> would fail to validate—thus losing the “implication” requirement of subproperties. The only current way to prevent this is for a human to know the specs and be careful not to add members to the wrong classes.
In conclusion, this issue requests a programmatic feature that “makes it impossible” to add a subproperty to a class that, either (a) its superproperty is not a member of, or (b) has no superclass that includes the superproperty as a member. The “impossible” part would be enforced programmatically: if the JSON Schema of a class included an incorrect property, that schema would fail validation. Most likely this would involve some type of metaschema code, as the goal is to validate a JSON Schema.
A subproperty implies (rather, should imply) the relationship of its superproperty. E.g. if
<x> <sdo:funder> <y>then it is safe to assume that<x> <sdo:sponsor> <y>, sincesdo:funderis a subproperty ofsdo:sponsor.In this project, the ranges of subproperties are programmatically enforced: the JSON Schema of a subproperty validates a document only if the JSON Schema of its superproperty also validates. In other words, since
<event> <sdo:sponsor> <brand>fails validation (becausesdo:Brandis not in the range ofsdo:sponsor), then there is no syntactic possibility for<event> <sdo:funder> <brand>to validate.However, the domains of subproperties are not enforced programmatically, but only through human knowledge and discipline. For example we would like to ensure that the domain of
sdo:funderis equal to or more restricted than the domain ofsdo:sponsor. That is, we would like to make sure that the only classes that havesdo:funderas a member either (a) also havesdo:sponsoras a member, or (b) extend a superclass that hassdo:sponsoras a member.Currently though, it is possible to give an arbitrary class, say,
sdo:City, a member ofsdo:funder(even though that class has no such member in the specification), without receiving an error. And therefore it would be possible for<city> <sdo:funder> <organization>to validate even though<city> <sdo:sponsor> <organization>would fail to validate—thus losing the “implication” requirement of subproperties. The only current way to prevent this is for a human to know the specs and be careful not to add members to the wrong classes.In conclusion, this issue requests a programmatic feature that “makes it impossible” to add a subproperty to a class that, either (a) its superproperty is not a member of, or (b) has no superclass that includes the superproperty as a member. The “impossible” part would be enforced programmatically: if the JSON Schema of a class included an incorrect property, that schema would fail validation. Most likely this would involve some type of metaschema code, as the goal is to validate a JSON Schema.