You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Re: Import/Export
I wonder if being more opinionated about the metadata structure would orient this section, but I appreciate that this may be the next step.
We'll store the metadata using a "sidecar" approach with three main tables: catalog, variable, variable_details.
There is support for variable labels, value labels and tagged_NA and established use. i.e. haven and labelled packages. For import, much metadata for key users comes from SAS or Stata files that are imported using haven. We should allow users to import this metadata and the store it in variables and variable_details.
There should be future provisions to be interoperable with other common metadata formats. I've added a conceptual diagram.
Wide versus long may be better situated as a future feature.
Do we want to include concepts such as logging and testing? Having clear expectations for the user about what will happen during transformations and the ability to debug, examine transformation effects, etc. Again, this could go in the next document.
Wide versus long may be better situated as a future feature.
Do we want to include concepts such as logging and testing? Having clear expectations for the user about what will happen during transformations and the ability to debug, examine transformation effects, etc. Again, this could go in the next document.
Agreed
Makes sense for those to go into the next document since its hard to provide a high level overview of what should go into logging and testing without getting into the specifications.
@DougManuel The scoping document should now be ready for you to review. The document is in the scope-docs folder and can be rendered using the command quarto preview ./scope-docs. You will need to delete and re-pull your version of this branch since I changed the entire history. I added a commit with everything you wrote to ensure that its all preserved. I also pulled in the changed from your catalog branch into the scope. Finally, I created a v2 branch into which this branch will be merged.
- Implements Dublin Core standard with 10 core fields from PRs #65 and #43
- Follows three-file architecture with registry reference for DRY principles
- Includes recodeflow-specific extensions for workflow integration
- Supports metadata file naming conventions and validation rules
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
yulric
force-pushed
the
scoping-doc
branch
2 times, most recently
from
No description provided.