Schemaorg: https://schema.org/subtype is a terrible name for a property and needs to be changed
I don't know how we missed this before (and apologies if someone has pointed it out already).
The medical/health vocabulary uses "subtype" for some relatively niche use. Unfortunately, subtype (also known as "sub class", e.g. rdfs:subClassOf) is a very commonly used phrase in our kind of data modeling. This needs to be renamed.
A more specific type of the condition, where applicable, for example 'Type 1 Diabetes', 'Type 2 Diabetes', or 'Gestational Diabetes' for Diabetes.
Perhaps "moreSpecificMedicalCondition"?
I do not know of anyone explicitly consuming this schema.org markup, beyond generalized support (ML models or suchlike), i.e. documented tools/features/services based on this and other medical/health terms.
/cc @vholland @scor @tmarshbing @nicolastorzec @rvguha
danbri
All 4 comments
I propose adding a property with the same definition, called "moreSpecificMedicalCondition", and marking "subtype" as supersededBy moreSpecificMedicalCondition.
@twamarc - does that sound ok medically?
danbri
on 4 Sep 2018
Looking at this further, and consulting Guha, this is a pretty extremely confusing case, enough to justify eventually removing this sense of "subtype" from our definitions. We could stage that with a phase inviting consumers of the original sense to comment, but in absence of that sort of evidence, the usability/clarity case for removing it is pretty strong.
Specifically: https://schema.org/docs/search_results.html?q=subtype shows that we have used the phrase "subtype" throughout our documentation in the general data modeling sense. To have an unrelated use of that phrase in our vocabulary is only going to confuse people needlessly.
danbri
on 4 Sep 2018
Another similar area that causes some confusion for me at least is the notion of sub-properties and super-properties. I am unclear what if any rules apply to expected types for sub- and super-properties. For example, the property yield has sub-property of recipeYield. yield has an expected type of HowTo while recipeYield has an expected type of Recipe. Recipe is a sub-type of HowTo.
It seems intuitive how to use sub-properties when they relate to same entity type as the super-property -- just choose the best fit. But it is unclear to me if a HowTo, which can have a performTime can also have a cookTime -- a sub-property of performTime not listed in the HowTo property list (maybe you are cooking paste for wallpaper or something.) Do sub-properties behave differently from other kinds of properties that are associated with sub-types?
Perhaps this is just a gap in documentation. But if someone want to explain how sub-properties work, I can work to get this added to the community documentation.
MichaelAndrews-RM
on 6 Sep 2018
Removal of subtype implemented
RichardWallis
on 3 Jul 2020
Related issues
danbri
路
5Comments
Muhaiyuddin
路
4Comments
jaygray0919
路
3Comments
thadguidry
路
5Comments
mariusvetrici
路
4Comments
Most helpful comment
Looking at this further, and consulting Guha, this is a pretty extremely confusing case, enough to justify eventually removing this sense of "subtype" from our definitions. We could stage that with a phase inviting consumers of the original sense to comment, but in absence of that sort of evidence, the usability/clarity case for removing it is pretty strong.
Specifically: https://schema.org/docs/search_results.html?q=subtype shows that we have used the phrase "subtype" throughout our documentation in the general data modeling sense. To have an unrelated use of that phrase in our vocabulary is only going to confuse people needlessly.