How to create role with language limitations?

134 views
Skip to first unread message

Anne Massenkeil

unread,
Jul 8, 2025, 8:16:58 AM7/8/25
to vocbench-user
Hello,

I'd like to create different lexicographer roles with specific language capabilities. How can I define the additional language restrictions?

Thanks!
Anne 

Screenshot (28).png





stel...@uniroma2.it

unread,
Jul 8, 2025, 11:06:49 AM7/8/25
to Anne Massenkeil, vocbench-user

Dear Anne,

 

From your expression “specific language capabilities” I wasn’t sure if interpreting it as:

“specific capabilities for language”

or “capabilities for specific languages”

:-)

 

In the doubt, I try to reply to both interpretations:

 

In the first case, that is defining new capabilities that are maybe more specific than generically saying “lexicalization” (which is a sort of trigger for everything related to language modeling) you can create new roles and define for them even very specific capabilities. You may check this page:

 

https://vocbench.uniroma2.it/doc/user/roles_adm.jsf

 

listing all capabilities. In the table on section “Capabilities Vocabuary” the first row, related to RDF editing, is the relevant one for you.

 

In case you meant how to assign different languages to different users, that is not done there; it is decoupled in a different section, related to assignment of users to projects:

 

https://vocbench.uniroma2.it/doc/user/projects_adm.jsf#project-users_management

 

so, each user can be assigned to any project and from there they can be given specific roles (local to the assignment of the user to that specific project) and languages (same, the languages assigned to the user are local to that project only). The “assigned languages” are those where the user has the capability for editing their content. So, a user may be given the lexicographer role and be able to every sort of lexicalization (rdfs labels, skos labels, skos-xl labels, ontolex lexical entries..) and yet, if a given language is not assigned to them, they can’t edit those elements if the content language is in a language they are not assigned to

 

Hope this replies to your inquiry :-)

 

Armando

 

 

From: vocben...@googlegroups.com <vocben...@googlegroups.com> On Behalf Of Anne Massenkeil
Sent: Tuesday, July 8, 2025 2:17 PM
To: vocbench-user <vocben...@googlegroups.com>
Subject: [vocbench-user] How to create role with language limitations?

 

Hello,

 

I'd like to create different lexicographer roles with specific language capabilities. How can I define the additional language restrictions?

 

Thanks!

Anne 

 

 

 

 

 


This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

--
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 visit https://groups.google.com/d/msgid/vocbench-user/37c0d890-e6e1-42ba-9693-11ede4a41655n%40googlegroups.com.

image001.png

Anne Massenkeil

unread,
Jul 9, 2025, 8:18:35 AM7/9/25
to vocbench-user
Thanks so much for the quick response, Armando. I meant what you described under #2 and it worked.

Best,
Anne

Anne Massenkeil

unread,
Jul 15, 2025, 7:59:19 AM7/15/25
to vocbench-user
Hi, I had a follow up question on roles please:

In addition to configuring languages for the lexicographer role, we want to add advanced validation capabilities since reject seems to be the only validation task that is available with the out of the box-lexicographer role setting. I tried selecting "validate" ("CRUDV") at role config (see below) but it leads to the data tab being inaccessible. Is this FAD? We are using VB3.

We don't want to simply add the "validator" capabilities (rdf "RV") to the lexicographer role because the validation then becomes too broad and allows validation for all onboarded users (vs. just the users' own actions).

Screenshot_role_def.png

Another question that came up is around search functionality. I tried various wildcards (* $ ?) but none worked (get "no data found" response). We are not using GraphDB yet -- is that part of the issue?

Many thanks in advance!

Anne 
Message has been deleted
Message has been deleted
Message has been deleted

Roland Wingerter

unread,
Jul 18, 2025, 6:58:38 AM7/18/25
to vocbench-user

Hi Anne,

1. If you want a user to have lexicographer and validator capabilities, you simply assign both predefined roles to her/him (see screenshot). No need to define a new role. User rights are project-specific, and a user can have more than one role per project.

2. VB3 Search has many options, but it does not support wildcards. Check out https://vocbench.uniroma2.it/doc/user/data_view.jsf#the_search_bar.

Kind regards

Roland

Validator user.png

Roland Wingerter

unread,
Jul 18, 2025, 6:58:43 AM7/18/25
to vocbench-user
Test

Anne Massenkeil schrieb am Dienstag, 15. Juli 2025 um 13:59:19 UTC+2:

