You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 47 Next »


General Information

A place to record thoughts on the interaction of resource versions and WAC authorization in the context of the Fedora API alignment sprint.

JIRA issue:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.


  • If we are preserving ACLs as part of a version rather than using the original resource's, then for resources without an assigned or inherited ACLs Fedora would need to record the Default ACL at the time of the snapshot somehow. 5.3 Inheritance and Default ACLs
    • Similarly, an inherited ACL would also need to be recorded for the snapshot.

Memento and Security

Memento has very little to say about security, mainly just that it is up to the server in terms of how access to previous versions work (most likely we want it to behave the same way it behaved at the point of the snapshot, but that is something that needs to be decided), and what memento headers to expose during authentication:

https://tools.ietf.org/html/rfc7089#section-7


Delta Documentation

For versioning: Versioning Delta/Specification Notes

For authorization: TBD

Design

Before reading through this, it would be good to review the Fedora Specification Versioning Section as well as understand the Memento Terminology. 

This design relates specifically to how versioning could be done in the Modeshape Implementation of Fedora 4

Players: 

  • LDPR - original resource
  • LDPRv - same as LDPR, but it has the versioning interaction model turned on (http://fedora.info/definitions/fcrepo#VersionedResource). This implies that it is a TimeGate and has a TimeMap.
  • TimeGate - a resource which provides access to LDPRms belonging to a LDPRv via datetime negotiation.  This is the LDPRv.
  • LDPCv - a LDP container that contains the LDPRms associated with a LDPRv.  Since the TimeMap response is generated from this information the LDPCv and TimeMap are generally considered to be the same, but the LDPCv may contain more information than what is delivered in a TimeMap response. 
  • TimeMap - a resource from which a list of URIs of Mementos of the Original Resource is available.
  • LDPRm - a specific version/memento of a LDPR.  The LDPRv is not a LDPRm itself.

RESTful Interactions

Enable Versioning on a LDPR:

The following actions will create versioning on a LDPR, effectively making it a LDPRv.  

  • Upon Resource Creation: if a Link: rel="type" header of type http://fedora.info/definitions/fcrepo#VersionedResource is provided when creating a resource, it will be created with versioning turned on. 
    • A LDPR will be created with the versioning interaction model (therefore it will be an LDPRv)
    • A LDPCv will be created, from which a TimeMap can be generated.
    • A LDPRm will be generated, contained by the LDPCv.
    • Any subsequent responses from the LDPRv will include the appropriate memento links in the header: Timegate, Timemap
  • On Existing Resource: if a PUT request is made against an existing resource with a link header ( Link: rel="type") specifying type of http://fedora.info/definitions/fcrepo#VersionedResource included the resource will become versionable. 
    • The versioning interaction model will be added to the LDPR, making it a LDPRv.
    • A LDCPv will be created, from which a TimeMap can be generated.
    • A LDPRm will be generated, contained by the LDPCv.
    • Any subsequent responses from the LDPRv will include the appropriate memento links in the header: timegate, timemap

Creating a new version of a LDPRv:

  • A POST request to the LDPCv with an empty body will cause a new memento of the LDPRv to be created. 
  • If a "Memento-Datetime"  header is included in the POST request, then the value of this header will be used as the memento datetime for the new LDPRm.
  • A POST request with a body will be rejected with a HTTP 415 response.

Creating a new version snapshot of a LDPRv and it's tree:

  • A POST request to the LDPCv with an empty body and a "Depth: infinity" header will cause the LDPRv and all the items in it's tree to become versioned. 
    • This does beg the question of "what is one of the resources in the tree does not have the version interaction model attached to it?"
  • No other values of "Depth:" will work to version the tree. In other words, you cannot specifiy a depth other then 'infinity'.

Accessing the TimeMap (aka LDPCv):

  • A GET request to the LDPCv will cause the TimeMap to be returned in "application/link-format" MIME-type.  No headers are necessary in that GET request, but an "Accept" header could be included, especially if there is more then one format implemented. At this point in time, only "application/link-format" is supported.
    • The response from the GET will include a "Accept-Post: */*; p=0.0" to indicate that a body is not supported on a POST to the LDPCv. 
    • The response from the GET will include a "Vary-Post: Memento-Datetime" to indicate that a client can request a specific time be associated with a memento when it's created via a POST. 

Accessing the TimeGate (aka LDPRv):

  • Any response from the LDPRv will include link relation headers of type "timegate" (referring to the LDPRv), "original" (also referring to this LDPRv), and "timemap" (referencing the URI of the LDPCv). 

Accessing a LDPRm:

  • A GET request to the TimeGate Resource (the LDPRv itself) with "Accept-Datetime" header specified will return the LDPRm associated with that datetime, or the closest one if there is not an exact match. 
    • example header usage:  "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT"
    • a Link header will be in the response to show the TimeGate URI
  • See: Datetime negotiation algorithm example for Accept-Datetime negotiation details.



Internal Interactions / Algorithms

Finding the ACL on a LDPRm (memento): 

There are three separate entities at play in this scenario.  

  1. LDPRv - the original resource. Potentially has it's own ACL or has one via inheritance.
  2. LDPCv - is a full LDPR in and of itself and should have it's own ACL because it's a means of discovery for finding information about mementos.
  3. LDPRm - is a full LDPR as well, but the existing ACL that it references should maybe not be it's ACL anymore, so that an admin can further change azn to the mementos w/o affecting the original LDPR. 

To find the ACL that relates to a LDPRm, follow this algorithm:

  1. First look at the LDPCv for the LDPRm to see if it has an access control triple for memento items associated with it ('memento:accessControl').  If so, stop there and honor that ACL as it will apply to all mementos it contains.
  2. Otherwise follow the pattern specified by the SOLID WebAC specification for finding an ACL for a LDPRv:
    1. Use the document's (LDPR) own ACL resource if it exists (in which case, stop here).
    2. Otherwise, look for authorizations to inherit from the ACL of the document's container. If those are found, stop here.
    3. Failing that, check the container'sparent container to see if that has its own ACL file, and see if there are any permissions to inherit.
    4. Failing that, move up the container hierarchy until you find a container with an existing ACL file, which has some permissions to inherit.
    5. The root container of a user's account MUST have an ACL resource specified. (If all else fails, the search stops there.)

Given this, the following is then true: 

  • LDPCv's can have an ACL applied to them. If not, then the LDPRv's ACL applies to all the mementos in the LDPCv.
  • LDPRv and it's mementos can have different ACLs.  

Accept-Datetime algorithm

This section describes the algorithm used in figuring out which memento will be returned on a GET request to the TimeGate with an Accept-Datetime header. 


Internal Representation of resources

LDPCv - Memento Container (TimeMap)


TimeMap (LDPCv)
@prefix acl:  <http://www.w3.org/ns/auth/acl#> .
@prefix iana:  <http://www.iana.org/assignments/relation/> .
@prefix ldp:  <http://www.w3.org/ns/ldp#> .
@prefix memento:  <http://example.com/memento#> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix time: <http://www.w3.org/2006/time#> .

</path/to/resource/xyz/fcr:versions> a ldp:Container ;
   acl:hasAccessControl </path/to/acls> ;    # this is for the LDPCv itself, for the TimeMap retrieval
   prov:startedAtTime "2017-09-08T21:35:19Z"^^xsd:dateTime ;  # first memento
   prov:endedAtTime   "2017-09-11T15:41:04Z"^^xsd:dateTime ;  # last memento


   memento:hasAccessControl </path/to/acls> ;
   memento:hasOriginalResource  </path/to/orig/resource/xyz> ;  # how else can we represent this? is this a given based on url? 
   memento:hasTimeGate </path/to/orig/resource/xyz> ;           # how else can we represent this? is this a given based on url?
  
   iana:first </path/to/resource/xyz/fcr:versions/12344> ;
   iana:last </path/to/resource/xyz/fcr:versions/12347> ;
   ldp:contains </path/to/resource/xyz/fcr:versions/12344>, </path/to/resource/xyz/fcr:versions/12345>, 
      </path/to/resource/xyz/fcr:versions/12347>, </path/to/resource/xyz/fcr:versions/12346> .


The use of IANA may or may not work here - esp if the original object's snapshot is in this LDPRm directly - we need to make sure that triples don't overlap. If we stick with all memento triples, then we can strip them out and have the version of the resource the user is after.  


LDPRm - Memento


Memento (LDPRm)
@prefix acl:  <http://www.w3.org/ns/auth/acl#> .
@prefix iana:  <http://www.iana.org/assignments/relation/> .
@prefix ldp:  <http://www.w3.org/ns/ldp#> .
@prefix memento:  <http://example.com/memento#> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix time: <http://www.w3.org/2006/time#> .

</path/to/resource/xyz/fcr:versions/12345> a ldp:RDFSource , prov:InstantaneousEvent;
    prov:atTime "2012-04-30T20:40:40"^^xsd:dateTime;
    memento:hasTimegate </path/to/orig/resource/xyz> ;    # how else can we represent this? is this this a given based on url?
    memento:hasOriginalResource </path/to/orig/resource/xyz> ;   # how else can we represent this? Is this a given based on url? 
    iana:next </path/to/xyz/fcr:versions/12346> ;   # to memento
    iana:prev </path/to/xyz/fcr:versions/12344> ;   # to memento
    
   ... triples from original resource at the time of versioning... 
 
 or, if we keep them separate, it might look like this:
(I'm not clear on how a binary and it's metadata would be represented)
    ldp:contains </path/to/xyz/fcr:versions/12345/version> ,
        </path/to/xyz/fcr:versions/12345/version/fcr:metadata> ;

Open Design Questions

  • Do we need a separate memento ontology or can we use PROV-O for most things? 
  • For information about TimeMap and TimeGate can these resources not list them explicity and just use some known url formatting for this?  We may not need the pointers to the TimeGate  / TimeMap inside the resources.
    • Timegate is LDPRv URL
    • TimeMap is LDPRv URL + "/fcr:versions"  
    • The code that retrieves the memento can construct the "original", "timemap" and "timegate" link headers from it's own URL – is that okay to do? 
  • Fedora Modeshape implementation will cleanup inbound references upon deletion of an object.  How do we keep the mementos intact and immutable if something they reference disappears? 
  • If the mementos have containment triples which point to other resource (either LDPRs or LDPRm's) how do we avoid an issue of the child being in two containers? 
  • Should Fedora Modeshape allow snapshot (tree) versioning? What modeshape currently does in that scenario does not create actual mementos for ldp:contained resources.
  • Should the mementos that have ldp containment triples reference the current resource in those triples or a memento of those resources?  Some of it depends on how the memento was created (as a tree or solo resource). 
    • i.e., should </a/fcr:versions/vnum> ldp:contains </a/b> or ldp:contains </a/b/fcr:versions/vnum>
  • When versioning a tree of resources, what happens if one of the resources in the tree does not have the version interaction model attached to it?

Use Cases

Versioning/Authorization Use-Cases

Issues / Concerns:

URIs in LDPRm, and the "multiple parent" problem

It seems to be difficult to determine the identity of the "parent" of a resource via ldp:contains with versioning.  

  1. LDPR contains LDPR (without versioning).  This one is simple.  A ldp:contains A/B.  A/B has exactly one parent:  A.
  2. LDPRv contains LDPRv.  This one is also pretty simple.  A ldp:contains A/B, A/B has exactly one parent: A.
  3. LDPRm contains LDPRv.  This one is a little less straightforward.  There could be multiple resources that assert they contain B:  What does a client need to know the identity of the resource that contains B?
    1. A_m1 (an LDPRm for A):  <A_m1> <ldp:contains> <B> 
    2. A_m2 (a different LDPRm for A): <A_m2> <ldp:contaiins> <B>
    3. A (an LDPRv): <A> <ldp:contains> <B>
  4. LDPRm contains LDPRm. This one causes problems due to the fact that an LDPRm MUST be contained by an LDPCv as well.  For memento B_m1 of resource B What does a client need to know in order to determine which one is B_m1's parent via containment?:
    1. A_m1 (an LDPRm for A):  <A_m1> <ldp:contains> <B_m1> 
    2. A_m2 (a different LDPRm for A): <A_m2> <ldp:contaiins> <B_m1>
    3. B_cv (The LDPCv for B):  <B_cv> <ldp:contains> <B_m1>

Snapshot Versioning (problem ?)

The current fedora implementation creates (and links to) new LDPRs when a non-empty LDPRv is versioned. These resources are neither an LDPRv, nor LDPRm

For example, consider a container A  and A/B where A ldp:contains B.

Creating a version v1 of <A> creates a resource <A/fcr:versions/v1>.  This is essentially an LDPRm, and contains triple <A/fcr:versions/v1> ldp:contains <A/fcr:versions/v1/B>.  

Issues are:

  1. <A/fcr:versions/v1/B> is a new LDPR, bit its relationship to versioning is not defined in any spec.  It is not an LDPRv, nor an LDPRm.  It does not the have equivalent of an LDPCv associated with it.
  2. There is no explicit or implicit relationship between <A/fcr:versions/v1/B> and <B>

All of this may be fine, but it lies outside of any specification.  Essentially, "when you create a new version of a resource, that resource versions now points new and different things that it didn't previously point to, and have nothing to do with versioning" 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.