RE: Modeling permissions with Hydra

Collapsing two sub-threads into one...

On Wednesday, November 11, 2015 7:54 AM, Dietrich Schulten wrote:
> Am 10.11.2015 22:43 schrieb Markus Lanthaler <markus.lanthaler@gmx.net>:
> >
> > On 9 Nov 2015 at 10:54, Asbjørn Ulsberg wrote: 
> > > 2015-11-06 20:35 GMT+01:00 Ryan Shaw <ryanshaw@unc.edu>: 
> > >> 1. There still doesn't seem to be consensus on the function of the API 
> > >> documentation. Markus' position, if I understand correctly, is that 
> > >> the API documentation is a kind of convenience or shortcut for 
> > >> specifying state transitions; rather than or in addition to including 
> > >> this information directly in representations. The advertised state 
> > >> transitions from any specific representation are always the aggregate 
> > >> of 1) the transitions specified in the representation itself PLUS 2) 
> > >> any transitions specified in linked documentation. 
> >
> > This is not "my position". It is how it is currently defined. If you
> > have a class C which supports operation O and a resource of type C,
> > then a client can infer that the resource supports O.
> 
> It does not seem that a reasoner can infer (as in RDF inference) the
> :operation triple on the resource from the :supportedOperation triple
> on the :Class. Or do I miss something?

Well, obviously a reasoner which just knows about RDFS can't make those inferences. Just like such a reasoner can't do much with OWL. Nevertheless this is how it is specified. A Hydra-conformant reasoner would (need to) be able to make to inferences.


On 11 Nov 2015 at 22:38, Ryan Shaw wrote:
> On Tue, Nov 10, 2015 at 4:42 PM, Markus Lanthaler wrote:
>> The reason this was designed this way is that in most APIs out there, typically (almost) all
> instances of a specific type typically support exactly the same operations. You don't see a lot
> of APIs where each resource behaves completely differently from every other resource
> exposed by the API.
> 
> I disagree; one sees exactly this in APIs where the supported
> operations are determined by a role-based permissions system,

I didn't say they such APIs don't exist. I just said the vast majority don't do this.


> especially if the roles themselves are dynamic (one can define and
> assign new roles).

Assigning roles could be realized by adding classes to instances which means operations could still be driven by ApiDocumentation. I see no contradiction here.


> Besides, one of the reasons one may not see so many
> APIs like this currently is that there hasn't been a great way to
> write real hypermedia clients that can handle such dynamic APIs, but
> isn't that what you are enabling with Hydra?

Yes, that's why we (currently) allow both inline controls and controls in the ApiDocumentation.



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 12 November 2015 22:45:02 UTC