Roland Wingerter

unread,
Jul 18, 2025, 6:58:51 AM7/18/25
to vocbench-user

1. If you want a user to have lexicographer and validator capabilities, you can assign both predefined roles to her/him (see screenshot attached). Note that user rights are project-specific, and a user can have more than one role per project.

2. VB3 Search has many options, but it does not support wildcards. Check out https://vocbench.uniroma2.it/doc/user/data_view.jsf#the_search_bar.

Kind regards

Roland



Anne Massenkeil schrieb am Dienstag, 15. Juli 2025 um 13:59:19 UTC+2:
Validator user.png

stel...@uniroma2.it

unread,
Jul 18, 2025, 7:43:10 AM7/18/25
to Roland Wingerter, vocbench-user

Dear Anne,

 

follow up to Roland’s msg with some complementary information.

 

  1. we’ll look into the issue with the “V”. Actually, I’ve performed some tests and I think I found a possible mistake in your case (at least I can’t recreate your issue if I properly configure the role, so mine is only an educated guess on what you might have done wrong) but then, I got stuck on another problem.
    So, I can’t tell from your screenshot whether you created a role containing only lexicalization with CRUDV and nothing else (this was my guess). If you need to check all data, you need to have (rdf,”R”) at least in addition to anything else. My suggestion is that you clone the lexicographer role and then add only the “V” to the lexicalization capability.
    This way everything should work except that…I tried to go on the validation screen and I still can only reject, not accept. The “reject” is always available as a special option in the validation screen, that is applicable to your own actions. We added that as a way to allow everybody to check their own actions and reject them (a form of UNDO) if they discovered they made a mistake. So, modulo the reject, which is available for the explained reasons, it seems the added “V” is not having any effect. I should check whether this is a bug, or a limitation we had at the time for which validation in the case of the RDF “area” cannot be detailed to specific capabilities.
    Apologies in advance, it’s a very busy period closing various things before summer but we will try to address this at the soonest and come back to you.

 

  1. Concerning the wildcards, I confirm what Roland said. Simply, most users didn’t want to deal with wildcards and use instead a series of “prepackaged” searches working on the whole search string. However, good news is that we will add this search (it will be simply using all common search engine syntax, so all tokens will be assumed to be optional (but the more you hit the more the result goes up in the ranking), if you want the whole string you have to use “”, you can use all wildcards, Boolean expressions etc..) and it will be probably available in a major release we will do within the year.

 

Kind Regards,

 

Armando

 

 

From: vocben...@googlegroups.com <vocben...@googlegroups.com> On Behalf Of Roland Wingerter
Sent: Thursday, July 17, 2025 1:49 PM
To: vocbench-user <vocben...@googlegroups.com>
Subject: Re: [vocbench-user] How to create role with language limitations?

 

Hi Anne,

1. If you want a user to have lexicographer and validator capabilities, you simply assign both predefined roles to her/him (see screenshot). No need to define a new role. User rights are project-specific, and a user can have more than one role per project.

2. VB3 Search has many options, but it does not support wildcards. Check out https://vocbench.uniroma2.it/doc/user/data_view.jsf#the_search_bar.

Kind regards

Roland

 

Anne Massenkeil schrieb am Dienstag, 15. Juli 2025 um 13:59:19 UTC+2:

Hi, I had a follow up question on roles please:

In addition to configuring languages for the lexicographer role, we want to add advanced validation capabilities since reject seems to be the only validation task that is available with the out of the box-lexicographer role setting. I tried selecting "validate" ("CRUDV") at role config (see below) but it leads to the data tab being inaccessible. Is this FAD? We are using VB3.

We don't want to simply add the "validator" capabilities (rdf "RV") to the lexicographer role because the validation then becomes too broad and allows validation for all onboarded users (vs. just the users' own actions).

 

stel...@uniroma2.it

unread,
Jul 18, 2025, 2:52:06 PM7/18/25
to Roland Wingerter, vocbench-user

Dear Anne,

 

quick follow up to my earlier msg. I can confirm that, unfortunately, it is a known limitation (sorry for having to investigate, but it’s something deep buried in the past).

At the moment the validation operation can’t be broken up among the single capabilities (even if the capability/roles editor allows for that). Enabling it is not a piece of cake and, in these years, it never came as a request, so we addressed many other priorities.

 

