Administrative Sets vs. Intellectual & Structural Arrangement

Intellectual & Structural Arrangements

Collections, Structural Sets, etc

• Collections refer to intellectual arrangement
• Collection membership could be represented using fedora:isDependentOf relationship (fedora:isMemberOf is reserved for primary set membership which may be a structural rather than intellectual arrangement) OR implicitly via a solr query/saved search, etc.
• Collections are explicit objects with their own metadata

Administrative Sets & AdminPolicy Objects (APOs)

• Admin Set is not an explicit thing. It refers to the set of items that are governed by a particular AdminPolicy object
• Objects refer to their AdminPolicy with hydra:isGovernedBy relationships

AdminPolicy objects have...

• defaultObjectRights based on Hydra rightsMetadata schema
• license info

Complete documentation in Stanford's confluence...

Objects belonging to an Administrative Set have

Objects inherit permissions asserted in their AdminPolicy object's rightsMetadata
It is possible to override permissions at the object level (Object-level rightsMetadata overrides/extends AdminPolicy rightsMetadata)
An object's rightsMetadata must explicitly reference the AdminPolicy's rightsMetadata

Structural and display sets: the Hull implementation

It may be useful to look at these issues in the context of a real, but relatively straightforward, implementation.

1.  Structural sets

The University of Hull is implementing an institutional repository Hydra head which deals with a wide variety of content and which provides full CRUD capability across a range of different object types.  This head replaces the Muradora UI which has previously provided access to the University repository and which gave us a range of differing access levels according to user rights.

The old repository was structured in a hierarchy of Fedora sets using "isMemberOf".  These sets provided managers and users with a range of features:

1. the set hierarchy allowed repository managers to group objects into collections of like objects
2. the set hierarchy provided a structured, drill-down access mechanism for users who wished to take that approach
3. object permissions were inherited down the set hierarchy

In the new, Hydra-powered repository Hull has decided not to provide users with the option of a formal drill-down approach; however, they did want to retain the very useful groupings provided by the existing hierarchy and they now refer to these as structural sets.  Whilst permissions are no longer inherited (rather they are declared explicitly by each digital object) a structural set also allows them to declare the default rightsMetadata for objects added into that set (be they sub-sets or content-bearing objects).

A structural set object is identified by a cModel declaration in RELS-EXT of hull-cModel:structuralSet.  Consider the example of a structural set which contains PhD theses for Applied Biology.  Within the hierarchy this might be represented as 'Root > Electronic theses and dissertations > Applied Biology > PhD'.  It comprises a number of datastreams:

• RELS-EXT
• DC - which contains 
  • a dc:title which is used for display purposes (in this case just 'PhD')
  • a dc:description which provides an admin user with a fuller context (here: 'Root > Electronic theses and dissertations > Applied Biology > PhD'
  • a dc:type (here 'Structural set')
  • a dc:date
  • a dc:identifier (the Fedora pid)
• descMetadata (very minimal)
• rightsMetadata (which restricts all access and functionality only to repository managers)
• defaultObjectRights (this rightsMetadata xml is copied verbatim to become the rightsMetadata of any digital object placed into this structural set)

The inclusion of the 'defaultObjectRights' datastream effectively promotes the structural set object to be a very simple APO and thus members acknlowledge this by declaring 'isGovernedBy' the structural set as well as 'isMemberOf'.

Hull's old set hierarchy is thus maintained for management purposes: repository managers can easily navigate it to find the 'Applied Biology' theses, as opposed to the 'Biological Sciences' theses or the 'Biology' theses (why do departments have to change thier names so often???).  Further, they have a way of assigning default rights to any new repository object as it is placed in its appropriate structural set.  Here is not the place to discuss the tool for changing the defaultObjectRights in a structural set and propagating this down to the members: suffice to say that this and similar tools are being put in place.

2.  Display sets

It is not intended that structural sets should ever be exposed to an end user; display sets, by contrast, are.  Display sets are the basis of Hull's intellectual arrangements and whilst a digital object in the repository must belong to a structural set, it may or may not be part of a display set.

Display sets have substantial descriptive metadata designed to provide context for their members. To that extent they are discoverable and top-level display sets give rise to a facet of resource type 'collection'.  The splash page for each member (which can be discovered independently of the display set object) will note that it is a member of a display set and provide a link by which the user can navigate to the top of that particular display tree.  Conversely, the splash page of the display set itself provides the facility to list all the members of the display set in the form of a standard search return.

Each 'top level' display set is a member of a root display set which is not discoverable by an end-user.  The only purpose of this root set is to provide a pseudo tree hierarchy so that the same code used to navigate structural sets can be used to navigate display sets.

Objects in a display set have an 'isMemberOf' relationship to the display set object (which is in addition to their 'ismemberOf' relationship to their structural set; the underlying code differentiates the set types).  At the time of writing (August 2011) it is proposed that it is not necessary (or, at least, not mandatory) for a display set object to declare a 'displaySet' cModel.  If this can be implemented successfully, then the code should work perfectly well with 'ordinary' Fedora sets.