Organization of important topics in a SciData JSON-LD file

[stuchalk]

In some of the example files (https://stuchalk.github.io/scidata/examples/ph.jsonld) and I had included 'property' and 'type' underneath the 'SciData' section. In the current version of the library as I thought that it was not needed if the 'ids' JSON array was populated.

In addition, I have been considering updating scidatalib to have every metadata element (as appropriate) be represented as text or as an id (JSON-LD '@id'). For example 'unit': 'kg' or '#unit': 'qudt:KiloGM'. Then all the '#labels' would be 'ids' section at the top of the file.

Thoughts? Is there something else useful that might be stored in 'type' and/or 'property' that would not be in some other part of the document?

[marshallmcdonnell]

@stuchalk Great, thanks for the guidance!
Switching over the ids sounds like a much better idea!
I cannot readily think of anything that would then require "type" or "property"

[stuchalk]

Still, I wonder if there is a need to have additional high level descriptors that can captured in 'property' and 'type' that would not be added elsewhere. So, as an example for your work, 'property' = 'raman spectrum' and 'type' = '2D spectrum' (and associated ontological ids). In essence I am saying that for an entry the ids section it has to also appear within the 'scidata' section of the JSON-LD file.

[marshallmcdonnell]

Hmm, I think the pros and cons are:

• Keeping them in allow for more flexibility to annotate IF you can't do so with the ids and other entries in the SciData JSON-LD
• Taking them out removes that convenience to just use "property" and "type" instead of describing the data using ontological values in the JSON-LD (hope I am saying that right 😁)

I'm fine either way, not sure which is the best route to go. 🤷‍♂️

[stuchalk]

I think in the end users will decide the metadata that they need to store the context of their data. As an end user, if you feel like you can make do with the current functionality and don't need property and type right now that's good for me. We can revisit when additional users ask these questions/make these comments...

[marshallmcdonnell]

@stuchalk Okay, I have ran back across this now while working on Issue #49

I want to read in a JCAMP file into a SciData object (or just get a SciData JSON-LD format) and then, for the above issue, write back out the exact same file.

My issue is for the "DATA TYPE" line in this example file:
https://github.com/ChalkLab/SciDataLib/blob/61f60d04e9c443ac138d37eb708511031f30a416/tests/data/jcamp/raman_tannic_acid.jdx#L3

I can see using an ontological value from ontobee to specify which type of spectroscopy (http://www.ontobee.org/ontology/CHMO?iri=http://purl.obolibrary.org/obo/CHMO_0000331) but then I'll need to map back from this in the SciData JSON-LD format to "#DATA TYPE=RAMAN SPECTROSCOPY" for writing the JCAMP file.

I could see where the general "property" and "type" could really help out.
Do you have any guidance?

[marshallmcdonnell]

If it helps, these are the other "DATA TYPE" fields we have in the test data right now:

tests/data/jcamp/mass_ethanol.jdx
3:##DATA TYPE= MASS SPECTRUM

tests/data/jcamp/raman_tannic_acid.jdx
3:##DATA TYPE=RAMAN SPECTRUM

tests/data/jcamp/infrared_ethanol.jdx
3:##DATA TYPE=INFRARED SPECTRUM

tests/data/jcamp/infrared_ethanol_compressed.jdx
4:##DATA TYPE=INFRARED SPECTRUM

tests/data/jcamp/infrared_compound_file.jdx
3:##DATA TYPE= LINK
9:##DATA TYPE=INFRARED SPECTRUM
548:##DATA TYPE=INFRARED SPECTRUM

tests/data/jcamp/uvvis_toluene.jdx
3:##DATA TYPE=UV/VIS SPECTRUM

tests/data/jcamp/neutron_emodine.jdx
3:##DATA TYPE= INELASTIC NEUTRON SCATTERING

tests/data/jcamp/hnmr_ethanol.jdx
5:##DATA TYPE=LINK
87:##DATA TYPE=NMR PEAK ASSIGNMENTS
105:##DATA TYPE=NMR SPECTRUM
131:##DATA TYPE=NMR SPECTRUM