-
Notifications
You must be signed in to change notification settings - Fork 33
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
Update shiny_attributes() to support attribute-level annotations #318
Comments
Sounds good -- PRs are always welcome! I do wonder if it wouldn't make more sense to package the shiny app components as a separate package though? I'd be happy to re-import the methods here if that's helpful. The shiny app code so far has all been community-contributed! |
It might indeed make sense to separate it, but its pretty convenient where it is. Some folks at NCEAS that were doing a lot of data curation with this module contributed it here for convenience. But as a UI function its pretty different from the other functions. I could also see this being a really helpful RStudio extension package. Adding the annotation fields looks like a great idea. We have some other work on providing annotations in EML via R and via web interfaces, and so it would be great to get perspectives from @amoeba, @jeanetteclark, @laijasmine, and @samanthacsik about what would be helpful here. |
I think at the moment it would be great to integrate this with the package right now as the Arctic Data Center team will really benefit from this. The current infrastructure makes it difficult to edit attributes without losing all the annotations as @BrennieDev described above with the |
In the meantime, I've created a PR anyone can take a look at to see the changes (should be pretty straightforward but let me know of any questions/concerns): |
Closed with merge of PR #319 |
Somewhat tangentially to Issue #313, we would like to include annotation-related fields in the shiny_attributes workflow to allow the setting/editing of 1:1 attribute level annotations.
Updated functions would include:
EML::get_attributes()
-- needs to handle annotation-related fieldsEML::set_attributes()
-- needs to build annotation object from annotation fieldsEML::shiny_attributes()
-- needs to include columns for annotation fieldsand the additional fields supported in these functions would be:
"id"
-- the attribute id, required for any attributes with an annotation attached"propertyURI"
-- represents the annotation element $annotation$propertyURI$propertyURI"propertyLabel"
-- represents the annotation element $annotation$propertyURI$label"valueURI"
-- represents the annotation element $annotation$valueURI$valueURI"valueLabel"
-- represents the annotation element $annotation$valueURI$labelExample:
![image](https://user-images.githubusercontent.com/72518353/110172890-aae95080-7db2-11eb-9bf7-0155ea3046ad.png)
The objective is to have a simplified workflow that allows for annotation setting through the shiny attribute editing process, which involves first using get_attributes() to get a data frame of the attributes for a data set, passing that df into shiny_attributes() to make changes, and then reconstructing an eml attributeList object from the shiny output using set_attributes() to reattach onto our original eml document. Currently, any values for id or annotation fields do not persist on attributes that are edited in this way and that information is lost in the process.
This suggested approach comes with several considerations, though most notable is its limitations for handling multiple annotations against a single attribute in preference for a simplified 1:1 attribute-annotation assignment workflow (which from discussions with the stakeholders of Issue #313 seems primarily the use case).
Happy to share the implementation code for this change as it is mostly completed (aside from any outstanding considerations/concerns), or discuss other approaches.
The text was updated successfully, but these errors were encountered: