Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

This design section is currently a work in progress

...

Players: 

  • LDPR - original resource
  • LDPRv - one in the same with LDPR, but it has the versioning interaction model turned on (http://fedora.info/definitions/fcrepo#VersionedResource). This implies that it has is a TimeGate and has a TimeMap.
  • LDPCv - a LDP container that contains information about the LDPRm's associated with a LDPRv. The TimeMap is generated from this information, so this is generally considered the TimeMap, though it may contain more information then what's delivered in a TimeMap response. 
  • LDPRm - a specific version of a LDPR.  The LDPRv is not a LDPRm itself.

RESTful Interactions

Enable Versioning on a LDPR:

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

  • Upon Resource Creation: if a Link: rel="type"header specifying a type http://fedora.info/definitions/fcrepo#VersionedResource, the resource will be created with versioning turned on for that resource. 
    • A LDPRm will be generated immediately as well. 
    • A LDPCv will be created, from which a TimeMap can be generated.
    • Any subsequent responses from the LDPRv will include the appropriate memento links in the header: timegate, timemap
  • On Existing Resource: The resource will become version-able if a PUT with an empty body and a link header ( Link: rel="type") specifying type of http://fedora.info/definitions/fcrepo#VersionedResource is included. 
    • A LDPRm will be generated immediately for this resource.
    • A LDCPv will be created, from which a TimeMap can be generated.
    • Any subsequent responses from the LDPRv will include the appropriate memento links in the header: timegate, timemap

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 a link header showing where the TimeGate resource and TimeMap resource are located. 

Accessing a LDPRm:

  • A GET request to the TimeGate Resource (the LDPRv itself) with "Accept-Datetime" header specified will return the requested LDPRm associated with that datetime. 
    • example usage:  "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT"
    • a Link header will be in the response to show the TimeGate URI 

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 time that represents will be used as the memento creation date.  The resulting memento will be accessible via that Memento-Datetime
  • A POST request with a body will be rejected with a HTTP 415 response. 


Internal Interactions / Algorithms

Finding the ACL on a LDPRm (memento): 

There are three separate entities at play in this scenario.  

...

  • 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.  


Internal Representation of resources

LDPCv - Memento Container (also TimeMap)


Code Block
titleTimeMap (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#> .

</path/to/resource/xyz/timemap> a memento:TimeMap, ldp:Container ;
   acl:hasAccessControl </path/to/acls> ;    # this is for the LDPCv itself
   memento:hasOriginalResource  </path/to/orig/resource/xyz> ;
   memento:hasTimeGate </path/to/orig/resource/xyz> ;
   memento:hasAccessControl </path/to/acls> ;
   iana:first </path/to/resource/xyz/timemap/12344> ;
   iana:last </path/to/resource/xyz/timemap/12347> ;
   ldp:contains </path/to/resource/xyz/timemap/12344>, </path/to/resource/xyz/timemap/12345>, 
      </path/to/resource/xyz/timemap/12347>, </path/to/resource/xyz/timemap/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


Code Block
titleMemento (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#> .

</path/to/resource/xyz/timemap/12345> a memento:Memento , ldp:RDFSource ;
    memento:datetime "20010320133610" ;
    memento:hasTimegate </path/to/orig/resource/xyz> ;    #original resource == timegate
    memento:hasOriginalResource </path/to/orig/resource/xyz> ;   # timegate and orig resource could come from LDPCv instead
    iana:next </path/to/xyz/timemap/datetimestamp12346> ;
    iana:prev </path/to/xyz/timemap/datetimestamp12344> ;
    ... triples from original resource at the time of the versioning are here as well. 

...