...
- What approach should be taken to resolve referential integrity issues causing changes to LDPRms?
- https://wiki.duraspace.org/x/TAJsBQ#VersioningDelta/SpecificationNotes-ref-int
- Also consider if referential integrity should be address across the repository rather than just for LDPRms
- Is it acceptable to only create versions for individual resources rather than trees?
- How should restoring previous versions of LDPRvs work?
- How to make an existing LDPR versionable?
- PUT with an empty body may not be acceptable
- Should it be possible to include non-LDPRm children in LDPCvs?
- How can LDPCvs be identified?
- Do we need a separate memento ontology or can we use PROV-O for most things? There are examples of what a memento and LDPCv might look like here: ? How have people represented Memento information in RDF?
- What does the internal representation of mementos look like?
- Are mementos stored internally as separate resources LDP-RS contained by LDPCv (TimeMap resource) or could/should they be serialized versions stored as LDP-NRs? What other options would work to internally represent the mementos?
- Is it okay to store information in the LDPRm indicating it's archival time (and strip that out when delivering to user)?
- What does the internal representation of mementos look like?
- For information about TimeMap and TimeGate can these resources not list them explicity and just use some 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?
...
Internal Representation of resources
These are just some notes written down largely to think through things - there might be a better way of doing this type of work.
An alternate design might be to serialize the memento into a binary resource and have that contained by the LDPCv. The key thing is to figure out how you store the archival date of each memento. Should it be in the memento itself? In the LDPCv? If so, how is that stored?
Here's an example of a LDPRv - what signifies that it is a LDPRv is that a request on the LDPRv returns memento related 'Link' headers in the reponse. These 'Link' headers point to the Here's an example of a LDPRv - what signifies that it is a LDPRv is that a request on the LDPRv returns memento related 'Link' headers in the reponse. These 'Link' headers point to the TimeMap and TimeGate for this resource . The current behavior is that a 'hasVersions' triple is returned when a LDPR is requested.
Code Block | ||||
---|---|---|---|---|
| ||||
$ curl http://localhost:8080/rest/xyz HTTP/1.1 200 OK Date: Mon, 18 Sep 2017 14:58:26 GMT Link: <http://localhost:8080/rest/xyz>; rel="original timegate" Link: <http://localhost:8080/rest/xyz/fcr:versions>; rel="timemap"; from="Fri, 8 Sep 2017 21:35:19 GMT"; until="Mon, 11 Sep 2017 15:41:04 GMT"; @prefix premis: <http://www.loc.gov/premis/rdf/v1#> . @prefix rdfs: <http http://localhost:8080/rest/xyz HTTP/1.1 200 OK Date: Mon, 18 Sep 2017 14:58:26 GMT Link: <http://localhost:8080/rest/xyz>; rel="original timegate" Link: <http://localhost:8080/rest/xyz/fcr:versions>; rel="timemap"; from="Fri, 8 Sep 2017 21:35:19 GMT"; until="Mon, 11 Sep 2017 15:41:04 GMT"; @prefix premis: <http://www.loc.gov/premis/rdf/v1#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix fedora: <http://fedora.info/definitions/v4/repository#> . @prefix ldp: <http://www.w3.org/ns/ldp#> . <http://localhost:8080/rest/xyz> rdf:type fedora:Container ; rdf:type fedora:Resource ; rdf:type ldp:RDFSource ; rdf:type ldp:Container ; fedora:lastModifiedBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ; fedora:createdBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ; fedora:lastModified "2017-09-18T20:01:33.501Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; fedora:created "2017-09-15T21:19:49.731Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; fedora:writable "true"^^<http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix fedora: <http://fedora.info/definitions/v4/repository#> . @prefix ldp: <http://www.w3.org/ns/ldp#> . <http://localhost:8080/rest/xyz> rdf:type fedora:Container ; rdf:type fedora:Resource ;2001/XMLSchema#boolean> ; fedora:hasParent <http://localhost:8080/rest> ; ldp:contains <http://localhost:8080/rest/xyz/abc> ; |
LDPCv - Memento Container (TimeMap)
The key here is that the memento container be able to return the necessary TimeMap information. Below were just a few initial thoughts on what the internal structure of a LDPCv & LDPRm might look like.
But first, here's a sample TimeMap in 'application/link-format' MIME type straight from the Memento Spec:
Code Block |
---|
HTTP/1.1 200 OK Date: Thu, 21 Jan 2010 00:06:50 GMT Server: Apache Content-Length: 4883 Content-Type: application/link-format Connection: close <http://a.example.org>;rel="original", <http://arxiv.example.net/timemap/http://a.example.org> ; rel="self";type="application/link-format" ; rdf:type from="Tue, 20 Jun 2000 18:02:59 GMT" ; until="Wed, 09 Apr 2008 ldp20:30:RDFSource51 ;GMT", rdf:type<http://arxiv.example.net/timegate/http://a.example.org> ; rel="timegate", ldp:Container ;<http://arxiv.example.net/web/20000620180259/http://a.example.org> ; fedora:lastModifiedBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ; fedora:createdBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ; fedora:lastModified "2017-09-18T20:01:33.501Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; fedora:created rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT" ; license="http://creativecommons.org/publicdomain/zero/1.0/", <http://arxiv.example.net/web/20091027204954/http://a.example.org> ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT" ; "2017-09-15T21:19:49.731Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;license="http://creativecommons.org/publicdomain/zero/1.0/", <http://arxiv.example.net/web/20000621011731/http://a.example.org> ; fedora:writable rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT" ; license="true"^^<httphttp://www.w3.org/2001/XMLSchema#boolean> ; fedora:hasParent creativecommons.org/publicdomain/zero/1.0/", <http://localhost:8080/rest> ;/arxiv.example.net/web/20000621044156/http://a.example.org> ; ldp:contains rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT" ; <httplicense="http://localhost:8080/rest/xyz/abc> ; |
...
/creativecommons.org/publicdomain/zero/1.0/",
... |
A possible LDPCv. The issues to work through is that the LDPCv might have an ACL that applies to it, and then perhaps there is a separate ALC that applies to all the mementos. How do you indicate that other ACL?
Code Block | ||||
---|---|---|---|---|
| ||||
@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
- 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
The timemap needs to have the archival time in it - so that needs to be stored some where. One thought was in the memento (not returned to user). Not sure if that's a good idea or not. Also, should the memento returned contain information about the next / prev memento? Does it still qualify as a memento if the resource has that data in it?
Code Block | ||||
---|---|---|---|---|
| ||||
@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> ;
|
...