Introduce fields in schema to describe synthetic data

[WardLT]

Our initial schemas focused only on data from battery cycling experiments. This PR is a first step towards expanding the types of data and adds fields associated with describing modeling data.

While at it, I'm starting to map the fields I create to the BattINFO ontology (see #30)

Fixes #62

To do list:

• Check with @jsimonclark that our approach to mapping schema fields isn't terrible. We we can go through further refinements later
• Capture software name, type and version number

[coveralls]

Pull Request Test Coverage Report for Build 9006896709

Details

• 71 of 73 (97.26%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+1.0%) to 83.0%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
batdata/schemas/ontology.py	43	45	95.56%

Totals
Change from base Build 8989303579:	1.0%
Covered Lines:	747
Relevant Lines:	900

---

💛 - Coveralls

[WardLT]

@jsimonclark, if you (or someone else from BattINFO) do get a chance to look at this, here are the two parts of relevance:

• A high-level description of how use use BattINFO: https://github.com/ROVI-org/battery-data-toolkit/blob/synth-schema/docs/schemas.md
• Our python implementation for using the ontology to generate fields names, which I'm going to use when rendering documentation - https://github.com/ROVI-org/battery-data-toolkit/blob/synth-schema/batdata/schemas/ontology.py

[jsimonclark]

@WardLT, this is looking really neat!

It looks like you are using BattINFO as a source for things like labels, elucidations, and as a "see also" reference for some of your fields. The mapping is done by adding an iri field to the class description, like in how you treated nominal_capacity.. Is that a correct summary?

This is a good approach to start integrating BattINFO terms. The real power of RDF comes when you start making graphs, which opens things up for semantic querying via SPARQL, machine-readable linking with other sources, and easier automation. JSON-LD is usually my recommended way for doing that, because it is easy to understand and can build on existing JSON infrastructure. Let me know if you'd like to discuss and we can setup a call.

[jsimonclark]

Also, for bibliographic and general metadata, keep resources like schema.org and dcterms in mind. I'm especially a fan of schema.org because it strikes a good balance of simplicity and features - and it helps with findability in Google or other search engines. For example, here you could map to schema:manufacturer.

[victorventuri]

I don't think I understand what this is used for...

[victorventuri]

I think I get it now, oops...

[victorventuri]

I think this looks fine, but I have not tested any of it. My main question is: we can specify the model that generated synthetic data on the metadata, but still, we have multiple cells per hdf5; how do we attribute specificities of each cell to each cell? For instance, in the case of the main synthetic data we are looking at, there is some variation in degradation parameters for each cell we store. Ideally, we would be able to recover what those are. Should there be a sub-metadata for each cell as well?

[WardLT]

@victorventuri , I agree that we've got some holes in the implementation of "multiple cells per HDF5" and I've opened up an issue to record discussion on that, #67 .

I'll go ahead and merge this PR then work on the multi-cell support in another branch.

[WardLT]

Thanks for the feedback @jsimonclark ! You've got my goals right.

I'll see if I can link to dcterms while I continue fleshing out ontology support.

I will probably need to talk to you more about going the next step in going towards better RDF/JSON-LD support. That's a new technology stack to me and I would be glad to learn from you!