Consider simplifying permissions so they can be calculated in SPARQL

[benjamingeer]

If we could calculate permissions in SPARQL, the result of a Gravsearch COUNT query would be more likely to be accurate, and Gravsearch would be less likely to return empty pages.

@lrosenth and I were talking about this and we wondered if a Unix-like permissions model, based on bitmasks, would be possible. It looks like SPARQL doesn't have bitwise operations, though.

[benjamingeer]

After thinking about this some more:

This would only be useful for read permissions. We only update one resource at a time, and we read it first anyway, so we can represent write permissions however we want.

Unix uses binary digits to represent permissions, which can then be tested using bitwise operations. Although we don't have bitwise operations in SPARQL, we could do something similar with decimal digits:

SELECT DISTINCT ?userCanRead WHERE {
    ###############################################
    # Information about the resource

    # The user associated with the resource
    BIND(<http://example.org/users/ben> AS ?resourceUser)

    # The group associated with the resource
    BIND(<http://example.org/groups/staff> as ?resourceGroup)

    # The read permissions granted by the resource:
    # 100 for user read + 10 for group read + 1 for other read   
    BIND(110 AS ?resourcePerm)

    ###############################################
    # Information about the user making the request

    # The user making the request
    BIND(<http://example.org/users/fred> AS ?user)

    # The groups that the user belongs to
    VALUES ?group { <http://example.org/groups/staff> <http://example.org/groups/editors> }

    ###############################################
    # Permission calculation
    
    # 1 if the resource grants user read permission
    BIND(FLOOR(?resourcePerm / 100) AS ?resourceUserRead)

    # 1 if the resource grants group read permission
    BIND(FLOOR((?resourcePerm - (?resourceUserRead * 100)) / 10) AS ?resourceGroupRead)

    # 1 if the resource grants other read permission
    BIND(?resourcePerm - (?resourceUserRead * 100) - (?resourceGroupRead * 10) AS ?resourceOtherRead)

    # Return a result only if the user has read permission on the resource
    FILTER((?resourceUser = ?user && ?resourceUserRead = 1) ||
        (?resourceGroup = ?group && ?resourceGroupRead = 1) ||
        ?resourceOtherRead = 1)
    
    BIND(true as ?userCanRead)
}

In this example, the user gets read permission on the resource because they belong to the group http://example.org/groups/staff, and the resource grants read permission to that group.

[benjamingeer]

Another idea: keep the existing permissions model, but redundantly store resource view permissions as triples in a separate graph, like this:

GRAPH <http://www.knora.org/resourceViewPermissions> {
    <resource> knora-admin:viewPermission <group> .
}

(We would only need them for resources, not for values.) Then Gravsearch could check these triples:

<user> knora-admin:isInGroup ?group .

GRAPH <http://www.knora.org/resourceViewPermissions> {
    ?resource knora-admin:viewPermission ?group .
}

I think it would be worth doing a test to see what sort of performance we would get.