-
Notifications
You must be signed in to change notification settings - Fork 3
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
Annotations' attributes get overwritten by CWRC-Writer #282
Comments
The attribute |
A few thought about the dates attributes. We might want to rethink the use of Since we are dealing with annotation metadata (as opposed to the content of the annotation), the issue date is the same as the created date, which can be either the moment when the user creates the annotation or when the file is saved (committed). Alternatively, we can use this pair of attributes (created & issued) to describe the above process (creation and save). Not sure if it would make any difference, though. |
Currently, when loading a file, CWRC-Writer parses (and remove) RDF annotation from the XML, and stores them in JS objects (Entities). These objects are used to manage entities, edit, and display entities. Later on, when the user decides to save (or to check the XML), these objects are used to regenerate JSON-LD and put them back in the XML (inside XENODATA). The problem is that when initially parsing the RDF, CWRC-Writer only stores part of the attributes, which does not include The solution to this issue might be as trivial as storing these crucial attributes to be used to regenerate the annotation later. while this works fine when the annotation doesn't change in the session, how we will handle updates? Should we update the date of creation's timestamp? Or perhaps add a new attribute to store the latest updated ( Perhaps @SusanBrown can help with these questions. |
I'm not well versed in JSON-LD neither how people used, but perhaps there is more to this. Perhaps, a bigger question (at least for me at this point) is how CWRC-WRITER supports JSON-LD and how it handles it? What attributes (and from which namespaces) we are using? Anatomy of a CWRC-Writer JSON-LD.
|
Store orginal annotation into entity object. Add modifiedDate, didUpdate, creator and creators as property to entity. Update modifiedDate when user edit annotation. Update xpath of context around changes (without modify the entity). Update annotationId if a new file is created. Add list of contribuitors when annotation gets modified. #282
Made some more adjustments and updates (9e3c0cf):
|
A few questions for consideration (@SusanBrown @ilovan ) 1. What constitutes, or what should trigger an update to an annotation?Perhaps a better question is What counts toward modifying an annotation? (as opposed to contextual updates)
2. Is it ok to have an array of contributors?DCMI defines the term I decided to use it to add users that modify the annotation. Every time a user deliberately modifies an annotation, the modified date gets updated, and the user is added to the list of contributors (if not already, and if not the creator). But it is not clear in the documentation if there can be more than one contributor. They say, though, that contributor (term) is a subproperty of contributor (element) (both in singular). Example:
3. On the
|
# [7.0.0](v6.0.0...v7.0.0) (2020-12-04) ### Bug Fixes * **annotation:** fix issues with annotations been overwritten when saved ([9e3c0cf](9e3c0cf)), closes [#282](#282) * **annotation:** get app version from package.json and app id from the current CWRC-Writer instance ([cc52a20](cc52a20)) * **annotation:** improve test to add contributors ([e9841d4](e9841d4)) * **nerve:** use data from the form elements to update the entity ([01a0c37](01a0c37)) * **nssi[nerve]:** skip teiheader when sending document to nssi[nerve] ([f797df5](f797df5)), closes [#285](#285) * **schematags:** filter tags using uppercase input ([7b8ce13](7b8ce13)), closes [#286](#286) * assure single attribute dropdown is an array instead of a string ([d69e8a9](d69e8a9)), closes [#283](#283) ### Code Refactoring * **gitdialog:** provide writer instance to logout component ([9bc1ae6](9bc1ae6)) ### Features * 🎸 config commitzen. Bump up version due to CI changes ([d7119e5](d7119e5)) * 🎸 travis-ci tweak ([7e0f4ad](7e0f4ad)) * 🎸 travis-ci tweaks ([448f75f](448f75f)) ### BREAKING CHANGES * **gitdialog:** provide writer instance to logout component
RDF annotations attributes get overwritten by CWRC-Writer every time it rebuilds the XML. More specifically, the annotation ID (which includes de URL), the date when the annotation was created and issued get updated to the current timestamp, and the creator's information is replaced with the current user's data. If the file is saved, previous information is lost.
For instance:
dcterms:creator
is replaced with the current user's @id, @cwrc:hasname, and foaf:nickdcterms:created
anddcterms:issued
are replaced with the current timestamp.Also, some of the metadata stored within the annotation is not up-to-date or incorrect. For instance,
ad:generator.id
is hardcoded as "https://cwrc-writer.cwrc.ca/", which is problematic when using CWRC-Writer from withing Islandora, or even an external standalone installation.as:generator.schema:softwareVersion
is also hardcoded as "1.0", which I am assuming is CWRC-Writer's version, currently om version 6.0.0Expected Behaviour
Unless the user deliberately changes an annotation, CWRC-Writer should preserve annotation's attributes, including the ID, the dates and the creator.
Current Behaviour
Previous information gets replaced when the file is saved,
Possible Solution
Rework the process of generating annotations. Currently, it seems that some attributes (date, creator, etc) are not stored as objects when the file is loaded. Storing these attributes and use them to check if there was any change to the annotation prior to regenerate the XML might solve the problem.
Since this is an important and sensitive feature, these changes should be discussed and agreed upon before implemented.
Steps to Reproduce (for bugs)
Sample Letter
from the template.The text was updated successfully, but these errors were encountered: