-
Notifications
You must be signed in to change notification settings - Fork 57
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
MetaData class proposal #142
Comments
Thanks! The meta data keeps growing through the pipeline (e.g. psModelCoef doesn't get added until createPs is called). I wonder if we should use a more 'compositional' approach? So we have data-loading meta data, PS-model meta-data, that together combine in to an overall meta data object. What do you think? Should we have a separate class for attrition? |
I think splitting out the metadata in two different classes is a good approach. I think for inheritance sake, it would be best for the "data-loading meta data" to inherit from the "PS-model meta data" class, as in my first example the only private function pertains the "data-loading meta data" class. The print method is then inherited. The fields can be packaged up in either a named
The
* Cursive names are overloaded methods The outcomeModel would then also be able to inherit from
The
Regarding attrition, I think we could handle it in a similar manner:
The A couple of choices that need to be made:
|
Should In response to your questions:
|
So my reasoning as to why the classes are setup like that, is that MetaDataPS is the most simple of the bunch, and we'd extend the child classes where needed with additional methods, i.e: MetaDataLoading: If we'd implement as you propose, method formatStudyDates from MetaDataLoading would also be inherited to all child classes, but I don't think we would need this method in any of them. It boils down to an organizational choice to keep methods in places where they're needed.
I agree, we can add an
Generally I agree, I don't know if we should just bite the bullet on this. The class only really contains a targetId, comparatorId, studyStartDate, and studyEndDate. So I'll do one more suggestion: StudyMetaData. Otherwise it can just be GetDbCOhortMethodDataMetaData as a working name.
I thought we'd eventually replace the S3 implementation with the R6 one, we can name it OutcomeModelR6 for now, as the idea of it is the same, the implementation is different.
|
But the meta-data coming out of the createPs() function will also contain all the meta-data that came out of getDbCohortMethodData(), right? The trail keeps growing as more data is applied. So the createPs metadata should have a formatStudyDates() function because it will contain the study dates used to create the CohortMethodData that was the input to createPs. Why would the class for the meta-data for the outcome model be called 'OutcomeModel'? I thought we'd distinguish between the data itself and its meta-data, but perhaps you're thinking of those being represented by a single class? |
Hi @schuemie,
As discussed a proposal for the MetaData class for CohortMethod. I've implemented a first version of the class in R6.
The code is available in the R/R6-MetaData.R file, on the R6-proposal branch.
In this post I will go through the implementation bit by bit.
Class definition
Public
Fields
The following fields are specified:
targetId
,comparatorId
,studyStartDate
, andstudyEndDate
are required when initializing an instance of the MetaData class.As of right now it is not entirely clear to me yet what parameters can be private, as I do prefer to store fields privately. Right now I'm thinking about the fields required for initialization.
Sources of fields:
targetId
comparatorId
studyStartDate
studyEndDate
attrition
outcomeIds
populationSize
deletedRedundantCovariateIds
deletedInfrequentCovariateIds
deletedRedundantCovariateIdsForOutcomeModel
deletedInfrequentCovariateIdsForOutcomeModel
psModelCoef
psModelPriorVariance
psError
psHighCorrelation
estimator
Methods
initialize
Initializer method used when
MetaData$new()
is called. Thevalidate()
method is called when a new object is initialized.validate
Validation method that validates each field (taken from: DataLoadingSaving.R, psFunctions.R).
getMetaData
Method to get all specified fields returned in a list. Individual public fields can be optained like so:
print (Overload)
Overload the print generic to nicely print the current fields.
Private
Methods
formatStudyDate
Method to format the study end and start dates (from: DataLoadingSaving.R).
The the following section an outcomeModel class is being specified using metaData.
My suggestion would be making another class called OutcomeModel, which inherits from MetaData, extending the functionality.
The text was updated successfully, but these errors were encountered: