YES!

There was an earlier discussion on this started by @danbri in #3250, which went stale at some point. Yours, Steffen

Discussion from bioschemas issue 863 created by @meier-rene

Similar to the keywords property which has been updated to include DefinedTerm, many keyword-like properties like measurementTechnique could also benefit from the inclusion of DefinedTerm in the range of the property. Adding the DefinedTerm as a potential expected type for measurementTechnique is beneficial as it could be faster to serve the information if it's stored as a DefinedTerm rather than have to request and parse additional data from a URL, and it would be cleaner and more sensible than plain Text.

I strongly support this. I have created this issue at the issue board of the bioschemas community.

A little bit of explanation:
In the live sciences, but also in other scientific disciplines, the different community have started to build up ontologies/controled vocabularies to harmonize the description of scientific data with proper metadata. In schema.org the natural type to accommodate these CV terms is the DefinedTerm.

When we add structured data to scientific data we like to use the type DataSet, because its properties fit to the data we want to describe. The properties measurementTechnique and variableMeasured belong to the most important properties for scientific data. The property variableMeasured can be of type PropertyValue, which again has a property measurementTechnique. This perfectly fits our needs. But as pointed out above the proper type to describe a measurementTechnique would be the DefinedTerm. Of course it would be possible to squeeze the reference to a CV term in a Text or URL type, but in the end its more demanding to get that information back and there is a perfect type for that in schema.org.

Thats why I ask you to please add DefinedTerm as expected type to measurementTechnique.

While I am wary of adding DefinedTerm indiscriminately across all of schema.org, it does make sense at least for measurementTechnique. Any others that are high priority to folks here?

Done! This is in release 19.0, just pushed to the live site.

Nearby (and still needing attention), #3125

@danbri-- @ljgarcia and @nsjuty are still in the process of reviewing properties that would benefit from having DefinedTerm in the range. So far, they have identified the following properties:

• encodingFormat
• applicationCategory
• applicationSubCategory
• featureList
• operatingSystem
• programmingLanguage
• courseMode
• eventStatus
• variableMeasured

More details here: BioSchemas/specifications#618 (comment)

@gtsueng, @ljgarcia, @nsjuty, I have an overlapping question (#3328) in regards to the use of featureList specifically. Do any of you have thoughts about this?

@meier-rene @chrisspradling1980 @sneumann
DefinedTerm has been added to the range for a number properties, see https://schema.org/docs/releases.html

@jvandriel featureList is not in the list, see https://schema.org/DefinedTerm
We are working on a number of other properties what would benefit of having DefinedTerm in the expected range. However it is in our list so it will be added on the Bioschemas side. Hopefully schema.org will do it later. We will ping them from our PR

I noticed featureList in @gtsueng's last comment, hence the callout.

This issue is being nudged due to inactivity.

From the side of NFDI4Biodiversity and after a discussion with @sneumann, we strongly support this effort especially for variableMeasured where we would like to link to standard variables. Our partner PANGAEA @uschindler is using subjectOf to introduce defined terms from CHEBI, PATO and QUDT. An example can be found here: https://doi.pangaea.de/10.1863/PANGAEA.952033?format=metadata_jsonld

Example again, this time it is clickable: https://doi.pangaea.de/10.1863/PANGAEA.952033?format=metadata_jsonld

propertyID should take a DefinedTerm.

SubjectOf doesn't make sense to me, why not use propertyID, its already available for sdo:PropertyValue? measurementTechnique already allows a DefinedTerm, the instrument URI information makes more sense there. here's a modified extract from @uschindler example:

{
    "@type": "PropertyValue",
    "name": "Fluorescence, dissolved organic matter",
    "unitText": "cts",
    "measurementTechnique": {
        "@id": "SDN:L22::TOOL0114",
        "@type": "DefinedTerm",
        "identifier": "SDN:L22::TOOL0114",
        "name": "WET Labs {Sea-Bird WETLabs} ac-3 absorption and attenuation meter",
        "url": "http://vocab.nerc.ac.uk/collection/L22/current/TOOL0114/"
    },
    "propertyID": [
        {
            "@id": "urn:obo:pato:term:0000018",
            "@type": "DefinedTerm",
            "identifier": "urn:obo:pato:term:0000018",
            "name": "fluorescence",
            "url": "http://purl.obolibrary.org/obo/PATO_0000018"
        },
        {
            "@type": "DefinedTerm",
            "name": "dissolved organic matter",
            "alternateName": "DOM",
            "url": "https://en.wikipedia.org/wiki/Dissolved_organic_carbon"
        },
        {
            "@type": "DefinedTerm",
            "name": "Abundance or Count",
            "url":"http://qudt.org/vocab/quantitykind/Count"
        }
    ]
}

additionalType should also take a DefinedTerm.