Restricting access a certain property for certain roles ?

[Thomas Francart]

Hello

Assume I have 3 distinct user groups : editors, "business validators", "main validators".

I would like to have 2 steps in the validation workflow :

• editors propose new entries
• business validators are doing a first-level of validation by e.g. setting a custom property/flag on the concept (like "reviewed = true"); they know the business but cannot garantee the integrity of the complete vocabulary, hence they don't have access to the validation feature in VB
• then "main validators" use the validation mechanism to validate (in the VB sense) modification, but only after the property/flag has been set in the previous step.

My question is : is it possible to restrict the access to the custom property/flag so that "editors" role cannot add/modify it ?

In other words is it possible to assign per-property accesses with VB capabilities ?

Reading http://vocbench.uniroma2.it/doc/user/roles_adm.jsf it seems it is *not* possible - could you confirm ?

Could the use of a custom form to set this flag specifically, and giving access to this custom form, be a workaround for this ? (I don't know if per-custom-form capabilities can be assigned)

Any other workaround that could be used to implement this use-case ?

Thanks !

Thomas

--

Thomas Francart - SPARNA
Web de données | Architecture de l'information | Accès aux connaissances
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

[Armando Stellato]

Dear Thomas,

 

by first, happy new year to you and everybody in the list! (this is the first msg of the year if I didn’t miss any)

 

Yours is an interesting use case. I see a few things to be done to implement what you say, a potential trick for now…and some issues (not in your view, rather considering the approach of VB at validation) for which I would implement it differently.

 

Let’s check them one by one:

 

1. Restricting modeling on some properties. Currently we have capabilities associated (and thus authorizations which can be scoped) to specific areas, e.g. ontology (merely OWL) editing, thesaurus editing (SKOS), lexicalization (any sort of lexicalization, be it RDFS, SKOS, SKOS-XL, Ontolex, or even made more specific for only some of them), and sub-areas (e.g. hierarchy in OWL, hierarchy in SKOS) etc… so far so good, there is much dynamism in the editing of capabilities and composition of roles, but we don’t have the possibility to tailor the editing capability to specific properties. Indeed, given the above approach, and not willing to break what already done, we should introduce sort of exceptions, so that some props (or other aspects of modeling) can get out of the above (currently, an ontology editor can use any property) and require special capabilities.
1. What you can do: depending on your scenario, you might have your users not in need of using custom/domain properties. I tested (I didn’t recall our choices for that role) the thesaurus role and unfortunately it allows for any domain property to be used, while not allowing for any work on predicates, such as defining a class, its superclasses, etc… However, you could compose these roles in details yourself by listing exactly what they can do (e.g. type definition, lexicalizations, hierarchy,..), thus not including generic property editing. Then you would make the business validators thesaurus editors (or higher) so that they could use any domain property
2. Another trick is the use of groups (http://vocbench.uniroma2.it/doc/user/groups_adm.jsf ). This case requires the special property to be actually the membership to a specific scheme. The idea is that all users would be put in a group which can edit the normal scheme. They would not have the power to associate then the concepts to other schemes. Instead, all business validators would have no restriction. The scheme would then be the scheme of all business-validated concepts. I need to test it but it could work.
2. Custom form are currently not per-user. They are assumed to be the standard (well…custom :-P but standard for that project) way to create a (certain kind of) resource in a given project. I would, however, not follow this path. CFs are meant to facilitate editing and are in no way related to authorizations.
3. We have then another aspect, which I think is the main issue here. As you already know, VB has a per-commit isolation of validation actions; in order to avoid any limitation, it doesn’t have a resource-wise validation. So the actions to be validated could be of any type, even mass editing performed via SPARQL by a properly authorized user. A property to be attached to a resource would imply falling back to the resource-wise validation that we prefer to avoid.

 

Given point 3, from my perspective, and besides any temporary trick one could  use and thus thinking of improvements to be developed, I would rather introduce a 2-step validation (or, at this point, in order to stay flexible, a customizable n-point validation), with assignable capabilities for different levels. What do you think?

 

Cheers,

 

Armando

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7XiXcF8BwJ34X0wam7WS17rDjT%3DQcDJ063Na_SUU6WGGQ%40mail.gmail.com.

[Thomas Francart]

Hello Armando

Thanks

Le lun. 2 janv. 2023 à 18:37, Armando Stellato <stel...@uniroma2.it> a écrit :

Dear Thomas,

 

by first, happy new year to you and everybody in the list! (this is the first msg of the year if I didn’t miss any)

 

Yours is an interesting use case. I see a few things to be done to implement what you say, a potential trick for now…and some issues (not in your view, rather considering the approach of VB at validation) for which I would implement it differently.

 

Let’s check them one by one:

 

1. Restricting modeling on some properties. Currently we have capabilities associated (and thus authorizations which can be scoped) to specific areas, e.g. ontology (merely OWL) editing, thesaurus editing (SKOS), lexicalization (any sort of lexicalization, be it RDFS, SKOS, SKOS-XL, Ontolex, or even made more specific for only some of them), and sub-areas (e.g. hierarchy in OWL, hierarchy in SKOS) etc… so far so good, there is much dynamism in the editing of capabilities and composition of roles, but we don’t have the possibility to tailor the editing capability to specific properties. Indeed, given the above approach, and not willing to break what already done, we should introduce sort of exceptions, so that some props (or other aspects of modeling) can get out of the above (currently, an ontology editor can use any property) and require special capabilities.

Maybe the Prolog-like implementation of capabilities could allow to express property-specific capabilities, without breaking what is already done ? (seeing a property-specific capability as a more fine-grained capability than the generic "rdf" one)

 

1. What you can do: depending on your scenario, you might have your users not in need of using custom/domain properties. I tested (I didn’t recall our choices for that role) the thesaurus role and unfortunately it allows for any domain property to be used, while not allowing for any work on predicates, such as defining a class, its superclasses, etc… However, you could compose these roles in details yourself by listing exactly what they can do (e.g. type definition, lexicalizations, hierarchy,..), thus not including generic property editing. Then you would make the business validators thesaurus editors (or higher) so that they could use any domain property

This solution looks promising. If I understand correctly, I could define a role "editor" with the capability to create/update/delete only thesaurus properties (labels, notes, notation), and create/update/delete the hierarchical+related links, but don't allow them to create/update/delete generic properties ?

That could do the trick.

 

2. Another trick is the use of groups (http://vocbench.uniroma2.it/doc/user/groups_adm.jsf ). This case requires the special property to be actually the membership to a specific scheme. The idea is that all users would be put in a group which can edit the normal scheme. They would not have the power to associate then the concepts to other schemes. Instead, all business validators would have no restriction. The scheme would then be the scheme of all business-validated concepts. I need to test it but it could work.

this one is rather convoluted, and would change the structure of the data when exported.

 

1. Custom form are currently not per-user. They are assumed to be the standard (well…custom :-P but standard for that project) way to create a (certain kind of) resource in a given project. I would, however, not follow this path. CFs are meant to facilitate editing and are in no way related to authorizations.

OK !

 

2. We have then another aspect, which I think is the main issue here. As you already know, VB has a per-commit isolation of validation actions; in order to avoid any limitation, it doesn’t have a resource-wise validation. So the actions to be validated could be of any type, even mass editing performed via SPARQL by a properly authorized user. A property to be attached to a resource would imply falling back to the resource-wise validation that we prefer to avoid.

I understand; the perspective of what I call "business validators" in my scenario is however resource-based : they would look at a proposed/modified resource, and confirm that the proposed addition or change *on this resource* is OK from a business point of view. They don't care about commits. Maybe they don't know what a commit is.

 

 

Given point 3, from my perspective, and besides any temporary trick one could  use and thus thinking of improvements to be developed, I would rather introduce a 2-step validation (or, at this point, in order to stay flexible, a customizable n-point validation), with assignable capabilities for different levels. What do you think?

That would definitely be an elegant and I guess useful additional feature.

I think property-based capabilities could still be useful (in other scenarios maybe) :-)

Cheers

Thomas