8000 Inconsistent replicate example · Issue #55 · MIAPPE/MIAPPE · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Inconsistent replicate example #55

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.

Sign up for GitHub

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

Jump to bottom
Closed
cpommier opened this issue Jul 24, 2019 · 7 comments
Closed

Inconsistent replicate example #55

cpommier opened this issue Jul 24, 2019 · 7 comments
Assignees
@cpommier @PapoutsoglouE
Milestone
1.1.2

Comments

@cpommier
Copy link
Member
cpommier commented Jul 24, 2019 •
edited
Loading

Line 100:
DM-73 Spatial distribution Type and value of a spatial coordinate (georeference or relative) or level of observation (plot 45, subblock 7, block 2) provided as a key-value pair of the form type:value. Levels of observation must be consistent with those listed in the Study section. "latitude:+2.341; row:4 ; X:3; Y:6; Xm:35; Ym:65; block:1; plot:894; replicate:1" Formatted text (Key:value)
Replicate should be removed to be consistent with the definition of DM-71
@cpommier cpommier mentioned this issue Jul 24, 2019
Merged
@cpommier cpommier changed the title Inconsistent replicate exemple Inconsistent replicate example Jul 24, 2019
@cpommier
Copy link
Member Author

@PapoutsoglouE I propose to release once this one is done.

@PapoutsoglouE
Copy link
Collaborator
PapoutsoglouE commented Jul 24, 2019 •
edited
Loading

Currently, the spatial distribution can hold:

  • observation levels (plant, block, etc), or
  • spatial coordinates that are not necessarily observation levels (X, lat, etc)

"Replicate" does not fit either of these, so I agree that something should be changed.

I think that it may be worth discussing revising the definition instead of the example here. Replicate information, as far as I understand, is useful to have somewhere, and we established that it cannot be an observation level.

So perhaps we should consider adding a third category to account for replicates? Though I am not entirely sure how it should be described. I am thinking something like:

Type and value of a spatial coordinate (georeference or relative), level of observation (plot 45, subblock 7, block 2), or other distribution information (e.g. replicate) provided as a key-value pair [...]

@DanFaria
Copy link
Collaborator

It is still unclear to me why we would need to declare replicates explicitly.
It seems to me that two observation units (at the same level) that have the same germplasm(s) and the same treatment(s) are experimental replicates by default. Or am I missing something?
Also, we already have a section for the experimental design that would in principle cover the replicates.

Finally, if you do think we need to capture replicate information explicitly, then the way we were doing it (e.g., plot 1; replicate: 1) doesn't seem all that intuitive or useful because it doesn't explicitly capture what this is a replicate of (meaning, we would have to go to the experimental design to figure it out, at which point we probably wouldn't need this field in the first place).

All things considered, my vote would be to simply remove replicate from the list of spatial coordinates at this stage.
If, at a later stage, we feel like capturing replicates explicitly is needed, then I would add a replicate field to the observation unit section where the value is a list of identifiers of other observation units of which the present one is a replicate of.

@PapoutsoglouE
Copy link
Collaborator

In this case then, what is the preferred workflow?
a) make change directly on the master branch
b) pull request from new branch
c) rebase existing branch v1.1.2 onto master and pull request from there

As a side note:

  1. can branches v1.1.1 and v1.1.2 be closed?
  2. should we make a v1.1-dev branch for future use?

@cpommier
Copy link
Member Author
cpommier commented Aug 15, 2019 •
edited
Loading

All things considered, my vote would be to simply remove replicate from the list of spatial coordinates at this stage.
If, at a later stage, we feel like capturing replicates explicitly is needed, then I would add a replicate field to the observation unit section where the value is a list of identifiers of other observation units of which the present one is a replicate of.
--> Agreed to remove replicate

For the branch management aspect this is related to the change made in 1.1.2. So simply make that change in branch 1.1.2, then let's rebase into master.
We should also release this. I create issue #56 for that.
@PapoutsoglouE would you create a pull request once ready ?

@PapoutsoglouE
Copy link
Collaborator

@cpommier I have made the change on this branch but I am unsure how to proceed.
Can you take it from here? The pull request currently looks ugly because of the previous non-fast-forward merge to master.

@cpommier cpommier added this to the 1.1.2 milestone Oct 30, 2019
@cpommier
Copy link
Member Author

Handled in #60

@PapoutsoglouE PapoutsoglouE mentioned this issue Feb 5, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cpommier cpommier

@PapoutsoglouE PapoutsoglouE

Labels
None yet
Projects
None yet
Milestone
1.1.2
Development

No branches or pull requests
3 participants
@cpommier @PapoutsoglouE @DanFaria
0