Revision of how we talk about elements of openMINDS

[UlrikeS91]

In the context of the openMINDS article, @lzehl and I struggled with using consistent terminologies to refer to parts of the openMINDS framework. We discussed and propose the following:

openMINDS infrastructure/framework = everything provided under the "openMINDS umbrella" (i.e., schema, instances, supportive tooling)

openMINDS schema = single metadata schema (i.e., the property-value pairs for one specific context that provides information about all possible/allowed ways to use it)

openMINDS instance = an instantiated schema (i.e., one possible way to use an openMINDS schema)

openMINDS instance/library module = GitHub repo for instances

openMIDNS tool module = GitHub repos for tooling

openMINDS model = all schemas across all GitHub repos

openMINDS schema module = all schemas within one GitHub repo

openMINDS submodels = subset of schemas within or across different GitHub repos that build a logical graph structure

'schema module' --> maintenance for larger submodels (i.e., one part of the whole openMINDS framework)
'(sub)model' --> logical graph structure

[apdavison]

My initial reaction:

openMINDS infrastructure/framework = everything provided under the "openMINDS umbrella" (i.e., schema, instances, supportive tooling)

I think we should stick to a single term for this, I think "framework" is the more appropriate term.

openMINDS schema = single metadata schema (i.e., the property-value pairs for one specific context that provides information about all possible/allowed ways to use it)

openMINDS instance = an instantiated schema (i.e., one possible way to use an openMINDS schema)

I don't like "instantiated schema". Rather, I would say "metadata document (that is) compliant with an openMINDS schema"

"node" rather than "document" could also be used, as long as it is established we're working in a graph-based framework.

openMINDS instance/library module = GitHub repo for instances

I would reserve the word "module" only for schemas. For collections of instances I would use "library" and/or "vocabulary".

openMINDS tool module = GitHub repos for tooling

As noted above, I would not call this a module, just a tool.

openMINDS model = all schemas across all GitHub repos

This is ok, but I would avoid using "model" as much as possible given how overloaded the term is; e.g., only use it in a context like "the openMINDS schema collection (also refererred to as the openMINDS metadata model)".

openMINDS schema module = all schemas within one GitHub repo

yes, or just "openMINDS module". The fact we're using a GitHub repo is an implementation detail, more important is that the schemas in the module are in general thematically related (the possible exception being "core").

openMINDS submodels = subset of schemas within or across different GitHub repos that build a logical graph structure

'schema module' --> maintenance for larger submodels (i.e., one part of the whole openMINDS framework) '(sub)model' --> logical graph structure

I'd need to see this in a broader context before having an opinion.

[lzehl]

• framework
• instances / instance libraries
• schema module

combinatorics of tags

• targets
• tooling
• programming package
• converters
• documentation
• schema formats

[UlrikeS91]

Here the updated terminology:

GENERAL

terminology	definition
openMINDS framework	everything provided under the "openMINDS umbrella" (i.e., schema, instances, supportive tooling)
'module'	thematical grouping, primarily for maintenance reasons
'model'	logical grouping (i.e., form a logical graph structure)

SCHEMA-RELATED

terminology	definition
openMINDS (metadata) schema	single metadata schema (i.e., the property-value pairs for one specific context that provides information about all possible/allowed ways to use it)
openMINDS (schema) module	multiple schemas thematically grouped; they may not represent a logical graph structure on their own (i.e., all schemas within one openMINDS GitHub repo)
openMINDS (metadata) submodel	subset of openMINDS schemas within and/or across openMINDS modules representing logical graph structures (i.e., minimal metadata representation of a research product using selected schemas from the openMINDS 'core' and 'controlledTerms' modules)
openMINDS (metadata) model	all openMINDS schemas (i.e., all schemas across all openMINDS GitHub repos)
openMINDS vocabulary	all properties, schema types and categories used in the openMINDS metadata model

The parts in brackets should be used whenever elements are presented out of context, but can be skipped when the context is clear (e.g., in the openMINDS article it would be ok to alternate between 'openMINDS metadata model' and the shorter version 'openMINDS model' as long as it was first introduced as 'openMINDS metadata model' and the context is still clear).

Theoretically, there would also be openMINDS (schema) submodules since we do have thematic grouping within one GitHub repo (e.g., openMINDS extensions are organized by 'activity' and 'entity' (and 'device' in some cases)). But I don't think that we should make this even more complicated than it already is.

INSTANCE-RELATED

terminology	definition
openMINDS instance	an instance compliant with a specific openMINDS schema (i.e., one possible way to use a specific openMINDS schema)
openMINDS instance library	all instances compliant with a specific openMINDS schema provided as a folder in the openMINDS_instances GitHub repo
openMINDS terminologies	all instances compliant with any openMINDS schema from the openMINDS 'controlledTerms' module

TOOL-RELATED

terminology	definition
openMINDS tool	a tool provided through the openMINDS framework relating to the openMINDS metadata model in some way (e.g., documentation, code packages, other schema formats, converters)

TOOL-RELATED TAGS (for GitHub repositories)

Can be used separately or in combination:

tag
'target'
'tooling'
'programming package'
'converter'
'documentation'
'schema format'