DeviceType under 'electrode', 'pipette', etc

[stevewds]

Hi openMINDS team -

We are enjoying implementing openMINDS in NDI. In doing so, we've encountered something that feels a little awkward to us and wanted to raise it.

For example, for Electrode, a deviceType field is requested. But, the list of known devices include things like "CT Scanner", "microtome", etc; this list feels like it might include "electrode". So the field "deviceType' feels circular or redundant when used with some objects like Electrode or Pipette.

It might be more natural to have a Device with a Type. We would call a major class of devices "probes" (anything that measures or stimulators a subject).

I don't have a specific point to make; I'm interested to hear if maybe I'm missing something about the structure or if it also feels circular to you all, too.

Thanks Steve

[lzehl]

@stevewds first: wow :grin: it is great to hear that you implementing openMINDS in NDI :partying_face:

To your issue: I do get your point and I agree.

@apdavison @Peyman-N I think the "deviceType" is a leftover from our first attempt to create a device independent schema (@stevewds as you suggested. However this attempt failed because we have accommodate too many different devices which require all different properties to be described best). Instead we decided to use device schemas according to major classes that share most of the properties (e.g., electrode, electrode array, pipette, slicing device, etc.) and then the deviceType property should be used to further narrow it down. We did not follow up on this correctly though.

Suggestion to solve this: A) We delete DeviceType fully from all device schemas. B) We add more specific device types into the DeviceType terminology C) We split device type terminology up into specific device types.

If we go with B or C we need to discuss the types (here already split, would be pooled for B):

• SlicingDeviceTypes : microtome, vibratome, cryotome
• ElectrodeDeviceTypes : welding electrode, flat electrode, ???
• ElectrodeArrayTypes : EEG cap, linear array, 2D electrode array, tetrode, 3D electrode array, in vitro microelectrode array, flexible microelectrode array
• PipetteTypes : ???

@stevewds @apdavison @Peyman-N what do you think?

[stevevanhooser]

I don't know what sort of typing is possible. Is it possible to make an object called something like a "probe" and have more specific subtypes?

probe.deviceType probe.name

and then have a type inherit all of these types but then have more specific fields:

electrode : probe (requires probe.deviceType be of a certain set) (with fields) electrode.imepdence etc...

Then one might avoid proliferation of deviceTypes

But I don't know if this is possible in JSON-LD.

Thanks Steve

[lzehl]

@stevevanhooser to explain a bit more how this is set up at the moment.

Schemas are written in an openMINDS specific syntax.

This syntax allows us for example to define concept (or parent) schemas that hold a set of common properties that are inherited by all extending (child) schemas.

Concept schemas are not available as such but only help to reduce maintenance in the metadata model development.

The Device schema in openMINDS_core is such a concept schema, which is then extended to device classes specific schemas in other openMINDS metadata models (e.g., Electrode schema and ElectrodeArray schema in openMINDS_ephys, SlicingDevice schema in openMINDS_specimenPrep).

In some cases, we create a library of actual metadata instances (containing the actual metadata) for a specific schema. These metadata instances are provided as JSONLDs that can be validated against the schema type they specify under "@type".

At the moment, DeviceType is a schema that identifies instances of any device type, although our instances library is far from complete yet (this is why you only have these unfitting options at the moment which could be solved by providing more options; cf option B in my previous comment). To reference to a certain set of device types, you have to define a specific device type schema with then respective libraries of instances (option C in my previous comment).

Linkages to schema that have a library with "controlled" instances in openMINDS are comparable to enum lists of other standards. Doing it that way gives us just more flexibility to define additional information for an enum term (e.g., label + definition + url to external resources + etc).

I hope this explains it a bit more.

[stevevanhooser]

Thanks!