Terms

[SteffenBrinckmann]

As continuation of the PR from @FlorianRhiem, ...
Until now we have not discussed any key-naming-conventions and then people started talking 'comment', and 'person', ....

• I would suggest to keep version 1.0 of the scheme without any conventions. That allows everybody to reach level 1 (having non-moving targets is great for that)

• version 2.0 is thereby the eln that has agreed-upon key-names. Do you agree?

• Could we create a list of keys and their synonyms: {"person": ["author","creator"...]} which is json and can be parsed?

  • This list should live somewhere in the root of this repo.

[NicolasCARPi]

version 2.0 is thereby the eln that has agreed-upon key-names. Do you agree?

No, I'd say we are currently version 0 and working toward a version 1.

Could we create a list of keys and their synonyms: {"person": ["author","creator"...]} which is json and can be parsed?

I'm not sure I understand what you mean, but see my examples folder README:

See https://github.com/TheELNConsortium/TheELNFileFormat/blob/master/examples/elabftw/README_template.md#concepts-used

eLabFTW concepts	JSON property
tags	keywords
links	mentions
comments	comment
steps	in elabftw-export.json
elabid	identifier
title	name
body (main content)	text

There are concepts that can fit perfectly in the json (like comments, or user -> person) and others that might be too specific (like steps in elab). My point is that we should use as much as possible the metadata file to store information in a defined manner and for the rest it can be done in another json file (which could have a comon name btw!).

I believe we are also close to a point where doing a meeting with all involved via zoom could help discuss things.

[SteffenBrinckmann]

Regarding the version numbering: why start counting from 0, did you ever use Fortran77 ? ;-)
I emphasize, lets do things step by step

1. first get the file format working that "https://pypi.org/project/rocrate/" can parse all files and that the file-format is correct. We can call this version 0.5 if you don't want to spoil 1.0.
2. then find agreements on the terms; which would involve zoom.

Lets do small-steps, instead of complicated big steps; which also makes the validator easier.

[FlorianRhiem]

I think we should try to keep following the schema.org nomenclature for these, e.g. for a Person there's a list of all instances where this entity may be referenced/used, including the author property of a CreativeWork. We could try to limit which generally allowed properties each entity might actually have to make it easier to find a common standard (e.g. the creator property of a CreativeWork can also be used instead of author, which leads to ambiguity).

[SteffenBrinckmann]

I guess it is rather simple now that we all have a common format, to parse each entity, get all keys and then use set-operations to find a list of all used keys in all entities.
Could that approach be helpful?

[NicolasCARPi]

Yeah it makes sense, we could even plot an histogram. This could help figuring out if we have an outlier (from a typo or other cause).

[SteffenBrinckmann]

eln_validator has now the '-c' = '--count' option to report the count of entities.