Scenario 11: Degrees of access

It may be necessary to make a resource available to different degrees in the case of different users. Examples of this are: (i) medical data containing personal information may need to be anonymised for one set of users, but not for (say) the patient’s own doctor(s); (ii) some parts of a thesis may be made available immediately, others only after a certain period has elapsed; (iii) a thesis may contain copyrighted material that cannot be made available, such as extracts of audio, sheet music or lyrics in a music thesis.

It may be required to hide datasets at different levels of granularity: hiding entire datasets, hiding rows, hiding columns. Some grid data management systems allow access control to be defined for individual rows, although this is harder for columns.

A number of project are looking at “marking up” data in some way to define what people can access: ASPiS and iREAD (investigating this in context of iRODS data grids); SPIDER (investigating creation of perimeters around certain subsets of data); AGAST (using RDF to define restrictions).

The metadata may also be subject to access control, both for humans and for machines, for example web crawler robots. EGEE projects such as AMGA can mark up metadata in this way . A special case of this is when even the knowledge that particular material exists is subject to restrictions, for example in the case of certain types of medical material. Consequently, access management needs to be applied to metadata as well as to the resources themselves, and must be taken into account when carrying out (federated) searches.


Submitted by

Stage: Active

Feedback Score

1 vote

Idea Details

Vote Activity

  1. Upvoted

Similar Ideas [ 4 ]


  1. Comment

    I have seen demos by Prof Wenfei Fan of Edinburgh of fine-grained security management of complex XML databases where parts of the database were not visible to certain users, including in the schema.

  2. Comment

    There is also the same issue in ePortfolios.

    Fine grained access control is mature in the sense of existing mature specifications such as XACML. However, user behaviour and usability is a big issue.

    Also there is the tendency to create new access markup specifications in each project that is funded.

    Which means when objects move or are copied, all policies are lost. (E.g. you can't move Flickr photos complete with "family only" restriction to other photo services - you have to recreate a new access policy under the new service that more-or-less matches what you had before)

  3. Comment

    I think that the existing comments are sensible here. I'd also say that this isn't really specifically a repository issue, either. I'm not even sure that the use cases which are repository oriented - which principally centre on differences between metadata and full text access controls - are particularly interesting.

    It has however been a matter of some irritation to the community that metadata about completely private objects was made available to OAI harvesters by common repository products. (I've not looked into this recently, but it came up several times in small group sessions at the 2005 DSpace user group meeting.) So there certainly have been historical pressures in this area.

Add your comment