Create / display chains of sequential or related documents

[rhiaro]

Examples:

• Paper v2 is derived from paper v1 + rebuttal + reviewer feedback
• Sequential chapters
• Paper is a follow-up from a proposal

These quite specific relations could be displayed differently from replies/annoations in the UI (from both ends of the relation, eg. derived-from and has-derivatives).

[rhiaro]

And add derivedFrom provenance to all articles generated via Save As

[csarven]

See also http://robustlinks.mementoweb.org/spec/ for whatever is applicable via @hvdsomp . I think we currently cover the use cases there using the PROV-O, schema.org, Web Annotation RDF vocabularies.

Aside: I'm not particularly a fan of HTML data attributes as they require special processing, but good to keep this in our radar.

[hvdsomp]

Thanks for putting this comment in, Sarven. A few things:

• I am not sure that what you are trying to achieve with PROV-O etc is what Robust Links wants to achieve. Robust Links is about papers linking to "web-at-large" resources. And about the fact that these resources evolve in two ways: they disappear (link rot) and their content changes when compared to when they were linked to (content drift). Robust Links is about providing a mechanisms to revisit the state of the referenced/linked resource as it was when it was referenced. It works, indeed, by means of HTML5 data- attributes and leverages the Memento protocol and associated infrastructure to find a temporally appropriate resource version in web archives, resource versioning systems, etc.
• I think what you want to achieve using PROV-O is more along the lines of what is described at Resource Versioning and Memento. That is a very lightweight, REST/HATEOS approach to expose and access temporal versions of resources.
• The data- attributes we use for Robust Links are processed using utterly simple RobustLinks JavaScript embedded in the page that includes the data- link decorations. I don't consider this any more special processing than would be required to deal with eg PROV-O, schema.org, ...

[csarven]

Hello people from 2015, 2016..

I think the original cases that @rhiaro raised is implemented in dokieli for generally two 'create' operations with @hvdsomp 's suggestion on Memento:

• Save As: the new resource has a relation to the original resource indicating that its derivation information.
• Immutable save: a new resource is intended to be treated as immutable is created (URI-M) and links to the original resource (URI-R) and vice versa (eg. latest-version, predecessor-version). A separate resource for TimeMap (URI-T) is created or updated to include the reference to the immutable resource.

If a resource (URI-R or URI-M) has a timemap relation, clicking on the "Memento" button from the dokieli menu will show a list of resources in the TimeMap resource in which the user can navigate to.

Note: the Memento bits are intended to mimic the TimeMap bits of Memento protocol where the client handles the resources. Part of the idea here is to bring this feature to servers that don't support the Memento protocol, but something that would allow clients to still work with resource versioning. Whether a resource is actually immutable is not something that dokieli can ultimately control since the server makes the last call on that. A separate issue is needed for dokieli to work with servers implementing the Memento protocol or implementing the relevant parts of the Fedora spec. The solid-server didn't it implement at the time (pending nodeSolidServer/node-solid-server#478 nodeSolidServer/node-solid-server#612 ) and the Fedora spec was/is still in the works.

Certainly a lot more can be fine tuned or extended here but I would consider the current state to be sufficient to close this issue.