Move suggested vocabularies to the vocabulary server

kobbejager commented 2 months ago

In order to make suggested vocabularies more consistent, easier to extend and easier to migrate to a controlled vocabulary at some point in the future, we should move the suggested vocabularies to Opentheso.

kobbejager commented 2 months ago

I have copied all blocks containing the suggested vocabularies into a new schema "example_lists.schema.json" (currently in the "examplelists" branch only). This is only temporary to have an overview of the existing intances of suggestedVocabularies.

Does the following workflow makes sense?

[x] Add all terms to groups in Opentheso and ecls (@jpadfield)
[x] Create handles and add them to ecls config.json (@kobbejager / @jpadfield )
[x] Update the definitions in example_lists.schema.json to make use of the ecls handles (@kobbejager)
[x] Remove the suggestedVocabularies in all schemas and replace them with $refs to the definitions (@kobbejager)
[x] Add script to (re)build the lists in cordra (@kobbejager)

jpadfield commented 2 months ago

[x] Can we combine the link_type list and the has_url lists? Or did we have a clear diference here?
[x] In the current link type list can we change some of the labels such as "developer", "contributor", and "funder" - The terms are too vague and could be types of people or roles or even to specific individuals? We could have something like "developer (webpage)" or "developer (details)" etc ?
[x] Could we also add: "software download", "support", "tutorial", "reference" and possibly "media"

jpadfield commented 2 months ago

[ ] Should parameter type be merged with the notion of measurable property

kobbejager commented 2 months ago

[ ] Can we combine the link_type list and the has_url lists? Or did we have a clear difference here?

I think it would make sense to merge the two, and make them in all instances an enum, possibly with the special term 'other'. We'll need to make sure that this unified group then works for equipment, software and service links.

[ ] In the current link type list can we change some of the labels such as "developer", "contributor", and "funder" - The terms are too vague and could be types of people or roles or even to specific individuals? We could have something like "developer (webpage)" or "developer (details)" etc ?

If I recall correctly, we added 'funder' to be able to acknowledge the funder of a service. I agree that the preferred label of this term might be improved ('funder webpage' or something with 'grant'). I'm not sure what the added value is of links to developer and contributor resources. On the service level we already have 'team_members' with 'roles' - do we really need links to their personal home pages? The same applies for software ('developer') and equipment ('manufacturer'): the has_url already defines "website" which can be used for a link to the product page on the website of the developer or manufacturer.

[ ] Could we also add: "software download", "support", "tutorial", "reference" and possibly "media"

Agree!

kobbejager commented 2 months ago

[ ] Should parameter type be merged with the notion of measurable property

No, those are two entirely different things in my opinion.

'Measurable property' is what we are measuring on a set of materials. We chose to express this on a high level, e.g. 'chemical composition'
'Parameter type' is a default parameter/setting of a tool, and should be detailed. E.g. in Raman: 'laser wavelength'. This is not something we measure, but a setting.

jpadfield commented 2 months ago

How about reference_role vs reference_type the semantics might be different but the list seems to be the same really?

jpadfield commented 2 months ago

Do we need different terms when "Measurable property" and 'Parameter type' overlap then? The example I have now is "Temperature" - I think I should leave it off "Parameter type" at the moment as the "Parameter type" should be specific temperatures, such as inlet temp, oven temp, ambient temp, etc. rather than the concept of temperature?

jpadfield commented 2 months ago

We have some conflict between the research domains and software types - should we add some thing to define the difference, similar to AAT - "data acquisition (process)" - "data acquisition (field)" - or can we just leave them as the same term?

kobbejager commented 2 months ago

How about reference_role vs reference_type the semantics might be different but the list seems to be the same really?

I think that the two could indeed be merged. I guess they should be fixed enums in all instances?

kobbejager commented 2 months ago

Do we need different terms when "Measurable property" and 'Parameter type' overlap then? The example I have now is "Temperature" - I think I should leave it off "Parameter type" at the moment as the "Parameter type" should be specific temperatures, such as inlet temp, oven temp, ambient temp, etc. rather than the concept of temperature?

I thinks so, yes.

Looking at the list of measurable properties, I seem to remember that we agreed on limiting the list to the top level items ( such as chemical composition, physical properties, and that the terms below it would be examples, not selectable items. Not sure if I understood it correctly?

kobbejager commented 2 months ago

We have some conflict between the research domains and software types - should we add some thing to define the difference, similar to AAT - "data acquisition (process)" - "data acquisition (field)" - or can we just leave them as the same term?

I suppose it are different concepts, so I'm inclined to keep them separate. The AAT-like solution looks ok.

jpadfield commented 2 months ago

How about reference_role vs reference_type the semantics might be different but the list seems to be the same really?

I think that the two could indeed be merged. I guess they should be fixed enums in all instances?

We now have one list: https://research.ng-london.org.uk/ecls/?group=g19

jpadfield commented 2 months ago

We have some conflict between the research domains and software types - should we add some thing to define the difference, similar to AAT - "data acquisition (process)" - "data acquisition (field)" - or can we just leave them as the same term?

I suppose it are different concepts, so I'm inclined to keep them separate. The AAT-like solution looks ok.

At the moment they are listed in both lists but I will look at creating the new terms for these

jpadfield commented 2 months ago

We have some conflict between the research domains and software types - should we add some thing to define the difference, similar to AAT - "data acquisition (process)" - "data acquisition (field)" - or can we just leave them as the same term?

I suppose it are different concepts, so I'm inclined to keep them separate. The AAT-like solution looks ok.

@kobbejager - I am wondering if we can just leave this ... it relates to the semantics of our question: What is your field of study: "data acquisition" - What type software are you using - "data acquisition" software. IF we asked what is the purpose of your software, again it would be "data acquisition", So, I think we could be ok?? What do you think?

kobbejager commented 2 months ago

@kobbejager - I am wondering if we can just leave this ... it relates to the semantics of our question: What is your field of study: "data acquisition" - What type software are you using - "data acquisition" software. IF we asked what is the purpose of your software, again it would be "data acquisition", So, I think we could be ok?? What do you think?

I don't have enough experience with vocabularies to answer this, I'm afraid.

kobbejager commented 2 months ago

Update:

data_type, equipment_component_type, organisation_type, parameter_type and software_component_type

created handles (and pushed them to the controlled-lists repo)
configured the lists in example_lists.schema.json
referred to these lists in all schemas using $ref
changed the has_url instances into the existing controlled list link_type
changed the reference_type instances into the existing controlled list reference_role

Everything still lives in the "examplelists" branch of this repo and hasn't been pushed to Cordra.

Issues

We are apparently still missing opentheso groups for acquisition_area and parameter_unit (see: https://github.com/E-RIHS/schema/blob/examplelists/example_lists.schema.json)
We have created different lists for equipment_component_type and software_component_type (just software_type in ecls). These are used in the has_defined_components in the equipment and software schemas. Herein the component type is accompanied with a tool field that queries for all software and equipment. So in the current situation, a top level equipment can have defined components that are either equipment or software. However, the type of the component is limited to equipment types, and no software types. The same occurs in software. I think we'll need to unified component_type list.

"has_defined_components": {
    "title": "Has defined components",
    "description": "Other tools that are components of this tool",
    "type": "array",
    "items": {
        "title": "Component",
        "type": "object",
        "properties": {
            "component_type": {
                "$ref": "https://e-rihs.io/schema/example_lists.schema.json#/definitions/software_component_type"
            },
            "tool": {
                "title": "Component (equipment or software)",
                "type": "string",
                "description": "The discrete component of the software suite. This is a reference to another equipment or software object that was previously defined.",
                "cordra": {
                    "type": {
                        "handleReference": {
                            "types": ["Equipment", "Software"]
                        }
                    }
                }
            }
        }
    }
},

jpadfield commented 2 months ago

The last lists have been added: acquisition_area, parameter_unit and component_type - the component one has just been added as a combined group I have not changed the relevant terms in the vocab at all.

I have also updated the list presentation to add the bootstrap warning colours and a hover text over the groups that do not have handles defined in the config file.

kobbejager commented 2 months ago

All tasks in this issue have been done. The adapted schemas and tools are in the "examplelists" branch. This has not yet been merged with the main branch. Only the example_lists schema has been uploaded into cordra (mainly to test the updated scripts), but not the adapted schemas that refer to these example lists.

E-RIHS / schema

Move suggested vocabularies to the vocabulary server #22

Update:

Issues