additionalType

[NicolasCARPi]

Hello all!

I'm in the process of allowing making a .eln that contains both experiments and resources (the two main entity type in elabftw). Previously, it was only one or the other.

In order to convey that information, I chose to use the additionalType property of the @type: Dataset.

So during import, I look at the additionalType property , to figure out if this node describes an experiment or a resource (which in elab can be anything like an antibody or a microscope).

The value could simply be: "experiments" or "resources". But if I create this issue it is to discuss with you what could be the best approach regarding the value.

I'm thinking of using http://semanticscience.org/resource/SIO_000994. And the code basically is: if it's that URI, it's an experiment, otherwise it's a resource. There are many others to choose from: https://lov.linkeddata.es/dataset/lov/terms?q=Experiment

So if on your side you've already digged into these aspects, please let me know here so that I can use the same as you!

[nicobrandt]

I can give some input on how we currently use additionalType in the Kadi export. We allow users to (optionally) specify an arbitrary type value within the basic record metadata, such as "experiment", "device", "document", etc., which we just put into additionalType as is. In some sense, this can be seen as an additional keyword with some inherent semantics.

That being said, these types don't follow a standardised vocabulary. Therefore, if we settle on something here, we would probably need to either move this type somewhere else or remove it from the export altogether. I don't have strong feelings about it either way though. For us it mostly depends on what the import/export requirements of other systems are. In any case, I think that full interoperability of such types will be tough to achieve across all systems.

[NicolasCARPi]

Oh so you let users add anything in there? Or is there an enum/list they can choose from?

if we settle on something here, we would probably need to either move this type somewhere else or remove it from the export altogether

Why? We both independently came to the conclusion that additionalType was a good attribute to categorize further the Dataset we have. Your usage is basically the same as mine, except you're more libertarian on the value. What about import? Do you use this field? If yes, then how do you deal with arbitrary text?

I think that full interoperability of such types will be tough to achieve across all systems.

Well, that's why we're discussing it now! ;)

Also, I'm thinking of the import interface allowing to force the resulting "type". At the end of the day, asking the user what they want is an acceptable shortcut.

[nicobrandt]

Oh so you let users add anything in there? Or is there an enum/list they can choose from?

Yeah, the former.

Why? We both independently came to the conclusion that additionalType was a good attribute to categorize further the Dataset we have. Your usage is basically the same as mine, except you're more libertarian on the value. What about import? Do you use this field? If yes, then how do you deal with arbitrary text?

Sorry, I worded this unclearly. I just meant in case we ultimately settle on a fixed vocabulary. Of course if we (in Kadi) can keep it as is that would be ideal :) Regarding the import, I just checked and seems like we don't use it at all yet. However, I guess since we don't have any restrictions, there shouldn't be anything to deal with regarding the import.

Well, that's why we're discussing it now! Also, I'm thinking of the import interface allowing to force the resulting "type". At the end of the day, asking the user what they want is an acceptable shortcut.

Of course! And the option of letting users customize the import (or even export) could indeed be a solution (or at least a good workaround), not just for the types.

[FlorianRhiem]

Do you see any overlap with genre? experiment was already one of the values for it we decided on during the last meeting, resource might be another?

[NicolasCARPi]

@FlorianRhiem I forgot about it!

So I'll use genre instead of additionalType, similar to what SampleDb does. My genres will be one of:

• experiment
• resource
• template (maybe protocol / experiment template ?)

[SteffenBrinckmann]

Just my 2ct: I understood it at the last meeting as @FlorianRhiem: genre for the subtype.

[nicobrandt]

You are right, sorry. I just checked my old meeting notes and genre was indeed already suggested for this, as an optional property with a (most likely) fixed selection of strings. I guess this still leaves the question of whether additionalType can also have a place in the specification or if it could maybe just be left as an ELN-specific thing 🤔

Edit: I actually confused our ELN export with another one. We are currently not using additionalType at all in the export 🤦‍♂️ The question above is still relevant though.

[simontaurus]

Following @SteffenBrinckmann comment on #103, @type MUST be a single string value while additional types should go to genre.
I understand the point of limiting variances.
However, @type is rather central in any RDF/JSON-LD reasoning, validation and framing operation.
A workaround would be to alias genre as @type ìf required by an interpreter

{
  "@context": [
    "https://w3id.org/ro/crate/1.1/context",
    {
      "genre": "@type"
    },
    "type": "schema:Dataset",
    "genre": "ex:CustomType"
  ]
}

In this case it would be helpful to allow genre to by an array of IRIs. This would allow the TheELNConsortium to specify a list of common types while vendors can add more specific subtypes to persist internal classification.

{
  "@context": [
    "https://w3id.org/ro/crate/1.1/context",
    {
      "eln": "https://w3id.org/TheELNConsortium/",
      "elabftw": "...",
      "osw": "https://opensemantic.world/id/"
    }
  ],
  "genre": [
    "eln:Experiment",
    "osw:Category-3AOSW0e7fab2262fb4427ad0fa454bc868a0d"
  ]
}

Otherwise additionalType IRIs may be the right location for those IRIs

[nicobrandt]

I suggest moving this into a new issue rather than resurrecting this old (closed) one :P

[NicolasCARPi]

created #105 from message above.