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

Properly delete graphs when resources are deleted from Fedora #3

Open
Conal-Tuohy opened this issue Jul 28, 2017 · 0 comments
Open
Assignees

Comments

@Conal-Tuohy
Copy link
Contributor

Currently when a binary resource is created, the handler script is notified, and it creates or updates one or more corresponding resources in the graph store.

  • If the Fedora resource was RDF, it is retrieved and stored in the graph store with the same URI.
  • If the Fedora resource was a binary resource, then its metadata resource (whose URI is the same as the URI of the resource, with '/fcr:metadata' appended) is retrieved and stored in the graph store which the same URI (i.e. ending in '/fcr:metadata`).
    • If the binary resource is CSV then the graph store is queried to find a linked CSV Metadata resource, then RDF is generated using that CSVM resource and the result is stored in the graph store under the CSVM resource's URI.
    • If the binary resource is CSV Metadata then RDF is generated using that CSVM resource and the result is stored in the graph store under the CSVM resource's URI.
    • Other binary resources (JPG, PDF, etc) don't currently produce an RDF graph in the graph store.

Currently, when the handler script receives notification from Fedora that a resource has been deleted, it always asks Fuseki to delete the Named Graph whose name is the URI of the deleted resource. However,

  • there may not be a corresponding graph to delete (e.g. for a PDF file)
  • the fcr:metadata resources are not deleted
@Conal-Tuohy Conal-Tuohy self-assigned this Jul 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant