Hi Nina, All,

On Fri, 2010-06-18 at 13:42 +0300, Nina Jeliazkova wrote:
> Hi Pantelis, All,
> 
> chung wrote:
> > Hello Nina, 
> >   I think it would be both more efficient for the server (because it
> > would provide shorter representations) and for the client (to be able to
> > view only the resources to which it has access) if the services return
> > only a URI list of resources at which the client has access. Otherwise
> > the services would have to return very long lists of URIs or even RDF
> > documents. 
> >   
> IMHO this is better handled by adopting a search functionality -
> e.g.retrieve only objects which comply to certain criteria (user or
> group ownership) and should be independent of AA. 
> I am kind of reluctant to the idea of duplicating resource - users
> relationships in services, for the obvious reason one can issue OpenSSO
> call to change this relationship, without ever informing the service.
> Then the service will have outdated information, which will be difficult
> to synchronize.

Well, this is why the services should not store user-related information
hence there is no way to provide such lookup services. How can the
service tell which are the models owned by 'Nina' if there is no Nina in
the Database of the service?

> 
> >From OpenSSO side , I am afraid there is no easy way to retrieve list of
> objects of particular type that "belongs" to particular user - Andreas
> am I right?
> >   However if we decide to return the complete list I think it would be
> > good practice if clients requested only URI lists and not RDFs for the
> > sake of shorter representations. Recall that RDF representations contain
> > all information about the underlying resources, for example if you ask
> > for an RDF/XML representation of all model you can see every model's
> > independent and dependent variables etc.
> >   
> It will be valid to have subset of RDF representation, e.g. when
> retrieving datasets , only metadata is retrieved, not all compounds and
> properties. Same could be done for models.
> 

Is there any kind of information in the representation of a model which
should be hidden/protected? I think the model representations as they
are now do not have anything about the model itself such as its
equation, coefficients etc...

> Even if model variables are retrieved, these are only links, not their
> representation.
> 
> Regards,
> Nina
> >
> > Best regards,
> > Pantelis
> >
> >
> > --------------------------------------------------
> >
> > New Book: Teach yourself C in 45 years, Volume I.
> > Special offers for life prisoners ;)
> >
> >
> > On Fri, 2010-06-18 at 12:36 +0300, Nina Jeliazkova wrote:
> >   
> >> Hi,
> >>
> >> Good question.  The easiest workaround would be to return URIs of all
> >> resources, regardless of the ownership/policy - if the user wants to
> >> retrieve representation of the  particular resource, then the
> >> authorisation applies.  This will not break protection of confidential
> >> resources, since the client will get only links, not resources
> >> themselves.  And this is how typical web page works as well - you can
> >> see the links, but accessing the links might require AA.
> >>
> >> In fact, retrieving list of resources should rely on the policy for the
> >> top level resource (e.g. /model )  , which might have GET allowed for
> >> everybody.
> >>
> >> Best regards,
> >> Nina
> >>
> >> chung wrote:
> >>     
> >>> Hi All, 
> >>>   If a user needs a list of all models or datasets (either a URI list or
> >>> an RDF document) is the service supposed to return only his resources
> >>> neglecting all other or list all resources to which the user has access?
> >>>
> >>>  In the first case I guess some identifier for the user has to be saved
> >>> in the database (e.g. bob at opentox.org). Checking all resources in the
> >>> database for authorization one by one I think is out of the question for
> >>> this would be a bottleneck. Maybe it is worth think about how can the
> >>> client obtain a list of all resources it can access which of course
> >>> might have been created by other users.
> >>>
> >>> Best regards,
> >>> Pantelis
> >>>
> >>> _______________________________________________
> >>> Development mailing list
> >>> Development at opentox.org
> >>> http://www.opentox.org/mailman/listinfo/development
> >>>   
> >>>       
> >> _______________________________________________
> >> Development mailing list
> >> Development at opentox.org
> >> http://www.opentox.org/mailman/listinfo/development
> >>
> >>     
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
> >   
> 
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>