You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've always thought that OWL named graphs are a good mechanism for modeling variants. In the simplest case, create one description for common assertions and one for each variant. Then there are two scopes for reporting and analysis: common plus variant 1, common plus variant 2. This extends to nested subvariants and arbitary combinations of variants, e.g., space optical plus ground optical, space RF plus ground RF, excluding optical/RF combinations.
I think we have everything we need to do this now with the exception of specifying multiple variant description roots (i.e., bundles) in build.gradle and the nesting the resulting analysis products under the appropriate variant. This seems like a really clean way to go about it and doesn't require any new notation or vocabulary for variants per se.
I suppose we could make a separate branch in git for each variant but that seems almost impossible to manage.
It might be helpful for the UI to have a perspective for each description root and hide anything not transitively imported by it. Switching perspectives is just a click.
Thoughts?
The text was updated successfully, but these errors were encountered:
I've always thought that OWL named graphs are a good mechanism for modeling variants. In the simplest case, create one description for common assertions and one for each variant. Then there are two scopes for reporting and analysis: common plus variant 1, common plus variant 2. This extends to nested subvariants and arbitary combinations of variants, e.g., space optical plus ground optical, space RF plus ground RF, excluding optical/RF combinations.
I think we have everything we need to do this now with the exception of specifying multiple variant description roots (i.e., bundles) in
build.gradle
and the nesting the resulting analysis products under the appropriate variant. This seems like a really clean way to go about it and doesn't require any new notation or vocabulary for variants per se.I suppose we could make a separate branch in git for each variant but that seems almost impossible to manage.
It might be helpful for the UI to have a perspective for each description root and hide anything not transitively imported by it. Switching perspectives is just a click.
Thoughts?
The text was updated successfully, but these errors were encountered: