Re: Forbidding access

Sounds good.

Another idea I just had was http codes
Ie: https://en.m.wikipedia.org/wiki/List_of_HTTP_status_codes

Ontology modelling at least some of these codes seems like a potentially
useful idea...

Therein also, could that be a path to indirectly provides an answer to your
question?

Timo.


On Thu, 18 Mar 2021, 9:42 pm Tomasz Pluskiewicz, <tomasz@t-code.pl> wrote:

> FWIW, I want to adopt WAC to secure a Hydra API, thus it becomes internal
> and I’m sure I can extend with whatever additional metadata I need to
> achieve the fine-grained control I need.
>
> For example, temporal access could be achieve by adding
>
>   <> schema:validThrough “2021-04-01”^^xsd:dateTime .
>
> And having the authorisation component take that into account…
>
>
>
> Tom
>
>
> On 18 March 2021 at 12:23:44, Timothy Holborn (timothy.holborn@gmail.com)
> wrote:
> > Simple answer imo: I think that's (about) WAC
> >
> > https://www.w3.org/wiki/WebAccessControl
> >
> > More complex considerations;
> >
> > Fwiw, I think much of the semantics noted presently are oversimplified.
> > Years back there was some effort to do schema generators or something of
> > that nature.
> >
> > Support for rule of law (justice), has an array of requirements that are
> > too often poorly considered. People live. Human has tools. If our tools
> > should support life, then it shouldn't be designed to distort reality,
> imo.
> >
> > Temporal structures are also important therein.
> >
> > Imagine ending a long term relationship and all the records about a
> > person's like during that relationship


> Nb: Autocorrect issue: this should read "about a person's life during"...
not "persons like"..

(personal or work / commercial)

> > becomes semantically detached or disassociated, kinda linked to
> > disassociative identity disorder (DID), as a form of cyber physical
> > phenomenon.
> >
> > Not sure how to solve problems for human agency ATM. Safety is important,
> > particularly from those with DID issues.
> >
> > Timo.
> >
> > On Thu, 18 Mar 2021, 8:10 pm Tomasz Pluskiewicz, wrote:
> >
> > > Martynas,
> > >
> > > In practical terms you could have a generic rule that persons can read
> > > resources in general:
> > >
> > > a schema:Person .
> > >
> > >
> > > acl:mode acl:Read ;
> > > acl:accessToClass rdfs:Resource ;
> > > acl:agentClass schema:Person ;
> > > .
> > >
> > > (Or make this more specific if you want, but the use of *Class terms is
> > > important.
> > >
> > > I would like a way to fine tune the access, so that I can exclude more
> > > specific classes or individuals…
> > >
> > > Hope this makes sense
> > >
> > > Tom
> > >
> > >
> > > On 18 March 2021 at 11:05:10, Martynas Jusevičius (
> martynas@atomgraph.com)
> > > wrote:
> > > > Hi Tomasz,
> > > >
> > > > why would it make more sense than not having such an authorization in
> > > > the first place? :)
> > > >
> > > > Martynas
> > > >
> > > > On Thu, Mar 18, 2021 at 11:02 AM Tomasz Pluskiewicz wrote:
> > > > >
> > > > > Hello
> > > > >
> > > > > All examples I see are authorisations to grant access to given
> > > resource/class.
> > > > >
> > > > > Would it make sense to also include a predicate to explicitly
> forbid
> > > access? Something
> > > > like “forbidden” or “inverse"
> > > > >
> > > > > To prevent from reading :
> > > > >
> > > > > <> a acl:Authorization ;
> > > > > acl:agent ;
> > > > > acl:accessTo ;
> > > > > acl:forbidden true ;
> > > > > acl:mode acl:Read ;
> > > > > .
> > > > >
> > > > > Best,
> > > > > Tom
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
>