While I’m not excluding that we will address this in the future, I’m looking at possible alternative directions: One thing that I’m not sure of is whether you are aiming at a user that can validate themself (basically as an exception to the normal validation, which you still want, otherwise you would simply not use validation for the project).

If that is the case, then a possible alternative is to simply allow for an exception to the validation for some users (i,e some users are considered real experts and simply skip the validation process, which still stays in place for all other users)

Anne Massenkeil

unread,
Jul 29, 2025, 10:16:10 AM7/29/25
to stel...@uniroma2.it, Roland Wingerter, vocbench-user
Thank you for your responses, Armando and Roland! 

Armando, while it would be great if the limitation can be lifted in a future release, I'll try some of the suggested workarounds.

BR,
Anne

anne massenkeil
lead knowledge engineer | implementation manager
anne.ma...@randstad.com
logo


You received this message because you are subscribed to a topic in the Google Groups "vocbench-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vocbench-user/B61Bi_uCX1U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vocbench-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/034e01dbf815%2403e7dbd0%240bb79370%24%40uniroma2.it.

Anne Massenkeil

unread,
Dec 3, 2025, 3:55:18 PM12/3/25
to vocbench-user
Dear Armando,

We are in the process of onboarding a number of new users and another permissions question came up.

We are using the role of Lexographer which has preset CRUD capabilites for the "lexicalization" and "notes" areas. Is there a workaround to implement vertical access control—whereby users can edit only the leaves but not the nodes? 

Ideally, within the lexicalization area, the users have permission to edit the most granular child concepts but not any of the broaders.

For example, would it be possible to create two parallel concept schemes to segment taxonomy nodes from leaves? Could the lexographer role then be customized to allow read permissions for one scheme and CRUD permissions for the second scheme?

Thanks,
Anne



stel...@uniroma2.it

unread,
Dec 3, 2025, 5:33:19 PM12/3/25
to Anne Massenkeil, vocbench-user

Dear Anne,

 

you can do that, with some configuration. It’s not possible to predicate in general that lexicographers are limited to leaf nodes.

However, you can:

  1. like you said, associate leaf nodes to a given concept scheme (you can do that programmatically with a SPARQL update, then you will need to keep that updated if you change your taxonomy structure or periodically run maintenance UPDATEs)
  2. use the group feature of VocBench to associate your lexicographers with a group you create expressly for this, express that they are subject to scheme/group restrictions and associate the group with the said concept scheme
    https://vocbench.uniroma2.it/doc/user/groups_adm.jsf
    https://vocbench.uniroma2.it/doc/user/projects_adm.jsf#project-groups_management

Kind Regards,

 

Armando

 

Anne Massenkeil

unread,
Dec 3, 2025, 6:26:46 PM12/3/25
to stel...@uniroma2.it, vocbench-user
Thanks for the quick response! 


anne massenkeil
lead knowledge engineer | implementation manager

Baran Barbarestani

unread,
Jan 22, 2026, 3:10:14 AM (7 days ago) Jan 22
to vocbench-user

Dear Armando,

I am reaching out to clarify an issue we are encountering in VocBench when working with a SKOS-based taxonomy.

Context:

  • Our taxonomy is entirely SKOS, and we deliberately avoid any OWL reasoning or interpretation in the RDF/TTL we upload.

  • We currently maintain a hierarchical structure with six levels (L1–L6). Each concept level contains concepts linked via skos:broader and skos:narrower.

  • Levels 1 and 6 are special:

    • Level 1 concepts are top concepts (they have no skos:broader).

    • Level 6 concepts are leaf concepts (they have no skos:narrower).

Implementation Attempt:

  • We attempted to organize each level into a separate SKOS ConceptScheme (L1 → Scheme1, L2 → Scheme2, … L6 → Scheme6) and maintain the hierarchy with skos:broader/skos:narrower across schemes.

  • This approach consistently triggers an OWL error upon upload to VocBench (resource 'http://www.w3.org/2002/07/owl#Thing' does not exist in the current dataset).

  • We have verified that the error persists even though the broader/narrower links for top/leaf concepts are empty. They exist structurally, but simply point to nothing for L1/L6, which is correct in SKOS.

Observed Behavior:

  • When we limit the structure to two schemes only (e.g., one for Levels 1–5, one for Level 6), the upload succeeds and no OWL errors occur.

  • Our assumption is that VocBench does not support more than two ConceptSchemes in a hierarchy if there are skos:broader/skos:narrower links crossing schemes, even in pure SKOS without OWL.

Question:

  • Is it correct that VocBench cannot handle more than two ConceptSchemes in a hierarchical SKOS taxonomy without triggering OWL errors?

  • If so, can you explain the underlying reason or limitations?

We would like to maintain our SKOS-only hierarchy with top and leaf concepts properly defined, but we want to ensure we do not introduce OWL violations or errors in VocBench.

Thank you for your guidance on this matter.

Best regards,

Baran Barbarestani
Taxonomy Analyst
baran.bar...@randstad.com
logo

stel...@uniroma2.it

unread,
Jan 22, 2026, 3:58:23 AM (7 days ago) Jan 22
to Baran Barbarestani, vocbench-user

Dear Baran,

 

thank you for the detailed explanation. It’s indeed a particular thing but, I’ve some (not so) bad news and some good news:

  1. Bad news is that if the error is consistently thrown for the right reason (missing owl:Thing), I’ve no idea how your dataset came to that status unless somebody tinkered low level with your data (e.g. by switching the working graph and deleting owl:Thing)
  2. Good news is that if this is confirmed to be an exception, it suffices to “reset” the situation or to fix it. None of the constraints you asked for applies

 

More in details:

 

The error, basically, should be thrown because the resource owl:Thing is not found. Now, upon creating a project, all core modeling vocabularies (RDF, RDFS, OWL and then others depending on the type of project, such as: SKOS, SKOS-XL, Ontolex-Lemon) are loaded into the repository, so the resource should be there because owl:Thing is part of the OWL vocabulary. The resource is read-only, so it shouldn’t be possible to remove it with a basic usage of VB. One way that comes to my mind is, as I mentioned earlier, to switch the working graph (https://vocbench.uniroma2.it/doc/user/global_data_management.jsf#change_working_graph ) to OWL and then explicitly remove it. Not all users can change the working graph (see details in the page). Another possibility is a nasty SPARQL UPDATE (again, something low level, which not all users can do) that deleted the OWL graph or at least the owl:Thing resource.

Other ways for which it might be missing include the full graph

 

Now, a first question to assess the situation: could you go to the “Class” tab and check whether you can see the owl:Thing resource (should be at the top) and, if you click on it, does the resource view open on it without any issue?

If you have any particular situation diverging from it, pls post a screenshot and give us some description of what happens.

 

Another question is: you mentioned uploading: what did you do “outside of VB” and how are you uploading the data? Cause another possibility is that you did lot of modifications to your dataset out of VB and in uploading you simply uploaded inconsistent data. Additional culprits include tinkering with the data directly in the triple store (if it is separated from VB). I mean, if you do things right, you can hack a project and its repo as you want, but the possibility to break something obviously increase.

 

And to confirm on your questions: as explained earlier, none of the constraints and the hypotheses described under your section “Observed Behavior” apply; in VB you can have as many concept schemes as you want (e.g. EuroVoc has tenths of them and is regularly maintained in VB by the European Commission)

 

Kind Regards,

 

Armando

 

The information contained in this e-mail communication is solely intended for the person/legal person to whom it  has been sent, and as it may contain information of a personal or confidential nature, it may not be made public by virtue of law, regulations or agreement. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to inform the sender of this e-mail message of this immediately, and to destroy the original e-mail communication. Neither Randstad N.V. nor its subsidiaries accept any liability for incorrect and incomplete transmission or delayed receipt of this e-mail. Randstad N.V. HR Amsterdam no.33216172

--
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.

Baran Barbarestani

unread,
Jan 22, 2026, 7:30:47 AM (7 days ago) Jan 22
to vocbench-user

Dear Armando,

Thank you for your previous guidance. I would like to provide an update and seek further clarification.

Observation:

  • We are still experiencing the owl:Thing error in VocBench.

  • This occurs even in freshly created projects with a clean SKOS upload.

  • Importantly, the error also appears when the hierarchy is limited to just two ConceptSchemes, contrary to our initial assumption that multiple schemes were the cause.

  • Initially, everything appears fine upon project creation and upload, but after some hours/minutes, the project crashes, and owl:Thing becomes unclickable.

Verification steps taken:

  1. Confirmed that owl:Thing is present in the Class tab.

  2. The resource view does not open when clicked, even though it exists.

  3. No low-level modifications (SPARQL updates, working graph switches, or manual deletions) have been made.

  4. The data uploaded is pure SKOS with proper skos:broader/skos:narrower links, top concepts, and leaf concepts.

Upload method:

  • All SKOS TTL files are uploaded using the standard VocBench loadRDF API via our Python script.

  • No manual editing or external triple store manipulations are performed.

Given this behavior, it seems that the crash is triggered internally by VocBench over time, even with correct SKOS files and only two ConceptSchemes.

Could you please advise:

  1. Whether this is a known VocBench stability issue for SKOS hierarchies?

  2. Any recommended workarounds to prevent the project from crashing over time?

Thank you for your guidance.

Kind regards,

Baran Barbarestani
Taxonomy Analyst
baran.bar...@randstad.com
logo

Baran Barbarestani

unread,
Jan 26, 2026, 7:20:39 AM (3 days ago) Jan 26
to vocbench-user

Dear Armando,

I hope you are doing well.

I just wanted to follow up on my previous message, as we are still experiencing the issue and it is currently blocking further work on our taxonomy.

To briefly recap the situation:

  • The owl:Thing error appears even in freshly created VocBench projects.

  • The uploaded data is pure SKOS, uploaded exclusively via the standard loadRDF API.

  • No low-level operations (SPARQL UPDATEs, working graph changes, or manual deletions) have been performed.

  • The project initially loads and works correctly, but after some time (minutes or hours), the UI crashes and owl:Thing becomes unclickable.

  • The behavior is reproducible and also occurs when using only two ConceptSchemes.

At this point, the evidence suggests that the issue may be triggered internally by VocBench over time rather than by the uploaded data itself.

Could you please let us know:

  • Whether this is a known stability issue, or

  • If there are any additional diagnostics or logs we could provide to help investigate this further?

Thank you again for your time and support. Any guidance would be greatly appreciated.

Kind regards,
Baran Barbarestani
Taxonomy Analyst
baran.bar...@randstad.com
logo


stel...@uniroma2.it

unread,
Jan 26, 2026, 1:43:26 PM (2 days ago) Jan 26
to Baran Barbarestani, vocbench-user

Dear Baran

 

At this point it’s hard to say, we never had any issue with that. A few questions more could help:

 

  1. You upload the pure SKOS via API and you said this happened even on a fresh project. Just to be sure no parameter combination (being paranoid but..when there’s nothing left to try) did you try loading the SKOS manually?
  2. owl:Thing is indeed hard-wired to be seen in the tree, yet the fact you can’t open it seems to reveal that the owl vocabulary is missing. Can you perform the two actions here below?
    1. take a screenshot of the class panel
    2. run the following sparql query

      SELECT distinct ?g (count (?s) as ?subjects) WHERE {

                                             graph ?g {

       ?s ?p ?o .

                                             }

}

group by ?g

  1. sorry if I already asked: which VB version you have and which triple store you are using? (RDF4J or GDB?, internal or external?)
  2. otherwise, we can only help by giving a look at the data…which is a little out of the scope of this list but if it really keeps like a bug (even though I fear it might more be an environment issue as we never had such issues nor we heard them reported by anybody…)

 

Kind Regards,

 

Armando

 

 

From: 'Baran Barbarestani' via vocbench-user <vocben...@googlegroups.com>
Sent: Monday, January 26, 2026 1:21 PM
To: vocbench-user <vocben...@googlegroups.com>
Subject: Re: [vocbench-user] How to create role with language limitations?

 

Dear Armando,

I hope you are doing well.

1.     Confirmed that owl:Thing is present in the Class tab.

2.     The resource view does not open when clicked, even though it exists.

3.     No low-level modifications (SPARQL updates, working graph switches, or manual deletions) have been made.

4.     The data uploaded is pure SKOS with proper skos:broader/skos:narrower links, top concepts, and leaf concepts.

Upload method:

·        All SKOS TTL files are uploaded using the standard VocBench loadRDF API via our Python script.

·        No manual editing or external triple store manipulations are performed.

Given this behavior, it seems that the crash is triggered internally by VocBench over time, even with correct SKOS files and only two ConceptSchemes.

Could you please advise:

1.     Whether this is a known VocBench stability issue for SKOS hierarchies?

2.     Any recommended workarounds to prevent the project from crashing over time?

Reply all
Reply to author
Forward
0 new messages