extending/optimizing CommonCoordinateSpace schema

lzehl commented 3 years ago

Currently CommonCoordinateSpace schema asks for the following properties:

anatomicalAxesOrientation: linking to an AnatomicalAxesOrientation
axesOrigin: linking 2 or 3 QuantitativeValues
defaultImage: linking to the template File (default image)
digitalIdentifier: linking to a DOI
fullName: stating the full name as string
homepage: linking to an URL
howToCite: stating preferred citation text as string
nativeUnit: linking to the native UnitOfMeasurement
ontologyIdentifier: stating to preferred ontology as string (format: IRI)
releaseDate: stating to release date as string (format: date)
shortName: stating the full name as string

Would it make sense to extend this?

I realized that we at least miss a "description" and/or "definition" property (optional).
The digitital ID should potentially also allow RRID and ISBN

Is it in addition necessary to create a new schema that captures most important visualization metadata for images? Or do we rely on the data (file format) to capture this?

@UlrikeS91 @tgbugs @dickscheid @aeidi89 @skoehnen @xgui3783 what do you think?

xgui3783 commented 3 years ago

re: digital ID , description & definition -> no strong opinion. From consumer side, it's nice to be able to show additional info

re: most important visualisation metadata for image, I somewhat agree that we should rely on data (file format). To me, visualisation feels like not a attribute of CommonCoordinateSpace, but of defaultImage (?)

lzehl commented 3 years ago

@xgui3783 yes I should have been more explicit here. The visualization metadata would be not for the CommonCoordinateSpace but a new schema (maybe called Image) that can point to a File schema (or the other way around).

UlrikeS91 commented 3 years ago

I realized that we at least miss a "description" and/or "definition" property (optional).

Same question as in the annotation issue: Can you elaborate on this? I'm not sure what this will be good for.

The digitital ID should potentially also allow RRID and ISBN

Yes, and in addition: Same for BrainAtlas and BrainAtlasVersion. Those have ISBN already, but RRID is needed. At least, the WHSSD atlas needs it ;)

Is it in addition necessary to create a new schema that captures most important visualization metadata for images? Or do we rely on the data (file format) to capture this?

No clue :D Not my field of expertise ;)

lzehl commented 3 years ago

@UlrikeS91 thanks for your points. To elaborate on "description" for CommonCoordinateSpace: in principle a CommonCoordinateSpace is a research product (a specific dataset type). Not all CommonCoordinateSpaces we want to register are also going to be registered as a DatasetVersion (question here to make this relation explicit should we add a property: "relatedDataset"?). For this reason a short "Definition"/"Description" about the CommonCoordinateSpace would be helpful I think (like 2-3 sentences; I think we can copy them from most homepages).

Majpuc commented 3 years ago

Is it in addition necessary to create a new schema that captures most important visualization metadata for images? Or do we rely on the data (file format) to capture this?

For experimental image data, it would be useful to have schemas capturing in-depth metadata at some point. Not only file format but i.e. pixel size, voxel size, nb channels, etc.. We actually already need this kind of metadata and don't have it.

lzehl commented 3 years ago

@Majpuc do you already have a complete list of metadata that you need? If yes, could you provide a complete list (if possible, inlc short description of what each property means, and what value you would expect)?

Majpuc commented 3 years ago

@Majpuc do you already have a complete list of metadata that you need? If yes, could you provide a complete list (if possible, inlc short description of what each property means, and what value you would expect)?

I will prepare such a list. Thanks!

lzehl commented 3 years ago

@Majpuc thank you :smile:

UlrikeS91 commented 3 years ago

@lzehl Thanks for the explanations. Yes, then it makes sense to have this additional property (as optional field?) and the idea to have a link to a related dataset would be nice, too. Maybe this should rather be "relatedPublication", though? Then is could link to other things too ;)

lzehl commented 3 years ago

@UlrikeS91 yes it should be optional. I think "relatedPublication" is not quite correct, because that typically covers related but not necessarily matching publications. Maybe define it as "originalPublication" and then allow DOI and DatasetVersion as type?

lzehl commented 3 years ago

And then get rid of the digitalIdentifier property, because that would be redundant.... not sure if I like that.... maybe the digitalIdentifier is actually enough? This can also lead to a DatasetVersion with that DOI no?

UlrikeS91 commented 3 years ago

@UlrikeS91 yes it should be optional. I think "relatedPublication" is not quite correct, because that typically covers related but not necessarily matching publications. Maybe define it as "originalPublication" and then allow DOI and DatasetVersion as type?

"originalPublication" sounds good (if we introduce it at all, see below).

And then get rid of the digitalIdentifier property, because that would be redundant.... not sure if I like that.... maybe the digitalIdentifier is actually enough? This can also lead to a DatasetVersion with that DOI no?

Thinking about it, digitalIdentifier should be enough. DOI can obviously lead to a DatasetVersion. Only question: Is there a single use case where the digitalIdentifier would NOT be the same as the originalPublication? If the answer is no, we for sure don't need "originalPublication".

skoehnen commented 3 years ago

Thinking about it, digitalIdentifier should be enough. DOI can obviously lead to a DatasetVersion. Only question: Is there a single use case where the digitalIdentifier would NOT be the same as the originalPublication? If the answer is no, we for sure don't need "originalPublication".

I could imagine someone releasing the CoordinateSpace as a dataset and then publishing a paper at a different point in time. That would be covered by such a setup, right? If we say we only care about a CoordinateSpace dataset, then I agree having both digitalIdentifier and originalPublication would be redundant.

skoehnen commented 3 years ago

@xgui3783 yes I should have been more explicit here. The visualization metadata would be not for the CommonCoordinateSpace but a new schema (maybe called Image) that can point to a File schema (or the other way around).

@xgui3783 @lzehl would this be a good time to start a discussion about the visualization metadata in a separate issue? I had discussions with both of you separately about this, maybe we should formalize it ;)

xgui3783 commented 3 years ago

@xgui3783 yes I should have been more explicit here. The visualization metadata would be not for the CommonCoordinateSpace but a new schema (maybe called Image) that can point to a File schema (or the other way around).

@xgui3783 @lzehl would this be a good time to start a discussion about the visualization metadata in a separate issue? I had discussions with both of you separately about this, maybe we should formalize it ;)

Can we spin this into a separate issue to keep this thread on issue?

skoehnen commented 3 years ago

Can we spin this into a separate issue to keep this thread on issue?

Yes, that is what i meant, we should not discuss this here ;) I opened #140, we can do it there.

lzehl commented 3 years ago

@skoehnen @xgui3783 thanks good idea. @Majpuc when you provide the list, please do so in #140 thank you :)

aeidi89 commented 3 years ago

Hi, I had a quick read-through, it looks good to me.

openMetadataInitiative / openMINDS_SANDS

extending/optimizing CommonCoordinateSpace schema #138