Minutes 2021-04-28

[matthieubosquet]

These probably could use a bit of improvement.

[bblfish]

I have refactored the discussion into a more dialogical form, filled out comments I made, and linked to examples I posted over the past few months which I alluded to in the conversation, but did not have time to fill in.
Does that still work for you @matthieubosquet ?
For those wishing to get the final version without too much diff clutter I suggest reading it here:
https://github.com/solid/authorization-panel/blob/minutes-2021-04-28/meetings/2021-04-28.md

[matthieubosquet]

@bblfish I'm not sure you can assert the statement that is part of the object property chain.

If:

SubObjectPropertyOf( ObjectPropertyChain( :hasFather :hasBrother ) :hasUncle ) 

:x :hasFather :y .
:y :hasBrother :z .
# Then
:x :hasUncle :z .

However, I don't think (and didn't find example of in the OWL 2 syntax of) infering the property chain predicate. And I think it is deliberate (I might be wrong).
Let's imagine for a second that:

:x :hasFather :y .
:x :hasUncle :z .
# It could be that:
:x :hasMother :w .
:w :hasBrother :z .
# And then
SubObjectPropertyOf( ObjectPropertyChain( :hasMother :hasBrother ) :hasUncle ) 
# Therefore
:x :hasUncle :z .
# (but :y :does_not_have_brother :z)

So just to confirm, the following axiom is incorrect:

:authorizes owl:inverseOf [
    owl:propertyChainAxiom(acl:accessControl acl:accessTo)
]

Instead what we're proposing to assert here is the acl:accessTo relationship via the following axiom:

acl:accessTo owl:inverseOf [
        owl:propertyChainAxiom ( acl:accessControl :authorizes )
      ] .

(which relies on the not yet existing :authorizes predicate).
Is this correct?

[bblfish]

For those following here, I recommend looking at the OWL 2 Primer §Property Chain section. You can get the Turtle version of each code snippet if you go to the top of the page and click a "Turtle Syntax" button. That will give you the definition for :hasGrandparent in Turtle as:

:hasGrandparent  owl:propertyChainAxiom  ( :hasParent  :hasParent ) .

(It is annoying that one cannot pass that decision around as a URL and I sent a mail to the semantic-web mailing list reporting that.)

We also have the definition given in OWL2 RDF Based Semantics.

I was working with this picture in mind:

But I wrote it out too quickly and got the order of the relations wrong.

:authorizes owl:inverseOf [
    owl:propertyChainAxiom  (acl:accessTo :accessControl )
]

But it is still a good question whether even that is correct.
And indeed the following does not look right:

I can follow the :accessTo link from <fake.acl> follow the :accessControl relation from there and that does not give me the :authorizes link that gives Control rights I started off with.

So yes, I should go back to the original proposal I made:

acl:accessTo owl:inverseOf [
        owl:propertyChainAxiom ( acl:accessControl :authorizes )
      ] .

[bblfish]

The above is a very good example of why we want to build on formally specified languages such as OWL, as it allows one to make precise arguments as @matthieubosquet just made above.

[matthieubosquet]

I can follow the :accessTo link from <fake.acl> follow the :accessControl relation from there and that does not give me the :authorizes link that gives Control rights I started off with.

I'm not sure I see why the :authorizes statement cannot be inferred using that graph and the previous axiom.

# If
ex:authorization1 acl:accessTo ex:resource .
ex:resource acl:accessControl <card.acl> .
# Then
<card.acl> :authorizes ex:authorization1 .
# Could we not also say
<fake.acl#authorization2> acl:accessTo ex:resource .
# Therefore
<card.acl> :authorizes <fake.acl#authorization2> .
# ?

[bblfish]

If I understand you correctly you have this picture in mind, where I have labelled the nodes.
The mapping from your code is
ex:authorization1 -> a1
ex:resource -> r
<fake.acl#authorization2> -> a2

So I was trying to say that with the improved but still rejected rule

:authorizes owl:inverseOf [
    owl:propertyChainAxiom  (acl:accessTo :accessControl )
]

we then get (inferred) the red dotted line representing <card.acl#> :authorizes <fake.acl#a2> which is not what is desired.
That would make it easy to create fake authorizations.

But that no longer follows from the rule originally proposed

acl:accessTo owl:inverseOf [
        owl:propertyChainAxiom ( acl:accessControl :authorizes )
      ] .

[matthieubosquet]

Thanks Henry, that makes sense. So, to summarize:

• The axiom allowing inference of the acl:accessTo statement seems safe
• The axiom allowing inference of the acl:authorizes statement is not safe because it introduces a problem in controlling the boundaries of the authorization graph applying to a resource X.

Given a set of server managed statements (by that I mean statements that "lawfully" belong in the authorization graph or in other words, assuming that the statements in the form :x acl:accessTo :y . are all part of the authorization graph and apply to the resource already), the acl:authorizes inferrence axiom could be used.

Therefore, it seems unlikely the axiom for inferring acl:authorizes could be used in production to maintain a compatibility layer, it may in certain circumstances be used to migrate from one authorization system to the other.

[bblfish]

Ah, thanks. What I thought was a mistake might have a use after all!

So yes, to first address your second bullet point, the rule for inferring :authorizes

:authorizes owl:inverseOf [
    owl:propertyChainAxiom  (acl:accessTo :accessControl )
]

could be used by new clients (ACP, WAC+, whatever...) on existing deployments. Or at least it allows us to see how existing deployments fit in with the proposal for an :authorizes relation.
Existing deployments do not show the :authorizes relation, but it is as if there always had been one such relation from the document to each Authorization. I.e. they could infer the blue dotted lines below.

But as shown in our previous comment, it is essential for the Authorization nodes to appear inside the document linked to by the acl:accessControl header. So there has to be some context around the :authorizes rule above that makes that clear. That could be done in N3, and perhaps there is a better construct than propertyChainAxiom to express it.

To your first bullet point, the rule for accessTo is on the other hand completely general.

acl:accessTo owl:inverseOf [
        owl:propertyChainAxiom ( acl:accessControl :authorizes )
      ] .

It can be used to help clients written for the acl ontology to continue making sense of servers producing ACP, WAC+ or whatever we come up with, by injecting the new acl:accessTo triple in the Graph before the UI ACL code gets to run, as illustrated in issue 184.

In any case both of these rules help show how the two systems relate, and increase our understanding of what is going on.

[matthieubosquet]

Henry, out of curiosity, what do you use for those graphs?
It's quite handy and you seem very quick to make them.

[bblfish]

I have been using Omnigraffle for close to 16 years now.
(I am not sure if there are new better tools out there)