Page History

...

@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> ;   
    

Design Questions

Open

...

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?
• 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? 
  • LDPRm Creation Example
  • Discussed by a subgroup – decided that we need to research this more. 

Answered Questions:

• 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? 
  • Handling Deletion of Referenced Resources / Mementos
  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? LDPRm Creation Example

        One way to fix this is to update the system so that links to other resources are URIs and not node references

• Should Fedora Modeshape allow snapshot (tree) versioning? What modeshape currently does in that scenario does not create actual mementos for ldp:contained resources.:contained resources.

        The initial version of this change will not allow snapshot(tree) versioning.  The first pass at spec compliance will only include versioning one resource at a time. 

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

        The discussion was to have the ldp:containment triples reference the cannonical URL of the resources.  

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

        Given that we will not be doing snapshot (tree) versioning at this point, this should not be an issue to consider at the present time. 

Use Cases

Versioning/Authorization Use-Cases

...