Skip to content
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

SCORE Artificat class potential blockage #138

Closed
VisLab opened this issue Feb 14, 2024 · 6 comments
Closed

SCORE Artificat class potential blockage #138

VisLab opened this issue Feb 14, 2024 · 6 comments

Comments

@VisLab
Copy link
Member

VisLab commented Feb 14, 2024

I propose that since going forward SCORE will always be partnered, that in SCORE 2.0.0 we move the hierarchy

Artifact to the standard schema as:

Data-property/Data-artifact-type

and move the major categories of artifact to the standard schema:

Data-property/Data-artifact-type/Biological-artifact
Data-property/Data-artifact-type/Non-biological-artifact
Data-property/Data-artifact-type/Other-artifact

We may want to move a few of the other items that currently appear under that to the standard schema as well. We have an opportunity to do this now with the upcoming release of a major backwards incompatible version of SCORE.

Reasoning: If they stay in SCORE, then anyone who wants to add an artifact type to SCORE will have to add it to SCORE rather than to its own library. If at least the top-level stuff is moved --- SCORE can anchor its specific artifacts in the standard schema but other libraries can add their own artifacts independently. I think this will be a very relevant issue for the upcoming development of a MOBI schema.

@dorahermes @smakeig @neuromechanist @christinerogers @monique2208

@dorahermes
Copy link
Member

dorahermes commented Feb 14, 2024

I agree that there are benefits to this and don’t see any major cons.

The only thing to note is that some of the SCORE artifacts are specific to ephys data, and MRI data have different artifacts (eg ringing, Eddy etc), so we should consider that in the hierarchy.

@VisLab
Copy link
Member Author

VisLab commented Feb 14, 2024

I think we should just add the high levels as listed above and have SCORE anchor to those. That way different modalities can put own and not conflict with or have to include SCORE... However maybe we only want to put Data-property/Data-artifact-type in the standard schema and then let individual schema modalities (such as the upcoming MOBI schema) organize their own hierarchy of artifacts and not conflict with anything or be forced to include unrelated libraries.

@dorahermes
Copy link
Member

Per discussion with @monique2208 the non-biological-artifact category is an exclusive category that does not make sense from an ontological perspective.

We have 2 options:

  1. Group the non-biological artifacts directly under artifact
  2. We can create other sub-categories, such as
  • Environmental-artifact, which could include Power-supply-artifact, Artificial-ventilation-artifact, Dialysis-artifact and Induction-artifact
  • Device-artifact / Electrode-artifact would include Electrode-pops-artifact and Salt-bridge-artifact

We agreed that 1) would be the best for now.

@VisLab
Copy link
Member Author

VisLab commented Feb 21, 2024

Addressed in PR #140

VisLab added a commit that referenced this issue Feb 26, 2024
@dorahermes
Copy link
Member

It seem like this issue had been resolved and can be closed?

@VisLab
Copy link
Member Author

VisLab commented Mar 11, 2024

This is now being handled in issue #144

@VisLab VisLab closed this as completed Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants