-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restrict acl:mode, accessToClass, agentClass range definition in ontology #187
Comments
https://github.com/solid/web-access-control-spec#authorization-schema has clear way of restricting valid values using ShEx cl:mode [acl:Read acl:Write acl:Control]+ ; |
In WAC the ontology is the primary normative document we always worked from. Furthermore, as shown in the discussion of The ACL ontology allows new
Indeed, the |
Cool. Nice try. Please read the whole section.. starting with the very first sentence:
I've accepted the PR solid/web-access-control-spec#77 from Eric (which you were also a participating in) conditionally. |
I don't see how that helps with case suggested by your previous statement:
One could still use [] rdf:type owl:AllDisjointClasses ;
owl:members ( acl:Access ex:FlyingSaurcers ) . In other words I don't think it can address solid/specification#169 while a Data Shape, ether ShEx or SHACL, does. I don't have objections to having suggested OWL restriction added to the vocab. I just don't see where it would come useful. |
While we are at it we could also fix acl:accessToClass a rdf:Property;
:comment "A class of information resources to which access is being granted.";
:domain acl:Authorization;
:label "to all in";
:range :Class .
acl:agentClass a rdf:Property;
:comment "A class of persons or social entities to being given the right";
:domain acl:Authorization;
:label "agent class";
:range :Class . But it would be more correct for them to be: acl:accessToClass rdf:range [ a owl:Restriction ;
owl:onProperty :subClassOf ;
owl:hasValue ldp:Resource
] .
acl:agentClass rdf:range [ a owl:Restriction ;
owl:onProperty :subClassOf ;
owl:hasValue foaf:Agent
] . |
Good.
It allows us to think more clearly about modeling issues. |
And in initial comment here
In on of later comments
I just want to make sure that we all are on the same page. Neither Even if we use class defined using I don't think we can say that data shapes definitions are more restrictive and RDFS (range & domain) are less restrictive. The later have nothing to do with restricting valid values so we can't directly compare them. |
I disagree that those do not restrict anything.
This set includes the numbers {0, 3, 6, 9, ... }.
from which we can infer that But what the proposed change would allow us to conclude is that :Tr :subClassOf acl:Access. which is false, since a set of numbers is not an access mode. Indeed there is no interpretation where we have a reasonable definition of So for people who value true statements, that means that the second option is out of bounds. This restriction is very helpful, even if it is not fully automatiseable: for one it helps make the intent of the ontology clearer. For example it makes it clear that The non-normative ShEx on the other hand state that <#authShape> {
acl:mode [acl:Read acl:Write acl:Control]+ ;
} which does restrict that objects of Note: I am not to here taking a position on whether or not one should add new access modes. |
I think it is fine to infer that That would be simply expressed by amending the ACL ontology statement @bblfish I believe that your proposed change would actually mean that |
ok, great! That is the main thing I was hoping to get agreement on.
I had considered that but the problem I think is that the range of acl:Read a :Class;
:comment "The class of read operations";
:label "read"@en;
:subClassOf acl:Access . So if you look at how foaf:knows is defined foaf:knows a rdf:Property,
owl:ObjectProperty;
:domain foaf:Person;
:range foaf:Person. Then you use it like this: <#Jim> a foaf:Person.
:i foaf:knows <#Jim>. Here the object of the above So what I was hoping to say with acl:mode :range [ a owl:Restriction ;
owl:onProperty :subClassOf ;
owl:hasValue acl:Access
] . is that the range of
I think I have it right, but I think it definitely needs careful checking. Looking at the primer with Turtle descriptions enabled (must be done manually). |
Therefore if you say
So similarly, if you say I guess what you're talking about might be inferring I don't see the text in the OWL 2 primer that suggests you can use blank nodes in the way you describe with |
yes. Agree with all the above. <#Rule> :mode :Read
Here is an example from the the OWL Primer :Parent owl:equivalentClass [
rdf:type owl:Restriction ;
owl:onProperty :hasChild ;
owl:someValuesFrom :Person
] . That is the class I could make it clearer by doing the same and name the class of access modes. :ClassOfAccessModes owl:equivalentClass [ a owl:Restriction ;
owl:onProperty :subClassOf ;
owl:hasValue acl:Access
] .
acl:mode :range :ClassOfAccessModes .
|
The The predicate you use in your However:
Maybe the most important bit is that the subclass relationship is reflexive and that every class is its own subclass. Therefore, the class of subclasses of There is no need for an I think what we want is: |
yes. This is expressed in functional programming as the difference between a function that has a range of It is a bit tricky to see how to model this in a type safe language like Scala. trait AcessControlRule {
type Mode <: Access
type A <: Agent
def allow(agent: A, accessTo: Uri, mode: Mode): Boolean
}
trait Access {
def request(req: HttpRequest): Boolean
}
class Read extends Access {
def request(req: HttpRequest): Boolean = req.method == GET
}
class Write extends Access {
def request(req: HttpRequest): Boolean = req.method == PUT
}
object ReadAccessOnDocs {
type Mode = Read
type A = Work
def allow(agent: A, accessTo: Uri, mode: Mode): Boolean = accesstTo.path.startsWith("/docs/")
} But of course it would not make sense to do this in a statically typed way. Instead on would have a function val Read: Request => Boolean = (req: Request) => req.method == `GET` But the set of functions |
Let me try to ask a simple question: Are you trying to express that the range is all the subclasses of |
No, the range is the Powerset of acl:Access, ie. <#auth> :mode acl:Access. which could be a way of expressing the authorization is enabled for "All modes of access". |
If I'm understanding the rest of this right, it seems that last should be |
@TallTed it is also true that :ClassOfAccessModes owl:equivalentClass [ a owl:Restriction ;
owl:onProperty :subClassOf ;
owl:hasValue acl:Access
] . The reason I come to this conclusion is that |
I see nothing relevant distinguishing The only thing you gain is a couple of inferences that are probably not useful or welcome. To be clear, neither With With your axiom, if I don't see how that's an improvement and it is confusing.
Yes, absolutely. That is exactly what EDIT: And I mean, I get how the idea would be nice if it were an actual restriction. But I don't see how useful or fitting it is in this ontology/in order to draw classification inferences. |
Do you see a difference between Say you have the type
(Let's ignore the blank node comment that a good reasoner will resolve) What you are saying is that On the other hand |
Yes, and everything you say makes sense from a functional programming perspective.
It's not an implication or a confusion, it's basic inference. It's how RDF works. RDF is not a strongly typed functional programming language and Can you translate with a few statements what you are trying to do in RDF? We have currently a few Access Modes What is your expected inferencing behaviour? |
Ok, so I think we need to go straight to the source here. Let's look at the inference rules from RDF 1.1 Semantics. We have as rule 9, translated to N3 for readability the inference { ?xxx rdfs:subClassOf ?yyy .
?zzz rdf:type ?xxx . } => {?zzz rdf:type ?yyy} This is different from the rule you are asserting which would be written { ?xxx rdfs:subClassOf ?yyy . } => {?xxx rdf:type ?yyy} Rule 9, states that the instances of the subClass are instances of the superclass. ie that
This is not the same as stating that subclasses of the superclass are members of the superclass. |
Henry, thank you for your patience. I have to say that you are right. I didn't think the distinction would hold, but it does. Given a graph: prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix : <https://example.com/>
:mode rdfs:range :Access .
:x :mode :Read . The following statements hold: @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix : <https://example.com/> .
:Access
a rdfs:Class, rdfs:Resource;
rdfs:subClassOf rdfs:Resource, :Access .
:Read
a rdfs:Resource, :Access . # The Read class is inferred to be of rdf:type :Access
:mode
a rdf:Property, rdfs:Resource;
rdfs:range :Access;
rdfs:subPropertyOf :mode .
:x
a rdfs:Resource;
:mode :Read . Given a graph: prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix : <https://example.com/>
:mode rdfs:range [
a owl:Restriction ;
owl:onProperty rdfs:subClassOf ;
owl:hasValue :Access ;
] .
:x :mode :Read . The following statements hold: @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix : <https://example.com/> .
_:node0
a rdfs:Class, rdfs:Resource, owl:Restriction;
rdfs:subClassOf _:node0, rdfs:Resource;
owl:hasValue :Access;
owl:onProperty rdfs:subClassOf .
:Access
a _:node0, rdfs:Class, rdfs:Resource;
rdfs:subClassOf rdfs:Resource, :Access .
:Read
a _:node0, rdfs:Class, rdfs:Resource; # The Read class is inferred to be of rdf:type _:node0 (not :Access)
rdfs:subClassOf rdfs:Resource, :Access, :Read . # The Read class is inferred to be rdfs:subClassOf :Access
:x
a rdfs:Resource;
:mode :Read . |
The current ACL ontology has
The
:range
here is defined as any instance of rdfs:ClassThis is defined as
That is the range of
:mode
allows the class of Flying Saucers as range too.Clearly this should be restricted to the class of subclasses of
acl:Access
.which is defined as
And indeed that is how Read, Write, Control, ... are defined.
One suggestion would be to fix this with
acl:mode :range [ a owl:Restriction ; owl:onProperty :subClassOf ; owl:hasValue acl:Access ] .
As described in the comment below the same reasoning applies to the range definitions of
acl:accessToClass
andacl:agentClass
.The text was updated successfully, but these errors were encountered: