API spec-compliance fixes #145
Conversation
| |----------------|-----------------------------------------------------------------------------------------------| | ||
| | `dense` | Return an iterator of `Arrow Tensor`s containing slice values. | | ||
| | `coos` | Return an iterator of `Arrow.SparseCOOTensor`s containing COO-encoded coordinates and values. | | ||
| | `table` | Return an iterator of `Arrow.Table`s containing COO-encoded coordinates and values. | |
There was a problem hiding this comment.
Not sure if csr, csc, and record-batch should be removed from the spec, but as they're no longer in the tiledbsoma impl, I removed them for now. If intended to remain, perhaps we should indicate that implementations can optionally implement formats.
There was a problem hiding this comment.
They need to be removed everywhere & it's a mistake on my part if I missed removing them from anywhere.
There was a problem hiding this comment.
Thanks for confirming. Will stick with the change as is; no other occurrences exist.
There was a problem hiding this comment.
Actually, record-batch is still in the core code so reinstated here
this still exists in the core code and was erroneously removed
Sorry, I'm not following what change is being requested by this. |
|
changes to date seem good. I left a few suggestions in single-cell-data/TileDB-SOMA#834 about additional cleanup of the open |
The unresolved issues will be reincarnated as GitHub Issues.
|
|
||
| In other words, every `SOMAMeasurement` has a distinct set of variables (features), and inherits common observables from its parent `SOMAExperiment`. The `obs` and `var` dataframes define the axis annotations, and their respective `soma_joinid` values are the indices for all matrixes stored in the `SOMAMeasurement`. | ||
|
|
||
| <figure> | ||
| <img src="images/SOMAExperiment.png" alt="SOMAExperiment"> | ||
| </figure> | ||
|
|
||
| > ⚠️ **Issue**: it would be a good idea to factor `SOMAExperiment` and `SOMAMeasurement` into separate sections. |
|
|
||
| 1. Are there operations specific to SOMAExperiment and SOMAMeasurement that need to be defined? Or do they inherit only the ops from SOMACollection? | ||
| 2. What (if any) additional semantics around writes need to be defined? | ||
| 3. Value filter support in `NDArray` has been proposed: |
| Issues to be resolved: | ||
|
|
||
| 1. Are there operations specific to SOMAExperiment and SOMAMeasurement that need to be defined? Or do they inherit only the ops from SOMACollection? | ||
| 2. What (if any) additional semantics around writes need to be defined? |
There was a problem hiding this comment.
Deleting (2) for good. I believe write semantics have been well documented now in the Object Lifecycle section, w.r.t. atomicity and concurrency semantics.
|
|
||
| Issues to be resolved: | ||
|
|
||
| 1. Are there operations specific to SOMAExperiment and SOMAMeasurement that need to be defined? Or do they inherit only the ops from SOMACollection? |
There was a problem hiding this comment.
Bruce votes for deleting and so do I, so deleting (1) for good.
| @@ -70,6 +70,7 @@ The foundational types are: | |||
| The composed types are: | |||
|
|
|||
| - `SOMAExperiment`: a specialization and extension of `SOMACollection`, codifying a set of naming and indexing conventions to represent an annotated, 2-D matrix of observations across _multiple_ sets of variables. | |||
| - `SOMAMeasurement`: a specialization and extension of `SOMACollection`, that contains a set of annotated observables that are common to one or more sets of measurements and/or derived calculations. | |||
|
@thetorpedodog @mlin Let me know if you intend to review these spec changes, in which case I'll hold off on merging. Ty! |
Co-authored-by: paul fisher <[email protected]>
Resolves single-cell-data/TileDB-SOMA#834
Resolves #133