-
Notifications
You must be signed in to change notification settings - Fork 18
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
Delete a resource #132
Comments
Yes, except for the word 'just'. :) When a resource is marked as deleted, should all of its values also be marked as deleted? If so, and if one of those values is a text value containing standoff, should the standoff be marked as deleted? In the new standoff design, standoff tags are resources containing values, so when we mark standoff resources as deleted, we'll have to mark those values as deleted, too. We also need to do cardinality checks before marking things as deleted (from #53). If we have to mark multiple resources and/or values as deleted in one API operation, we may need to do so in a single triplestore transaction to ensure that we don't violate consistency constraints. So this all needs a bit of design. |
I see :-) |
If someone has annotated a standoff resource by linking to its IRI, we would have to worry about the cardinality constraints on the annotation. We could eliminate this problem if we allowed annotations on standoff only using UUIDs, which are not involved in constraint checking. Possibly this could be done using constraints in |
Use case: a standoff tag indicates that some text is a transcription of a region in an image. Therefore the standoff tag points to the region resource. What happens if the region resource is deleted? Will this violate the consistency constraint on the standoff tag? Similarly: a standoff tag says that some text is derived from some other text value in some other resource, e.g. it's a critical text based on a transcription. What happens if the transcription is deleted? Will this violate the consistency constraint on the standoff tag? Solution: if a resource class has a constraint requiring a property pointing to an X, and it points to an X that's marked as deleted, that's OK. |
This will be easier now because standoff tags are not going to be resources. When a resource is marked as deleted, @lrosenth says there's no need to mark all its values as deleted. |
Work in progress is on |
* feature (consistency): Simplify consistency checking rules. - Allow a required property to have only a value marked as deleted. - Rename properties used in knora-base for consistency checking to make them clearer. - Add comments. * feature (store): Add consistency check optimisations suggested by Ontotext. - Update GraphdBConsistencyCheckingSpec to test the new consistency checking rules. - Add missing cardinalities for hasStandoffLinkTo and hasStandoffLinkToValue to knora-base:Resource, and update test data accordingly. * docs: Add documentation for optimised GraphDB consistency rules. * feature (store): Adjust scripts and configuration for GraphDB 7.0.3. * test: Add test for property with no cardinality. * fix (webapi): Redesign value deletion as per #63. * feature (webapi): Implement resource deletion. - Refactor some code for the context query in the resources responder. * feature (webapi): Add test for resource deletion (#132). - Fix link deletion. * docs: Update docs about deletion. * feature (webapi): Add an E2E test for deleting a resource. - Rename all 'rapierPath' to 'knoraApiPath. * test: Add E2E tests for creating and deleting values. - Distinguish between the 'anything' test user and the root user. * test: Add E2E tests for changing and deleting more value types. * fix (exclude deleted resources from extended search): check for deleted flag * fix (URL encode IRIs): URL encode IRIs for delete request * feature (webapi): WIP for pull request #186. * feature (webapi): WIP for pull request #186. * fix (webapi): Check permissions on LinkValues for incoming links (issue #88). - Always grant view permission on LinkValues for hasStandoffLinkTo. - Refactor link querying in ValuesResponderV1. - Use ?prop and ?obj in SPARQL rather than ?p and ?o, for consistency and code reuse. * doc: Update various things in knora-base.tex. - Describe the new deleting design. - Describe the SystemUser. - Remove ideas about future standoff development that are obsolete in the new standoff design. - Make the \issue{} command point to GitHub issues. * docs: Clarify permissions on standoff links in knora-base.tex. * style (webapi): Add comments to clarify value creation in a new resource. * test: Add test for deleting two text values containing the same standoff resource reference. * test: Add tests of permission-checking on incoming and outgoing links (issues #88 and #89). * fix (webapi): Fix permission checking on outgoing links. * style (webapi): Correct comments and variable names. * fix (webapi): Check permissions on values in results of extended search. - Require valueHasString on knora-base:Value. * test: Remove incorrect test data (issue #17). * fix (webapi): Check permissions on values in results of full-text search. * style (webapi): Use IRI instead of String. * style (webapi): Reformat code. * feature (store): Update config and scripts for GraphDB 7 running as a stand-alone server. * test: Fix some test data. * docs: Update knora-base.tex. * docs: Update consistency checking doc. * fix (ontologies): Add missing rdfs:subPropertyOf :objectCannotBeMarkedAsDeleted for consistency checking. * feature (webapi): Add check for missing cardinalities in values. * test: Fix typo. * test: Add an extended search test with three criteria to check performance. * feature (webapi): Store permissions in a single triple for more efficent queries (#196) * feature (webapi): Check permissions in context query. * feature (webapi): Check permissions in context query. * docs: Clarify requirements regarding use of subjectClassConstraint and objectClassConstraint. * docs (typos) - it is an honour for me to fix your typos * docs: Clarify the syntax of inference and consistency rules.
In the SALSAH GUI, the user can click on a trash can button to delete a resource.
But we have not defined this method in the resources route yet:
Can we just add this method to the route and mark the resource in question as deleted (sufficient permissions provided)?
The text was updated successfully, but these errors were encountered: