fix: redefine "public" and "private"

[jnussbaum]

No description provided.

[Nora-Olivia-Ammann]

Based on what decision did you change this definition?

[jnussbaum]

Based on what decision did you change this definition?

Based on my experience, what people most often want when they use the terms "public" / "private". This code change doesn't have a direct impact, it's rather like a default, that can be used or overwritten on a per-project-basis.

[BalduinLandolt]

Looks reasonable to me. Are these changes in line with what we have most commonly in the database? Is the PRIVATE one the same as the current default DOAPs used by the API for new projects? Because this is currently our "canonical definition of private". And does this align with what RDU wants?

[jnussbaum]

Looks reasonable to me. Are these changes in line with what we have most commonly in the database? Is the PRIVATE one the same as the current default DOAPs used by the API for new projects? Because this is currently our "canonical definition of private". And does this align with what RDU wants?

Thanks for your input. Unfortunately, your questions have different contradictory answers ;-)

1. What is most commonly in the database (stage)?

There are more than 20 different public-ish permissions. One among them is far on top (much more frequent than the others): CR knora-admin:Creator,knora-admin:ProjectAdmin|D knora-admin:ProjectMember|V knora-admin:KnownUser,knora-admin:UnknownUser. Therefore, I have now adapted this PR so that this becomes the new PUBLIC.

For private-ish, there are 3 candidates:

• 50'000 times: CR knora-admin:ProjectAdmin|D knora-admin:Creator|M knora-admin:ProjectMember
• 30'000 times: CR knora-admin:ProjectAdmin|D knora-admin:Creator,knora-admin:ProjectMember
• 8'000 times: CR knora-admin:ProjectAdmin|M knora-admin:ProjectMember

2. What is the default DOAP for private that the API sets?

Surprisingly, the default private DOAP is the one that appears the least frequent on stage: CR knora-admin:ProjectAdmin|M knora-admin:ProjectMember (8'000 times). But since it is the default, I have now adapted the PR so that this becomes the new PRIVATE.

3. What does RDU want?

Since they don't care about permissions at such a low level, I had the following approach until now: Every time I had to do a permissions change, I translated the high-level instructions ("private" / "public") into something that seemed reasonable to me, and then checked back with RDU. Mostly, they just accepted what I suggested to them. But it also depends from case to case. So this question cannot really be answered.

4. What makes sense?

According to my gut, PUBLIC is now quite sensible. However, I think that PRIVATE should rather be changed to CR knora-admin:ProjectAdmin,knora-admin:Creator|D knora-admin:ProjectMember, although this never appears in the database.

[BalduinLandolt]

Looks reasonable to me. Are these changes in line with what we have most commonly in the database? Is the PRIVATE one the same as the current default DOAPs used by the API for new projects? Because this is currently our "canonical definition of private". And does this align with what RDU wants?

Thanks for your input. Unfortunately, your questions have different contradictory answers ;-)

1. What is most commonly in the database (stage)?

There are more than 20 different public-ish permissions. One among them is far on top (much more frequent than the others): CR knora-admin:Creator,knora-admin:ProjectAdmin|D knora-admin:ProjectMember|V knora-admin:KnownUser,knora-admin:UnknownUser. Therefore, I have now adapted this PR so that this becomes the new PUBLIC.

For private-ish, there are 3 candidates:

* 50'000 times: `CR knora-admin:ProjectAdmin|D knora-admin:Creator|M knora-admin:ProjectMember`

* 30'000 times: `CR knora-admin:ProjectAdmin|D knora-admin:Creator,knora-admin:ProjectMember`

* 8'000 times: `CR knora-admin:ProjectAdmin|M knora-admin:ProjectMember`

👍

2. What is the default DOAP for private that the API sets?

Surprisingly, the default private DOAP is the one that appears the least frequent on stage: CR knora-admin:ProjectAdmin|M knora-admin:ProjectMember (8'000 times). But since it is the default, I have now adapted the PR so that this becomes the new PRIVATE.

Considering how much easier it is to create numerous resources with dsp-tools (where other permissions may be provided) than with the app, this may not be as surprizing.
The two top candidates, were they promoted by dsp-tools in some way? (e.g. an XML template, docs, etc.) In that case, I suppose the numbers would make perfect sense.

3. What does RDU want?

Since they don't care about permissions at such a low level, I had the following approach until now: Every time I had to do a permissions change, I translated the high-level instructions ("private" / "public") into something that seemed reasonable to me, and then checked back with RDU. Mostly, they just accepted what I suggested to them. But it also depends from case to case. So this question cannot really be answered.

I asked the wrong question anyways - the right question would be "what do the projects want?" but the same would apply there, I guess.
As long as it doesn't functionally violate the customer's behavioural expectations, that approach makes sense, though some standardization will be nice to have.

4. What makes sense?

According to my gut, PUBLIC is now quite sensible. However, I think that PRIVATE should rather be changed to CR knora-admin:ProjectAdmin,knora-admin:Creator|D knora-admin:ProjectMember, although this never appears in the database.

Giving CR to Creator sounds reasonable, but I think sticking to the current default for now is also a good idea. In the end, the permissions system has to change over time anyways, so we will have to see what we make form all this...

[jnussbaum]

The two top candidates, were they promoted by dsp-tools in some way? (e.g. an XML template, docs, etc.)

I cannot find the source of these:

• neither https://github.com/dasch-swiss/082E-rosetta-scripts/blob/main/rosetta.xml
• nor https://docs.dasch.swiss/latest/DSP-TOOLS/file-formats/xml-data-file/#complete-example
• nor https://github.com/dasch-swiss/dsp-tools/blob/7f9928794a680b0a417a8a4f603cbac4ac4df2bd/src/dsp_tools/commands/excel2xml/excel2xml_lib.py#L400

But it doesn't matter that much. I guess that these permissions really stem from dsp-tools, even if I cannot reconstruct the exact way how they came into being.

More importantly: I will tend for the standardized way, and merge this PR as is. Thanks for your thoughts 👍