Adding schema for individual components

[marshallmcdonnell]

This is an umbrella ticket for adding the initial draft of schema to SciData.

The plan is to create small, modular schemas to facilitate structuring the larger overall SciData schema (see Structuring complex schema )

Schemas:

• Basis Set
• Calculation
• Chemical
• Compound
• Computer
• Condition
• Dataset (PR Re #5 - Dataset schema #9)
• General (skip?, see Issue General context - is it needed? #12)
• Material
• Measurement (PR Re #5 - Measurement schema #11)
• Methodology
• Molecular System
• Organism
• Parameter (PR WIP: Re #5 - Parameter schema + refactor for Unit and Value schemas #8)
• Procedure
• Resource (PR Re #5 - Resource schema #10)
• Sample
• Software
• Substance
• System
• Target
• Unit (PR Re #5 - Unit schema #6)
• Value (PR Re #5 - Value schema #7)
• SciData (Overall)

[stuchalk]

Marshall, this is awesome and something that will really help users to implement SciData. Just so you know because of my NSF grant I will be revising SciData when I find data elements that need to be represented but cannot logically fit into the current framework (i.e. safety info, results, etc.). So, the spec will change over time...

Two other thoughts:

• We should think about is how to link the semantic representation of the data element in ScIData into a JSON Form. It would be amazing if when a JSON Form is defined it not only represents the datatype but also the semantic meaning. If this were possible it might be that you could link (automatically) a controlled vocabulary or database of ontologically defined entities. The result would be a form populating a field with a dropdown menu or a live search box that only allows specific values to be entered.
• In the context a form is used it would be great if before the form is rendered it automatically pulls local settings for some of the fields so they do not have to be shown (e.g. current userid etc.). Maybe this is not part of a JSON form but a local add-on that defines elements to be pulled in in the background.

I am happy to work with you to iterate the forms - if we can get them to fit your need then that is a paper we can write to get others to do the same :)

[marshallmcdonnell]

So, the spec will change over time...

Understood and no problem, this will get some initial schema down and can modify them with changes to SciData.

It would be amazing if when a JSON Form is defined it not only represents the datatype but also the semantic meaning. If this were possible it might be that you could link (automatically) a controlled vocabulary or database of ontologically defined entities. The result would be a form populating a field with a dropdown menu or a live search box that only allows specific values to be entered.

Completely agree! Not exactly sure all the details but have that same goal in mind. As the schema and JSONForms get more complete to the full SciData scope (as is now), we should probably have a discussion on how to move stuff forward that way.

In the context a form is used it would be great if before the form is rendered it automatically pulls local settings for some of the fields so they do not have to be shown (e.g. current userid etc.). Maybe this is not part of a JSON form but a local add-on that defines elements to be pulled in in the background.

Yes, agree, if there is say a login to populate userid and then author information, that can all get dropped from the JSONForm UI and already be in the JSON-LD in the background or if you have some Guest login, they can fill that in instead. Just a thought up example. I have some of the defaults in the main SciData schema I plan to do that way (ie "author type" is one that probably won't change or limit it to a drop-down of choices

scidata/examples/ph.jsonld

Line 21 in 9e0149e

"@type": "dc:creator",

)

I am happy to work with you to iterate the forms - if we can get them to fit your need then that is a paper we can write to get others to do the same :)

Sounds great! 👍 and definitely more than happy if you postdoc wants to contribute and be an author if so.

Thanks for feedback! I'll try to keep track of PRs for all these here as they come in.

[SmithRWORNL]

@marshallmcdonnell I need permission to push a branch on this repo for this issue.

[marshallmcdonnell]

@stuchalk is it okay to include @SmithRWORNL as a contributor to this repo so we can work on the schema directly (instead of from a fork)?

[stuchalk]

I already invited them... :)

[marshallmcdonnell]

Awesome, thanks! @SmithRWORNL let us know if you are still blocked.

[SmithRWORNL]

Addressed by #25

[marshallmcdonnell]

@stuchalk just an update, @SmithRWORNL has all the schema in for this ticket so closing it out.

I did mark through the schema that were not created in this original ticket because those entities no longer exist in the SciData JSONLD framework.

I'll open a separate ticket to do the packaging of the schema as a library (i.e. for python)

We would use this to validate SciData JSONLD for web services