Pleased to try also:
```
sapply(c("SummarizedExperiment", "MultiAssayExperiment"), library,
character.only = T)
new <- SummarizedExperiment()
metadata(new) <- list(MultiAssayExperiment())
new
```
Again, it is a preference.
kind regards,
Sean
On Wed, Jan 24, 2024 at 6:06 AM migdal migdal <mcjmig...@gmail.com> wrote:
> Hi Delphine,
>
> I had a similar dilemma while developing midasHLA
> <https://github.com/Genentech/midasHLA> package. There, we wanted to have
> unique features names across all experiments and colData as well as
> mandatory metadata. To this end I wrote a new class specific to my package
> that extends MAE. I had some negative comments
> <https://github.com/Genentech/midasHLA/issues/5#issue-727826240>
> regarding this solution (see R code section of the comment by LTLA; it
> might help you decide how to approach your particular case), but IMO it
> works nicely.
>
> Best Maciek
>
> On Wed, 24 Jan 2024 at 14:43, Sean Maden <maden.s...@gmail.com> wrote:
>
>> There aren't strict standards imposed on many of the packages in
>> Bioconductor introducing classes, but many other packages extend and
>> impose
>> standards and constraints for given areas/fields/subjects.
>>
>> If you are considering this route, something like the following could work
>> to determine if introducing metadata features and restrictions is the
>> route
>> to take:
>>
>> libraryVector <-
>> c("MultiAssayExperiment", "SummarizedExperiment",
>> "SingleCellExperiment", "SpatialExperiment")
>>
>> # Try something like this to test your candidate data classes:
>>
>> testClass <- function(libraryName, functionString){
>> # libraryName : valid class library
>> eval(parse(text = paste0(functionString,"(",libraryName,")")))
>> }
>>
>> for(libraryName in libraryVector){
>> testClass(libraryName, "library")
>> testClass(libraryName, "new <- ")
>>
>> metadata(new) #
>>
>> testClass("new", "rm")
>> testClass(libraryName, "detach")
>> }
>>
>> There may be better ways to harmonize and share the data with
>> collaborators
>> as a flat table.
>>
>> MAE has extensive documentation and there is also a cheatsheet provided to
>> help out with tasking.
>>
>> See also: DOI: 10.18129/B9.bioc.MultiAssayExperiment
>>
>> Sean
>>
>> On Tue, Jan 23, 2024 at 5:45 AM Delphine Charif <delphine.cha...@inrae.fr
>> >
>> wrote:
>>
>> > Dear Bioc developer,
>> >
>> > We are developing a package and have used the MultiAssayExperiment class
>> > to manage our data.
>> > We need to impose a particular structure on the slot metadata of the MAE
>> > object (list => named list)
>> > because we havec defined methods that depend on this named list.
>> > Is it good practice to extend the MAE class for the specificity of our
>> > metadata structure or is it better
>> > to define new methods applying to a MAE object (and check the metadata
>> > structure )?
>> >
>> > Thanks in advance,
>> >
>> >
>> >
>> >
>> >
>> >
>> > --------------------------------------
>> > Delphine CHARIF
>> > +33 (0)1 30 83 35 24
>> >
>> > IJPB<https://ijpb.versailles.inrae.fr/> - <https://www.inrae.fr/>
>> INRAE<
>> > https://www.inrae.fr/>
>> > RD10 - Route de Saint-Cyr
>> > 78026 Versailles
>> > ---------------------------------------
>> > En temps partiel le mercredi
>> >
>> >
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > _______________________________________________
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
