Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create / display chains of sequential or related documents #41

Closed
rhiaro opened this issue Dec 15, 2015 · 4 comments
Closed

Create / display chains of sequential or related documents #41

rhiaro opened this issue Dec 15, 2015 · 4 comments
Labels

Comments

@rhiaro
Copy link
Collaborator

@rhiaro rhiaro commented Dec 15, 2015

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

@csarven csarven added the UI label Dec 15, 2015
@rhiaro
Copy link
Collaborator Author

@rhiaro rhiaro commented Apr 27, 2016

And add derivedFrom provenance to all articles generated via Save As

@csarven
Copy link
Member

@csarven csarven commented May 10, 2016

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
Copy link

@hvdsomp hvdsomp commented May 10, 2016

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
Copy link
Member

@csarven csarven commented Feb 10, 2019

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 solid/node-solid-server#478 solid/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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants