Date: Thu, 28 Mar 2024 20:57:21 -0400 (EDT) Message-ID: <867813303.29324.1711673841005@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29323_1336413843.1711673841005" ------=_Part_29323_1336413843.1711673841005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Title (goal)
|
Fedora managing access conditions
|
---|---|
Primary Actor | Librarian/archivist/curator |
Scope | |
Level | User goal |
Story | The producer of Fedora content wants to be ab= le to set access conditions that would allow for the following scenarios:= p>
As for implementation, I can offer some examples of what we use now= . We specify the file type/size, the authorization type and then any values= associated. Some examples: TIF - Active Directory Group - Manuscript= Curators TIF - Aeon JPG 600px - IP - list of IP values or range= s PDF - external authentication JPG 1200px - Yale only JP= G 150px - open access TIF - NetID - yale\mf438 (or a list of NetIDs)<= /p> DSK - Active Directory Group - ManuscriptDirectors DSK - Emulat= ion - AppleWin v1.1.8 Basically our need is for very granular levels = of permission to be stored with the object in Fedora. Right now it is store= d as XML as a data stream, it would be beneficial to have it stored differe= ntly so that we could make mass changes to materials for entire collections= . Another note, we would only be storing a single JPG or possibly no = JPG and only a JP2 and will derive the JPG on the fly. So the access condit= ion setup may include conditions for resolutions of digital formats not con= tained in the data streams. The JPG examples above would indicate that a si= ngle JPG exists as a data stream and from that stream we will derive smalle= r images. But the access conditions are different for ranges of sizes. For = Yale, we stick to these sizes, 150px or less (thumb), 151-600px (medium), 6= 00+ (full resolution). For TIF images we use Full, Half page and Quarter pa= ge. Right now, all other sizes/resolutions are tied directly to the file ty= pe stored as a data stream. But being able to reference access for somethin= g that is dynamically generated would make this scale to future needs. <= /td> |
Title (goal)
|
Programmers use API for access condition support in external systems, i.e. =
Hydra
|
---|---|
Primary Actor | IT/programming |
Scope | |
Level | User goal |
Story | A programmer can use an API in Fedora that wi= ll provide access conditions for a requested object. In an ideal impl= ementation I could make a request to Fedora with a PID and the data stream,= the API would then return the requirements for access. For example, a URL = might look like http://fedora/PID/TIF/access and then returns so= mething sort of JSON or XML that has all the access information for the spe= cific request. If the data stream type is not specified then all access inf= ormation would be returned. Since we also would like to contain infor= mation related to born digital/emulation environments, this output would al= so list the restrictions for environments for accessing materials. |
Title (goal)
|
Applications use API for updating access conditions stored in Fedora
|
---|---|
Primary Actor | IT/programming |
Scope | |
Level | User goal |
Story | A programmer use the API to update/add access= conditions to a PID, PID range or all PIDs in a namespace. This would esse= ntially be API access to do everything in the Use Case 1 above. Since no cu= rators at Yale will have direct access to Fedora and all interaction will b= e through a different software front end such as Archivematica or our homeg= rown solution Ladybird, we will need CRUD controls for Access Conditions th= at can be handled from the other software products after ingest takes place= . Bulk updates are the most important part of this feature. Working w= ith individual objects is time consuming and a wasteful operation. Ideally = this is implemented so that a single update to a PID takes about the same a= mount of time as updating 10,000 PIDs. |