previous we have implemented an approach for restriction or highlighting property or class trees based on domain and range restrictions on properties, as a guide only guide only given open world
it would be also be benefical to use the owl class definitions ("domain typing") to apply modeling choice restrictions. For example is someone selects that a cell-based conversion column is a 'Water Measurement', and water measurement is defined that it is in the hasCharacteristic relationship with some Characteristic (this is not the case but I don't see a quick realistic example), then if someone drops hasCharacteristic, then either we restrict the tree or pre-populate the Class field with Characteristic.
since this requires more discussion and design will shelf until after demo, we can point to it as future work, but show that the domain/range aspect is functional.
some additional discussion from Evan on the topic:
"although i guess one issue with this approach is that you'll also see the ancestors of the contextualized roots. For example, if the property was allValuesFrom waterMeasurement, you'd see pol:Measurement, repr:Measurement, and owl:Thing as its ancestors. maybe we could grey out/disable classes above the roots and use invocations of PATH_TO_NODE to get paths down to each of the contextualized roots. this information is already cached by the hierarchical facet once the call completes so a return to either state will have all of the available data on the client, which will save network time."
previous we have implemented an approach for restriction or highlighting property or class trees based on domain and range restrictions on properties, as a guide only guide only given open world
it would be also be benefical to use the owl class definitions ("domain typing") to apply modeling choice restrictions. For example is someone selects that a cell-based conversion column is a 'Water Measurement', and water measurement is defined that it is in the hasCharacteristic relationship with some Characteristic (this is not the case but I don't see a quick realistic example), then if someone drops hasCharacteristic, then either we restrict the tree or pre-populate the Class field with Characteristic.
since this requires more discussion and design will shelf until after demo, we can point to it as future work, but show that the domain/range aspect is functional.
some additional discussion from Evan on the topic:
"although i guess one issue with this approach is that you'll also see the ancestors of the contextualized roots. For example, if the property was allValuesFrom waterMeasurement, you'd see pol:Measurement, repr:Measurement, and owl:Thing as its ancestors. maybe we could grey out/disable classes above the roots and use invocations of PATH_TO_NODE to get paths down to each of the contextualized roots. this information is already cached by the hierarchical facet once the call completes so a return to either state will have all of the available data on the client, which will save network time."