-
Notifications
You must be signed in to change notification settings - Fork 2
increased granularity of access control
- at the level of properties in a concept
- at the level of concepts
- at the level of a branch
Potentially, a property where the filler value is a user name could be used to restrict editing of concepts or properties by annotating a class, or an annotation value, respectively. To restrict editing of an entire branch, we could introduce an inheritable value restriction on the class where the filler value is again a username.
A use case that would need to be met, though, is to be able to support editing by a backup person when the editor owning the property/class/branch is unavailable. Roles (or maybe individual operations) in the metaproject could be created so that editors that belong to that group (e.g. CanEditCDISCDEFS) would all have the same level of access. Another possible solution could instead involve property ranges and creation of datatypes; this might not eliminate editing of the metaproject but could help by not increasing its complexity unnecessarily.
Increased granularity will not be a target, instead, we will try to recapitulate the Def_Curator behavior. The setup will be along the lines:
annotationProperty_X declaration: add annotation "restricted_by" annotationProperty_Y complete later: annotationProperty_Y range: datatype-enum includes u