Medical/health vocabulary as an extension #492

Closed
unor opened this Issue May 14, 2015 · 101 comments

Projects

None yet
@unor
Contributor
unor commented May 14, 2015

Would it be possible to remove the health/medical types from the main namespace and make it an extension, e.g. http://med.schema.org/?

As the Extension Mechanism documentation explains,

Schema.org provides a core, basic vocabulary for describing the kind of entities the most common web applications need.

But MedicalEntity is rather domain specific, not something "the most common" sites would use.

@danbri danbri added this to the sdo-ganymede milestone May 14, 2015
@danbri
Contributor
danbri commented May 14, 2015

Yes, we have not discussed this with @twamarc (who led an existing proposal #11 ) but given the scale and detail of our medical vocabulary this is indeed a strong candidate for conversion into a med: extension. Probably it is best to test the infrastructure with something smaller first (bib: and auto:), but thanks for starting this conversation. @twamarc - have you followed any of the discussion around the new extension model? http://schema.org/docs/extension.html has an overview...

@danbri danbri self-assigned this May 14, 2015
@twamarc
Contributor
twamarc commented May 15, 2015

I personally support this approach as a way forward (but I have not yet discussed with the group which was behind the proposal last year).
We-all of us I guess, followed with interest the recent discussions about schema extension mechanism and how things keep evolving at schema.org. I am still convinced that the medical vocabulary existing in schema.org should be improved and making it an extension, maintained by some people would help to make it robust and up-to-date.
Just looking at the proposal, some of suggested concepts have been already integrated in schema---there is a need to align the proposal to the existing schema version (eliminating duplicates, etc)

In parallel there is (since end last year) a big move towards having robust medical vocabulary and within the W3C Life science Group with the start of the HL7 ITS subgroup on RDF for Semantic Interoperability. The group is nowadays working among others on HL7 FHIR Ontology which may help/overlaps with the proposal.
Sure the group will not back the proposal but the existing of the extension will be an added value.

The 2 questions I have here (for next steps):
-should we still use the same namespace schema: or we will use something else depending to the extension, eg. med.schema: ?
-Is there a mechanism (a developer's site ) to maintain the proposal or we need to that in an external API?

@danbri
Contributor
danbri commented May 19, 2015

@twamarc thanks for your reply, and your patience.

To answer your specific questions:

1.) Each hosted extension (http://schema.org/docs/extension.html) will be assigned a short code name. This is used as a folder name in the codebase (e.g. data/ext/bib/* for bibliographic), and when publiched as a subdomain in the site (i.e. we will eventually have bib.schema.org). Q: would 'med' be an adequate short name for the vocabulary we discuss here? (rather than something alluding to 'healthcare', 'life science' etc.?).

However, do note that unlike "classic RDF Linked Data" the names assigned within the extension should be designed to be used alongside all other terms (from the core and even from other extensions). This means that we still need some central coordination, and that names of type/property/enum terms should be specific. For example, we made a previously by using "/action" to mean "muscle action", and we will need to create a workflow based around the new W3C Community Group and Github to help improve our naming choices. This new extension mechanism was only announced fully last week with the v2.0 release, and there are still some tooling and workflow issues to finalize.

2.) ... consequently there is not yet full documentation for developers of extensions, beyond the high level notes in http://schema.org/docs/extension.html

For now, everything is in Github. We do have a special label here (for issues and pull requests) regarding extensions.

For a path forward for Medical/Health I suggest,

  • confirm whether we think 'med' is a reasonable short name for the scope of this work.
  • Let's prepare here a 3-4 sentence overview of the extension. We should say how it interacts with the core. I've made a rough draft below as a conversation starter only, including a sketch of the kind of workflow template we'll need to standardize as we improve the Extensions documentation.
  • Technical work of revisiting the draft in #11 and re-structuring it as 1. changes to data/schema.rdfa 2. an extension in data/ext/med/medvocab.rdfa 3. update examples accordingly.

For example would this be a fair initial template description?:

"""The medical extension refines and improves schema.org's medical/healthcare vocabulary that was initially published in 2012 (see http://blog.schema.org/2012/06/health-and-medical-vocabulary-for.html http://schema.org/docs/meddocs.html ). Taking into various integration points post-2012 changes (e.g. Audience, action / muscleAction), it moves schema.org's detailed treatment of medical terminology into a extension called 'med'.

  • The following terms are moved (todo: list).
  • The following terms are renamed (todo: list) with the core.
  • The following terms are renamed (todo: list) and moved into the extension.
  • The following terms are created (todo: list) within the core.
  • The following terms are created (todo: list) within the extension.
  • The following somewhat medically-related terms remain in the core (todo: list, e.g. http://schema.org/Recipe).
  • The following extension-related discussions are noted as relevant (todo: list, e.g. GS1, nutrition/food, ...).
  • The following related standards groups have been identified and invited to comment. (todo: list).
  • [ ](meta: did I miss any obvious workflow questions --@danbri?) """
@danbri danbri changed the title from Can we make MedicalEntity an extension? to Medical/health vocabulary as an extension May 19, 2015
@twamarc
Contributor
twamarc commented Jun 12, 2015

Hi Colleagues,
Hi Dan Brickley,

Here are some preliminary informations to start the health.schema.org Extension.

  1. The name: #health.schema.org (See votes communicated earlier)
  2. The short overview of the extension: See twamarc/ScheMed#1)
    "
    The medical extension refines and improves schema.org's medical/healthcare vocabulary that was initially published in 2012 (see http://blog.schema.org/2012/06/health-and-medical-vocabulary-for.htmlhttp://schema.org/docs/meddocs.html ).
    Taking into various integration points post-2012 changes (e.g. Audience, action / muscleAction, Enumeration), and with community effort to extend and polish existing version (e.g adding other concepts like the Medical Encounter, Medical Procedure, Health, Health Insurance, Genetics ) , it moves the existing schema.org's medical vocabulary into a dedicated extension called 'health.schema.org.
    "
    3)Technical work of revisiting the draft in #11 and re-structuring: ONGOING

PLANNED:
4) The list of terms that are moved (todo: list).
5) The list of terms that are renamed (todo: list) with the core.
6) The list of terms that are renamed (todo: list) and moved into the extension.
7) The list of terms that are created (todo: list) within the core.
8) The list of terms that are created (todo: list) within the extension.
9) The list of terms that are somewhat medically-related terms but remain in the core (todo: list, e.g. http://schema.org/Recipe).
10)The list of extension-related discussions that are noted as relevant (todo: list, e.g. GS1, nutrition/food, ...).
11) The list of terms that are related standards groups that have been identified and invited to comment. (todo: list).

12)Coordinate with Food type (help further with foodWarning and recipeIngredient) #458

Regards,
Marc

@danbri
Contributor
danbri commented Jun 12, 2015

Thanks. I'll put this on Steering Group's next agenda, likely we'll have a call in ~ 2 weeks.

@twamarc
Contributor
twamarc commented Jun 12, 2015

Great!
Let me know (some day before)if I have to invite available participants from https://www.w3.org/community/schemed/ so I can set up a TCon bridge.

@danbri
Contributor
danbri commented Sep 15, 2015

@twamarc - could you add links to the latest discussions, drafts, meeting notes etc into this issue? I'd like #492 to be a general "one stop shop" for schema.org community members to check into the status of this work.

@twamarc
Contributor
twamarc commented Sep 15, 2015

Sure, I will populate all related discussions from other issues

@danbri
Contributor
danbri commented Sep 15, 2015

Thanks, that would be really useful!

@twamarc
Contributor
twamarc commented Sep 16, 2015

Current ongoing work:
-(Step one-)The minimum requirement for first version of health.schema.org extension (#11), based upon those terms identified in the current core of schema.org as candidates for moving into a health extension:
*see @RichardWallis: twamarc/ScheMed#11 (comment)
*see @danbri : twamarc/ScheMed#11 (comment)
also in line with last ScheMed CG meeting discussions:
*Quoting @rvguha experience (http://www.w3.org/2015/08/28-schemed-minutes.html)

-(Step one-bis)Working on the partial notes about the exact choice of name for each term inhealth.schema.org extension @danbri in #2
*see: twamarc/ScheMed#2 (comment); from what a couple of issues have been opened :
#twamarc/ScheMed#20 |Terms/words choice or re-use in health extension: action, activityDuration, etc
#twamarc/ScheMed#19 |Terms/words choice: re-work on too broad or vague terms like Vessel, Appearance, Balance, CT, Completed, Emergency, etc.
#twamarc/ScheMed#18 |Removing the medical sense of 'action' (deprecate).
#twamarc/ScheMed#17 |Recipe and existing Recipe vocab to stay in core?
#twamarc/ScheMed#16 |Move from core to extension: MedicalAudience
#twamarc/ScheMed#15 |Move from core to extension: Diet, DietarySupplement
#twamarc/ScheMed#14 |Move from core to extension: consider if we move Place / LocalBusiness -related types

-(Step two-): Additions, enhancement, wide community review including:
--Under investigation: support nutrition vocab and see convergence with GS1:
see also
#twamarc/ScheMed#13 |Optimizing health extension for nutrition vocabs Enhancement (cc/ @mgh128)

--Under investigation: support clinical trials data/vocab (cc/ @micheldumontier)
see also
#twamarc/ScheMed#12 |Optimizing health extension for clinical trials data/vocab Enhancement

--Under investigation: support for genetics and pharmacogenetics vocab (@markwoon)
see also
#twamarc/ScheMed#6 | Support for genetics and pharmacogenetics

--Under investigation: support for Health Insurance markup #twamarc/ScheMed#3 (cc/ @ccorak, @DavidXPortnoy)

That's for now.
~Marc

@twamarc
Contributor
twamarc commented Sep 16, 2015

Added:
-ScheMed CG wiki page: https://www.w3.org/community/schemed/wiki/Main_Page
-Meetings:
*Last meeting minutes: http://www.w3.org/2015/08/28-schemed-minutes.html
*Coming meeting 25 September (4.00pm UK Time(11.00am Boston Time | 3.00pm GMT):)

@twamarc
Contributor
twamarc commented Sep 19, 2015

@RichardWallis
I have just committed the extraction of all medical vocabs from the schema core to health extension v0.2. I left in core some vocabs to be discussed (nutrition, Recipe and physicalActivity | Fitness) this will be discussed in coming SchemED CG meetings.

I merged with sdo-phobos, and passed all tests successfully. However it seems there I miss something: the test are OK and I see that some orphan domain|range terms are not detected by the tests.

eg. See the http://schema.org/indication :

here: the 3 listed domains are not defined in core neither in the extension (accidentally there as a legacy of v0.1 health.schema.org):

health:MedicalIntervention
health:CaringEvent
health:MedicalIndication

So I was expecting the tests to detect them and I can correct this immediately. Unfortunately not.
Of course I can do that manually-- time consuming.

Can you pass the stets at your side?
https://github.com/twamarc/schemaorg/blob/master/data/ext/health/health_core-0.2.rdfa
https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa

Following our disussions I guess this will be published under
http://health.sdo-schemedex.appspot.com/MedicalEntity
Then we will work deeply on this first draft of this extract proposal through those individual terms identifying issues and comments, to get it ready for proposal.
Am still working on them, examples and rationale text.
Thanks,

~Marc

@RichardWallis
Contributor

@twamarc I get the following failures when I run the tests:

FAIL: test_validDomainIncludes (test_graphs.SDOGraphSetupTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/wallisr/Development/schemaorg/health 0.2/schemaorg/tests/test_graphs.py", line 164, in test_validDomainIncludes
    self.assertEqual(len(nri1_results), 0, "DomainIncludes should define valid type. Found: %s" % len(nri1_results))
AssertionError: DomainIncludes should define valid type. Found: 11

======================================================================
FAIL: test_validRangeIncludes (test_graphs.SDOGraphSetupTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/wallisr/Development/schemaorg/health 0.2/schemaorg/tests/test_graphs.py", line 148, in test_validRangeIncludes
    self.assertEqual(len(nri1_results), 0, "RangeIncludes should define valid type. Found: %s" % len(nri1_results))
AssertionError: RangeIncludes should define valid type. Found: 4

Scrolling back up the test output you will see informational reports for the 11 offending domainIncludes and 4 rangeIncludes.

@twamarc
Contributor
twamarc commented Sep 22, 2015

@RichardWallis
I still failed to run the following tests : tests/test_basics.py AND tests_graphs.py
I have thefollowing returned error:

$ python tests/test_basics.py
Traceback (most recent call last):
File "tests/test_basics.py", line 8, in
from sdoapp import *
File "d:\Users\axpzc\schemaorg\sdoapp.py", line 6, in
import webapp2
ImportError: No module named webapp2

The tests under scripts/run_tests.py are OK at my side:
Ran 61 tests in 15.268s
OK (skipped=1)

So I tried to fix the domainIncludes and rangeIncludes issues manually (not sure I fixed them all): can you run the tests at your side again?

Thanks

@RichardWallis
Contributor

@twamarc check for the following in your environment: PYTHONPATH=/usr/local/google_appengine
That should fix your problem. Yell if not.

Meanwhile here are the error reports I'm getting:

test_validDomainIncludes (test_graphs.SDOGraphSetupTestCase) ... INFO:test_graphs:Property http://schema.org/biomechnicalClass invalid domainIncludes value: http://schema.org/Joint

INFO:test_graphs:Property http://schema.org/frequency invalid domainIncludes value: http://schema.org/DoseSchedule

INFO:test_graphs:Property http://schema.org/hospitalAffiliation invalid domainIncludes value: http://schema.org/Physician

INFO:test_graphs:Property http://schema.org/proprietaryName invalid domainIncludes value: http://schema.org/Diet

INFO:test_graphs:Property http://schema.org/purpose invalid domainIncludes value: http://schema.org/MedicalDevice

INFO:test_graphs:Property http://schema.org/sourcedFrom invalid domainIncludes value: http://schema.org/Nerve

INFO:test_graphs:Property http://schema.org/tissueSample invalid domainIncludes value: http://schema.org/PathologyTest

INFO:test_graphs:Property http://schema.org/totalTime invalid domainIncludes value: http://schema.org/MedicalProcedure

FAIL
test_validRangeIncludes (test_graphs.SDOGraphSetupTestCase) ... INFO:test_graphs:Property http://schema.org/hospitalAffiliation invalid rangeIncludes value: http://schema.org/Hospital

INFO:test_graphs:Property http://schema.org/purpose invalid rangeIncludes value: http://schema.org/MedicalDevicePurpose

INFO:test_graphs:Property http://schema.org/sourcedFrom invalid rangeIncludes value: http://schema.org/BrainStructure

FAIL
@twamarc
Contributor
twamarc commented Sep 22, 2015

@RichardWallis Thanks. Not solved at my side (I guess windows config problem?).
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa__init__.py", line 580, in graph_from_source
if not rdfOutput : raise f
rdflib.plugins.parsers.pyRdfa.FailedSource
ERROR

However I fixed the above errors--still manually. Can you test again? :)

@RichardWallis
Contributor

@twamarc I don't get any errors this time but there is a weird problem.

There are domain references to MedicalClinic & Hospital yet there are no
definitions for them :-(

I would have thought that the test would have picked that up but it doesn't.

One of the errors last time I think was for Hospital - what did you do to
fix that?

~Richard.

On Tue, Sep 22, 2015 at 3:23 PM, Marc notifications@github.com wrote:

@RichardWallis https://github.com/RichardWallis Thanks. Not solved at
my side (I guess windows config problem?).
Traceback (most recent call last):
File
"C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa__init__.py",
line 580, in graph_from_source
if not rdfOutput : raise f
rdflib.plugins.parsers.pyRdfa.FailedSource
ERROR

However I fixed the above errors--still manually. Can you test again? :)


Reply to this email directly or view it on GitHub
#492 (comment)
.

@twamarc
Contributor
twamarc commented Sep 22, 2015

This was about 'hospitalAffiliation' property:

<div typeof="rdf:Property" resource="http://schema.org/hospitalAffiliation">
<span class="h" property="rdfs:label">hospitalAffiliation</span>
<span property="rdfs:comment">A hospital with which the physician or office is affiliated.</span>
<span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Physician">Physician</a></span>
<span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Hospital">Hospital</a></span>
</div>

changed to:

<div typeof="rdf:Property" resource="http://schema.org/hospitalAffiliation">
<span class="h" property="rdfs:label">health:hospitalAffiliation</span>
<span property="rdfs:comment">A hospital with which the physician or office is affiliated.</span>
<span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Physician">health:Physician</a></span>
<span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Hospital">health:Hospital</a></span>
<link property="http://schema.org/isPartOf" href="http://health.schema.org" />
</div>

There hospital & Physician was missing the extension prefix 'health:'. I added it.
Additionnally they were still in core schema.rdfa (so there was no 'isPartOf' I addeed it)

It was the same for 'Hospital', as well as 'purpose'.

Let me fix this 'MedicalClinic & Hospital ' manually, and commit.

@twamarc
Contributor
twamarc commented Sep 22, 2015

Done! and other tests are OK except the 'test_graphs'

Traceback (most recent call last):
File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa\__init__.py", line 580, in graph_from_source
if not rdfOutput : raise f
rdflib.plugins.parsers.pyRdfa.FailedSource
ERROR

I see for this test config failing that I have a warning 'Note: unable to import appengine_config.':

    D:\Users\axpzc\schemaorg>python scripts/run_tests.py
    C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine
    Note: unable to import appengine_config.
    INFO:api:(re)loading core and annotations.
    INFO:api:(re)scanning for extensions.
    INFO:api:Extensions found: data/ext/auto\auto.rdfa , data/ext/bib\bsdo-1.0.rdfa , data/ext/bib\comics.rdfa , data/ext/health\health_core-0.2.rdfa .
    INFO:api:Preparing to parse extension data: D:\Users\axpzc\schemaorg\data/ext/auto\auto.rdfa as 'auto\auto.rdfa'
    INFO:api:Preparing to parse extension data: D:\Users\axpzc\schemaorg\data/ext/bib\bsdo-1.0.rdfa as 'bib\bsdo-1.0.rdfa'
    INFO:api:Preparing to parse extension data: D:\Users\axpzc\schemaorg\data/ext/bib\comics.rdfa as 'bib\comics.rdfa'
    INFO:api:Preparing to parse extension data: D:\Users\axpzc\schemaorg\data/ext/health\health_core-0.2.rdfa as 'health\health_core-0.2.rdfa'
    test_sameas_jsonld (test_basics.AdvancedJSONLDTests) ... ok
    test_alltypes (test_basics.BallparkCountTests) ... ok
    etc.../~/

& later on, at the end of tests:

INFO:test_graphs:Graph tests require rdflib.
INFO:test_graphs:Trying to import rdflib...
INFO:rdflib:RDFLib Version: 4.2.1
INFO:api:(re)loading core and annotations.
INFO:test_graphs:SDOGraphSetupTestCase reading schemas using built-in parsers.
INFO:test_graphs:Attempting to parse data/*rdfa with rdflib.
INFO:test_graphs:Found 1 files via data/*rdfa.
INFO:test_graphs:Files to parse: data\schema.rdfa
INFO:test_graphs:Parsing URL data\schema.rdfa with rdflib RDFa parser.
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa\__init__.py", line 580, in graph_from_source
    if not rdfOutput : raise f
rdflib.plugins.parsers.pyRdfa.FailedSource
ERROR

======================================================================
ERROR: setUpClass (test_graphs.SDOGraphSetupTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Users\axpzc\schemaorg\tests\test_graphs.py", line 64, in setUpClass
    SDOGraphSetupTestCase.parseRDFaFilesWithRDFLib()
  File "D:\Users\axpzc\schemaorg\tests\test_graphs.py", line 45, in parseRDFaFilesWithRDFLib
    self.rdflib_data.parse(f, format='rdfa', pgraph=self.rdflib_errors)
  File "C:\Python27\lib\site-packages\rdflib\graph.py", line 1037, in parse
    parser.parse(source, self, **args)
  File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\structureddata.py", line 145, in parse
    check_lite=check_lite
  File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\structureddata.py", line 176, in _process
    processor.graph_from_source(orig_source, graph=graph, pgraph=processor_graph, rdfOutput=False)
  File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa\__init__.py", line 662, in graph_from_source
    if not rdfOutput : raise b
FailedSource

Ran 61 tests in 18.762s

FAILED (errors=1)

I will continue to investigate this.
Can you re-test?

Thanks for your help.
~Marc

@RichardWallis
Contributor

@twamarc Tests pass here and the Hospital type now is visible.

~Richard.

On Tue, Sep 22, 2015 at 8:35 PM, Marc notifications@github.com wrote:

Done! and other tests are OK except the

Traceback (most recent call last):
File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa__init__.py", line 580, in graph_from_source
if not rdfOutput : raise f
rdflib.plugins.parsers.pyRdfa.FailedSource
ERROR

I see for this test config failing that I have a warning:
D:\Users\axpzc\schemaorg>python scripts/run_tests.py
C:\Program Files\Google\Cloud
SDK\google-cloud-sdk\platform\google_appengine
Note: unable to import appengine_config.
INFO:api:(re)loading core and annotations.
INFO:api:(re)scanning for extensions.
INFO:api:Extensions found: data/ext/auto\auto.rdfa ,
data/ext/bib\bsdo-1.0.rdfa , data/ext/bib\comics.rdfa ,
data/ext/health\health_core-0.2.rdfa .
INFO:api:Preparing to parse extension data:
D:\Users\axpzc\schemaorg\data/ext/auto\auto.rdfa as 'auto\auto.rdfa'
INFO:api:Preparing to parse extension data:
D:\Users\axpzc\schemaorg\data/ext/bib\bsdo-1.0.rdfa as 'bib\bsdo-1.0.rdfa'
INFO:api:Preparing to parse extension data:
D:\Users\axpzc\schemaorg\data/ext/bib\comics.rdfa as 'bib\comics.rdfa'
INFO:api:Preparing to parse extension data:
D:\Users\axpzc\schemaorg\data/ext/health\health_core-0.2.rdfa as
'health\health_core-0.2.rdfa'
test_sameas_jsonld (test_basics.AdvancedJSONLDTests) ... ok
test_alltypes (test_basics.BallparkCountTests) ... ok
etc...

Can you re-test?

Thanks for your help.
~Marc


Reply to this email directly or view it on GitHub
#492 (comment)
.

@twamarc
Contributor
twamarc commented Sep 23, 2015

Great!
Once this stable version is visible under http://health.sdo-schemedex.appspot.com/MedicalEntity we can use it for our coming meeting (Friday).

Thanks
~Marc

@RichardWallis
Contributor

@twamarc This version is now is available to view at: http://health.sdo-schemedex.appspot.com

/cc @danbri

@twamarc
Contributor
twamarc commented Sep 25, 2015

Meeting notes from Sept 25, 2015 : http://www.w3.org/2015/09/25-schemed-minutes.html

@twamarc
Contributor
twamarc commented Nov 6, 2015

The November 6th, 2015 meeting minutes: http://www.w3.org/2015/11/06-schemed-minutes.html

@twamarc
Contributor
twamarc commented Nov 13, 2015

cc// @danbri @RichardWallis
All fixes from last meeting now done:
Now in line with schema.org v2.2 as well.
https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa
https://github.com/twamarc/schemaorg/blob/master/data/ext/health/health_core-0.3.rdfa
Tests are OK thanks @RichardWallis for helping on this.
Happy to see that the whole history of commits are also tracked in the original pull request #11

Next step:
*Still collecting feedback on what terms may be better left in the core.
*Any fixing and continue tracking reported issues

This should be ready for ship'in (next schema.org release?)
Overview of current version: http://health.sdo-schemedex.appspot.com

~ Marc

@mfhepp
Contributor
mfhepp commented Nov 16, 2015

Dear Marc:

Thanks for your hard work! Just from a very quick look:

  1. The following properties have pretty generic names. There is a risk that we define them in the narrow sense of the medical / health domain. I would recommend to rename them so that it becomes clear that they are meant in the specific sense of this domain:

action,
algorithm
aspect
availableIn
availableService
branch
cause, causeOf
code, codeValue, codingSystem
comprisedOf, connectedTo
cost, costCategory, costCurrency, costOrigin, costPerUnit - also, how does this relate to PriceSpecification
diagram
frequency
function
manufacturer
origin, originatesFrom,
overview
partOfSystem
runsTo
source, sourcedFrom
purpose
status
usesDevice, warning

Also, the type Vessel could mean very different things in different contexts (e.g. boats in the vehicles branch)

  1. How do doseUnit, doseValue, maximumIntake, recommendedIntake, strengthUnit, strengthValue, totalTime relate to QuantitativeValue?

In the case of http://health.sdo-schemedex.appspot.com/doseValue, QualitativeValue seems wrong as a possible range. Rather combine doseValue and doseUnit into one "dose" property with a range of QuantitativeValue.

  1. How does publicationType relate to the bib extension? Can't we simply use schema:category?
  2. http://health.sdo-schemedex.appspot.com/MedicalEnumeration is an abstract intermediate type whose main purpose seems to bundle medical-related value sets. We tend to avoid such types in the vocabulary.

In general, I have concerns about the degree of alignment with the schema.org meta-model.

Martin


martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 13 Nov 2015, at 13:17, Marc notifications@github.com wrote:

cc// @danbri @RichardWallis
All fixes from last meeting now done:
Now in line with schema.org v2.2 as well.
https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa
https://github.com/twamarc/schemaorg/blob/master/data/ext/health/health_core-0.3.rdfa
Tests are OK thanks @RichardWallis for helping on this.
Happy to see that the whole history of commits are also tracked in the original pull request #11

Next step:
*Still collecting feedback on what terms may be better left in the core.
*Any fixing and continue tracking reported issues

This should be ready for ship'in (next schema.org release?)
Overview of current version: http://health.sdo-schemedex.appspot.com

~ Marc


Reply to this email directly or view it on GitHub.

@twamarc
Contributor
twamarc commented Nov 16, 2015

@mfhepp
Hi Martin,
Thanks a lot for this valuable screening ( well just a quick look but it's a high contribution). Such external and unbiased views on the terms are important.

I will translate the point 1) into separate issues so we can discuss this deeply in the CG. +See some comments also below in point 3.

For point 2) I fully agree with you.
I will fix the range of http://health.sdo-schemedex.appspot.com/doseValue to http://schema.org/Number

For point 3) it depends on use cases and expression models. I agree that type of the medical article is not different from type of any other publication.
Either we specialize it to medicalPublicationType either we extend its definition.

This is a tricky and recurring question for terms which were previously weak-ly defined in schema.org (actually most of listed terms above in point 1 are in this category).
The dilemma here is:
a)do we create another well defined term to supercede this one and we deprecate the one which will be left in core? (I was for this approach). The problem here is the principle of this first step of the work was only to extract medical related terms from core and try to disambiguate some terms with strictly minimum editions/additions. Ultimately no NEW terms. (@danbri @RichardWallis @rvguha )

b)do we take them from core and extend the definition? (I was against that, as a term like Vessel will still be seen as vague for SEO/webmasters guys).

So we do have now 2 options: either to leave *publicationType * in core and deprecate (and use 'category' where needed) it either to import it to extension and extend its definition.
What do you think about this?

For point 4) again this is a term which was last year highly discussed, but it seems to me it's important to bundle medical-related value sets. If the trend is to avoid such types in the vocabulary, What would be the alternate approach?

Finally for the concern about alignment with the schema.org meta-model, I think we worked hard for this and now this is in line with 2.2. Test were OK as well, but we keep collect all bugs which could be identified.

Thanks
Marc

@RichardWallis
Contributor

As well as the properties that Marin mentioned there are several types that
should probably remain as part of the core vocabulary, including:

  • Dentist
  • Diet
  • Hospital
  • Midwifery
  • Muscle
  • Nursing
  • OcupationalTherapy
  • Optician
  • Pharmacy
  • Physiotherapy
  • Physician
  • Patient
  • PublicHealth
  • Substance
  • VeterinaryCare

Potentially it could be argued that MedicalBusiness should also remain in
the core as a foundation for all general medically associated businesses.

That is not to say that the could not be then extended within the health
extension. For instance Pharmacy could be a subtype of LocalBusiness in
the core, yet be in the domain of medicalSpecialty as defined in the health
extension.

~Richard.

On Mon, Nov 16, 2015 at 8:56 AM, Marc notifications@github.com wrote:

@mfhepp https://github.com/mfhepp
Hi Martin,
Thanks a lot for this valuable screening ( well just a quick look but
it's a high contribution). Such external and unbiased views on the terms
are important.

I will translate the point 1) into separate issues so we can discuss this
deeply in the CG. +See some comments also below in point 3.

For point 2) I fully agree with you.
I will fix the range of http://health.sdo-schemedex.appspot.com/doseValue
to http://schema.org/Number

For point 3) it depends on use cases and expression models. I agree that type
of the medical article
is not different from type of any other
publication.
Either we specialize it to medicalPublicationType either we extend its
definition.

This is a tricky and recurring question for terms which were previously
weak-ly defined in schema.org (actually most of listed terms above in
point 1 are in this category).
The dilemma here is:
a)do we create another well defined term to supercede this one and we
deprecate the one which will be left in core? (I was for this approach).
The problem here is the principle of this first step of the work was only
to extract medical related terms from core and try to disambiguate some
terms with strictly minimum editions/additions. Ultimately no NEW
terms. (@danbri https://github.com/danbri @RichardWallis
https://github.com/RichardWallis @rvguha https://github.com/rvguha )

b)do we take them from core and extend the definition? (I was against
that, as a term like Vessel will still be seen as vague for
SEO/webmasters guys).

So we do have now 2 options: either to leave *publicationType * in core
and deprecate (and use 'category' where needed) it either to import it to
extension and extend its definition.
What do you think about this?

For point 4) again this is a term which was last year highly discussed,
but it seems to me it's important to bundle medical-related value sets. If
the trend is to avoid such types in the vocabulary, What would be the
alternate approach?

Finally for the concern about alignment with the schema.org meta-model, I
think we worked hard for this and now this is in line with 2.2. Test were
OK as well, but we keep collect all bugs which could be identified.

Thanks
Marc


Reply to this email directly or view it on GitHub
#492 (comment)
.

@twamarc
Contributor
twamarc commented Nov 18, 2015

@RichardWallis
Thanks I will add this on the list to discussed. A quick view on this list--- it would be hard to convince why terms like Patient, Physician, Nursing, Muscle, Dentist etc which are purerly medical/health related and specific enough; why they are not in extension.
The previous listed were most too vague too general but those ones... are real specific.
Any motivation behind? what rationale?

@davefeg
davefeg commented Nov 21, 2015

@RichardWallis I screened the list and IMHO I think ALL those terms should be and remain in health.schema.org extension. Theyare clear and specialized enough in difference with the previous ones submitted by @mfhepp

@jamrob
jamrob commented Nov 21, 2015

@davefeg @RichardWallis @mfhepp
I am somehow sad about this!
This work was already done and has been rejected. See:http://health.sdo-schemedex-0-1.appspot.com/MedicalEntity and my comments on twamarc/ScheMed#11.

@twamarc: this current approach of re-doing the work already done, without any reason of rejecting the previous efforts of all of us was the reason for me and many of other members to leave the initiative.

Quoting:
twamarc/ScheMed#36
twamarc/ScheMed#37

BTW reading the current proposal and comments of @davefeg I fully support his suggestion.
In previous rejected submission we were taking into account leaving vague/ambiguous terms in core (and deprecate them) and creating renamed one in the extension.

@twamarc
Contributor
twamarc commented Nov 28, 2015

Hey guys, we never said the task will be easy... :)
However am happy that despite such challenges we are moving forward. Please keep discussing on the specific issues opened in schemed rather than here.
~Marc

@davefeg
davefeg commented Dec 9, 2015

Hi Marc,
Thanks for invitation.
As I told you I will not be able to participate in coming Dec 11th, TCon as well, sorry.
However I have a main concern about the approach of TCon, and I would like to suggest something.
It's very hard for some of us to contribute to the code review/model review based on GitHub.
It would help to use TCons to discuss general and driving ideas and keep the code/model review/discussion on GitHub comments/discussions.
On this basis everyone can feel comfortable to suggest/comment or push his/her expectations and contribute (if he/she can) to the GIt Hub codes.
We are not at the same level to discuss codings and we are sure we have suitable people in the ScheMed Community Group to translate our discussions (with concensus) into codes with a strong help from schema.org team.
May I suggest to change the coming agenda by replacing all points with a single point: Collect what each members/participants expect from the ScheMed Community Group/health.schema.org?
This point is enough and and then we will discuss code review through github channel.

My last suggestion is to have the current version of health.schema.org proposal at least published officially by schema.org (and keep improvment coming). Remember that the current proposal includes only the already existing vocab in schema.org before our Community group work.
So publishing it would not have any problem (is already published in core with its known weaknesses).
Sorry if am too direct but I had to, for sake of our community group progress.
Wishing you all guys fruitful discussions.

Dave.

@twamarc
Contributor
twamarc commented Dec 10, 2015

Hi Dave,
Thanks for your comments. Well I agree that focusing our TCons on general and driving ideas and keep the code/model review/discussion on GitHub comments/discussions may allow some of participants to contribute more, but this has to be first raised somewhere as discussion point. There are several way to raise a topic here:
1-The first one is to raise it as an issue on GitHub(recommended).

https://github.com/twamarc/ScheMed/issues

2-The second is directly to make and submit editions on dedicated page of the community group wiki:

https://www.w3.org/community/schemed/wiki/Domestic_standards_of_procedures
https://www.w3.org/community/schemed/wiki/Commitments_and_requirements

3-The last one is to raise the topic on community group mailing list public-schemed@w3.org or at schema.org maili list. public-vocabs@w3.org

Remember that the ScheMed CG is an interest & Business group. So we share the common interests and the main one from the beginning is to improve and maintain the health.schema.org extension.
This doesn't prevent to have additional points on the agenda based on participants requests.
So feel free to send in your expectations/suggestions.
Here we will avoid to create yet another group overlapping with existing groups but that can be discussed.
About the coming agenda, yes I will add the topic at the beginning of the meeting.

Marc.

@twamarc
Contributor
twamarc commented Dec 11, 2015

Healthcare Schema Vocabulary CG Meeting, 11th December 2015
See not cleaned (sorry) minutes here: http://www.w3.org/2015/12/11-schemed-minutes.html

Main decisions:
-To appoint a co-chair (if possible 2) Open invitation for volunteering.

  • Agreement on the suggestions received of keeping the TCons for general driving ideas and unsolved issues on Github, or on-demand points. Not detailed codes review or model discussions.
    -To ask schema.org if the current version of health.schema.org extension can be shipped for next release (with provision to keep receiving feedback).

Thanks.
Marc

@twamarc
Contributor
twamarc commented Feb 17, 2016

Hi everyone,
No much changes since our last Webex TCon last year, but I would like to make a small update and a follow up. Currently (since 2016), efforts are being done to build up an implementers community of the extension. So far we are in connections with:
*The metadata working group of BioCADDIE (https://biocaddie.org/group/working-group/working-group-3-descriptive-metadata-datasets),
*The EUROREC Institute (EuroRec) which is alredy using couple of our concepts but not yet in public domain

Meanwhile I would like to remind and follow up decisions taken since last year:
The suggestion was to ask schema.org if they can publish the current version of the extension and the CG continue to follow up the improvement (eg. the big discussion about twamarc/ScheMed#36, other issues, extensions, etc.).
Is that a viable way forward @danbri , @RichardWallis ?

~Thanks, Marc

@danbri
Contributor
danbri commented Feb 26, 2016

@twamarc - thanks for the updates. Can you point us at the "current version of the extension"? (pull request and maybe test build of site?)

@twamarc
Contributor
twamarc commented Feb 29, 2016

@danbri - Thanks for the feedback.
The current version of the extension:
*tests from my side (python scripts/run_tests.py) are OK. previously re-checked by @RichardWallis as well.

@twamarc
Contributor
twamarc commented Mar 26, 2016

@ALL:
This issue will centralize (or at least reference) all threads related to the hosted extension, from:

  1. #11
  2. https://www.w3.org/community/schemed/
  3. https://github.com/twamarc/ScheMed/issues
    and more relevant others.
    So if you make a comment elswhere, please remember to quote the root issue #492

Thanks in advance!
~Marc

@danbri
Contributor
danbri commented Mar 26, 2016

Thanks @twamarc . Earlier I suggested that these questions would be good to have clear answers for. Can you help with that?

  • The list of terms that are moved (todo: list).
  • The list of terms that are renamed (todo: list) with the core.
  • The list of terms that are renamed (todo: list) and moved into the extension.
  • The list of terms that are created (todo: list) within the core.
  • The list of terms that are created (todo: list) within the extension.
  • The list of terms that are somewhat medically-related terms but remain in the core (todo: list, e.g. http://schema.org/Recipe).
@twamarc
Contributor
twamarc commented Mar 26, 2016

Sure!
I think I did this already I have to find the document. The last version was this one.
overview_vocab_v0.2.docx

@ppKrauss

About http://schema.org/MedicalScholarlyArticle, it is in scope of this review?

I think the best semantic reference, and best clues about relevant classes/properties, are in the JATS standard, that have its origins in the PubMed Central works with millions of articles of "medical scholarly publication" (def. of MedicalScholarlyArticle).

Exemples of same good choices:

Example of needs (in the current schema)

@twamarc
Contributor
twamarc commented Mar 28, 2016

In indexing PubMed central articles, we need a small piece example. @ppKrauss can you suggest a complete example and needed properties? It would be helpful to initiate discussions.
Please note that bib.schema.org extension has more usefull properties we do not need to repeat here.

@westurner
Contributor

Lobbing notes over from https://westurner.org/opengov/us/index#objectives :

Which groups were masked? (single, double, triple is not sufficient)

From the health-lifesci RDFa https://github.com/schemaorg/schemaorg/blob/sdo-deimos/data/ext/health-lifesci/health_core-0.3.rdfa , I see the (new) MedicalTrialDesign subtypes:

.

  • Where can I specify MedicalTrial group URIs (in order to link data)?
    • ... With CSVW, there could/should/would be URIs that link the groups to datasets/columns (for ~"TripleBlind" statistical analysis)
@twamarc
Contributor
twamarc commented Apr 2, 2016

Interesting point raised here @westurner. Thanks.
It's not only ´´ MedicalTrialGroup´´ term missing here, there are others we might add to be complete. So I agree to extend the clinical trial vocab BUT what use-case will we refers to? ClinicalTrial.gov? any commitment/plan to consume the vocab? another site or API? we need concrete use targeted here.

@ppKrauss
ppKrauss commented Apr 2, 2016

Hi @twamarc, thanks reply (!), let's see if I understand your request.

All my JATS-tag links have samples. Eg. affiliation (aff tag) have 5 examples...

The aff-example-2 shows adequate separation from of institution,

    <aff>Klinik für Strahlentherapie und Radiologische Onkologie, 
          <institution>Technische Universität München</institution>, 
           Munich, Germany ... 
    </aff>

(or imagine ritcher with eg. <city> and <country> tags)
so, mapping the markups (from JATS to SchemaOrg's Microdata) we have something as

<div itemscope="itemscope" itemtype="http://schema.org/ArticleFrontAff">
        Klinik für Strahlentherapie und Radiologische Onkologie, 
        <span itemscope="itemscope" itemtype="http://schema.org/Organization">
             Technische Universität München
        </span>
        <span itemprop="http://schema.org/addressLocality">Munich</span>, 
        <span itemprop="http://schema.org/addressCountry">Germany</span> ...
</div>

... showing the need for ArticleFrontAff, an SchemaOrg's Affiliation class complementing MedicalScholarlyArticle scope.


Another eg. abstract (abstract tag)... Perhaps we can to adapt the generic SchemaOrg/description, but I recommend, for a MedicalScholarlyArticle context, to use something more specific, so, to create SchemaOrg's abstract or articleFrontAbstract or articleAbstract...


Well... with these examples/explanations you see the problem of the request:

  1. Maybe we can satisfied with the JATS's links.
  2. There are a hundred other examples, of needs (!), we perhaps not have time to show and discuss all here... We need focus (at this moment what the main SchemaOrg needs? What the curation mechanism?)... And a simple box of issue here, haven't enough space (perhaps we can use the Wiki).
  3. Each example need to be splitted into details, as above... So, need perhaps some standard example template to produce faster, and focusing on goals.

Another approach is to take advantage of the PeerJ's good work (in the mapping from JATS to SchemaOrg's Microdata) and discuss/prepare there.

@twamarc
Contributor
twamarc commented Apr 2, 2016

Thanks @ppKrauss .. I see:
But here it depends on how you want to model your article data.
why not using for instance the author links?
(am just thinking loud, I do not say you should mandatory use this):

<article>
  <http://schema.org/author> 
             <schema.org/Person>
                                    <http://schema.org/affiliation> <Aff>
</article>

Think something like (of course it's just a textual illustration example , syntax is not correct!!!):

<div itemscope itemtype="http://schema.org/ScholarlyArticle">
  <strong>Title:</strong> <span itemprop="name">Be Careful What You Wish For: FRBR, Some Lacunae, A Review</span><br />
  <strong>Author:</strong> <span itemprop="author">Smiraglia, Richard P.</span><br />
</div>

<div itemscope itemtype="http://schema.org/author">
        <span itemscope="itemscope" itemtype="http://schema.org/affiliation">
        Klinik für Strahlentherapie und Radiologische Onkologie, 
        <span itemscope="itemscope" itemtype="http://schema.org/Organization">
             Technische Universität München
        </span>
        <span itemprop="http://schema.org/addressLocality">Munich</span>, 
        <span itemprop="http://schema.org/addressCountry">Germany</span> ...
</div>

You may find extra info under:
*https://schema.org/CreativeWork
*work done in the "W3C Schema Bib Extend (BibEx) group" to improve schema.org for bibliographic information, including terms for periodicals, articles and multi-volume works. The design was inspired in places (e.g. pageStart, pageEnd, pagination) by the Bibliographic Ontology, 'bibo'.

@scarini
scarini commented Apr 4, 2016

Hello. This is the first time I look at the details of the extension so apologies if any of my comments have been previously addressed. I focused on a couple of areas I am more familiar with and have the following questions/comments.

The Human Studies Database Project has published a Study Design ontology you may want to look at:
http://hsdbwiki.org/index.php/Study_design_typology
and also the Ontology of Clinical Research:
http://bioportal.bioontology.org/ontologies/OCRE

  1. This enumerated type (where I assume the name means Interventional study design as opposed to Observational):
    http://schema.org/MedicalTrialDesign
    places several elements of a study design on the same level.
  2. I assume the list of study status terms comes from the terminology used by ClinicalTrials.gov:
    http://health-lifesci.webschemas.org/MedicalStudyStatus

Is there a reference to the source that I missed?
Again here, different elements are put together:

ActiveNotRecruiting
Completed
EnrollingByInvitation
NotYetRecruiting
Recruiting
ResultsAvailable
ResultsNotAvailable
Suspended
Terminated
Withdrawn 

and definitions are missing, so for example, it is not clear what "Withdrawn" means.

  1. In the medical specialty list
    http://health-lifesci.webschemas.org/MedicalSpecialty
    I see a mix of adjectives and names, sometimes both, as in
    Dermatologic
    Dermatology

and typos, as in
Radiography
Radiograpy

Please, let me know if anything I wrote is not clear.
I can be reached at simona.carini@ucsf.edu
Regards.

@Dataliberate
Contributor

These are all valuable inputs into the discussion about the evolution of medical terms in an extension to the core Schema.org vocabulary.

We must remember however that the moving of medical terms from the core into an extension was considered to be enough of a significant step to be the first in a series of steps in this area.

Lets get what we have nailed down (thanks for spotting the Radiograpy typo) in an early release. Then we can review what we have to improve and enhance it in a later step(s).

@twamarc
Contributor
twamarc commented Apr 5, 2016

+1 @RichardWallis !

Thanks @scarini for this review regarding clinical study terminology.
I think there will be room for improvement in coming steps (after this baseline vocab is online).

Just looking at the http://hsdbwiki.org/index.php/Study_design_typology (The Human Studies Database Project), I notice that it's quite simplified but it will be hard to make a concensus in public health/clinical pharmacologist community with it.

In this vocab we need to find a common interests for most of web indexing/SEO/data sharing communities. The intention is not to replace existing ontologies like
http://bioportal.bioontology.org/ontologies/OCRE or others. Definitely there will be no single medical/health/lifescience ontology. This doesn't exclude to optimize this vocab for one of other use cases, like clinical trials here, but also others.
Where needed we can align/map the terms of course as this is done for other medical terminologies.

On top of that, we need real use-cases where the terms are used in real-life so we can fine tune them according the need and see if it's a general shared term or a specific one. Do we have some exemples of APIs/Web services where the Human Studies Database Project ontology is deployed you can share? Or some other examples?

Finally I share with you the observation of a mix of adjectives and names, sometimes both: this need to be worked on in next steps, but again based on users's requests.
Regarding the Withdrawn meaning, it's just to mark a study which has been introduced but withdrawn for any reason.
I will create an issue (to initiate discussions) to extend the definition.

Marc

@westurner westurner referenced this issue in FDA/openfda Apr 8, 2016
Open

Open, and Linked, FDA data #5

@danbri danbri pushed a commit that referenced this issue Apr 11, 2016
Dan Brickley the sponsor property definition in core shouldn't mention MedicalStud…
…y, and extension should add that but not re-label the property.

For #492
9e575ce
@danbri
Contributor
danbri commented Apr 12, 2016

@twamarc et al.,

I am going through the schemed files from a QA perspective. To help with this I wrote a one-off Python script which listed (types, properties, enumerated values) that (a) moved from core to health-lifesci (b) are new additions in health-lifesci. It only found a few types to be new; there are no properties or enumerated values in the extension that we did not already have in the v2.2 core.

Amongst the new type declarations it found http://schema.org/MedicalImaging which after investigating I am pretty sure was intended to be written "MedicalImagingTechnique". I have made that change - please confirm that this makes sense.

The remaining output of the check is at https://gist.githubusercontent.com/danbri/a9baa20c885f6399a835dc25e1e78c0f/raw/079576011ebae4b6a6a35ec09e41f1bbfe03002b/gistfile1.txt

Looking at the other new types,

Type terms in the ext/health-lifesci but not 2.2 core: set(['http://schema.org/VitalSign', 'http://schema.org/Substance', 'http://schema.org/Radiography', 'http://schema.org/SurgicalProcedure', 'http://schema.org/MedicalBusiness', 'http://schema.org/Patient'])

Thanks for any advice on all these!

/cc @scor @mfhepp @tmarshbing @shankarnat @chaals @pmika @vholland @rvguha

@danbri
Contributor
danbri commented Apr 12, 2016

What about PhysicalActivityCategory and PhysicalActivity? the former still seems to be in the core. Intended?

@twamarc
Contributor
twamarc commented Apr 13, 2016

@danbri,
+1
Big job done here!

http://schema.org/MedicalImaging: Yes, this is a bug the intention was MedicalImagingTechnique. Thanks fixing that.

http://schema.org/VitalSign:
The intention here was to move this from enumerated (thus under PhysicalExam) and to attach it to MedicalSign. see twamarc/ScheMed#28

http://schema.org/Substance:
This is a new term proposed and discussed (twamarc/ScheMed#23) to improving Drug concept definition

http://schema.org/Radiography: You're wright! This supersedes old typo name http://schema.org/Radiograpy.

http://schema.org/SurgicalProcedure:
Simillary to VitalSign the intention was here to remove it from enumeration. But we could not know how it may break the existing models we quoted both.

http://schema.org/Patient:
Yes, this is new proposed and discussed term to help in other needed improvements. twamarc/ScheMed#26

http://schema.org/MedicalBusiness:
Yes, this is a new term proposed (twamarc/ScheMed#14#) and discussed (twamarc/ScheMed#14 (comment)) in previous ScheMed discussions. The conculsion was to have a structure that separate the MedicalOrganization and the MedicalBusiness even if whe know that there's sometimes a MedicalOrganization behind (doing) the MedicalBusiness.
The whole discussions was done under issue : twamarc/ScheMed#14 (comment)
Also quoted in https://www.w3.org/2015/11/06-schemed-minutes.html.

PhysicalActivityCategory and PhysicalActivity: The intention was to leave them in the core for now, given couple of dependencies there. But We should work on their improvement soon (it's on my desk-am still looking for a clear use case).

Thanks for your deep review.
~Marc

/cc @scor @mfhepp @tmarshbing @shankarnat @chaals @pmika @vholland @rvguha

@danbri danbri pushed a commit that referenced this issue Apr 20, 2016
Dan Brickley Moved Dentist, Hospital, Pharmacy, Physician back to core.
Also Cross-referenced branch with branchOf to avoid confusion.
For #492 final review.
9fabc43
@danbri danbri pushed a commit that referenced this issue Apr 20, 2016
Dan Brickley Clarified that 'sponsor' is now in core, but we reference MedicalEnti…
…ty only in extension.

For #492.
f3368c6
@danbri danbri pushed a commit that referenced this issue Apr 20, 2016
Dan Brickley * Moved birthPlace, deathPlace, Dentist, Hospital, Pharmacy, Physicia…
…n back to core.

* Cross-referenced branch with branchOf to avoid confusion.
For #492
f3b951d
@danbri danbri pushed a commit that referenced this issue Apr 20, 2016
Dan Brickley Moved VitalSign from PhysicalExam enumeration, into MedicalSign.
Confirmed in #492 but we ought to have an example.
c074d11
@danbri danbri pushed a commit that referenced this issue Apr 20, 2016
Dan Brickley Several edits described in detail in #492 6d41073
@danbri
Contributor
danbri commented Apr 20, 2016

I have been doing some more QA and integration here, see recent commits. This involved moving a few things back into the core (Recipe and local business types, plus birthDate/deathDate are the main ones). More detailed notes follow. We will not perfect these schemas in one pass but I think they are now approaching the stage where we can go ahead with publication. I'll open a new issue for health-lifesci medical vocabulary issue tracking and put some further observations there. Note that there may be other sources of vocabulary for health-lifesci in addition to the efforts of the (hardworking!) schemed CG.

# Notes

  • Property changes
    • Note that these properties have been moved back to core: birthPlace, deathPlace
    • sponsor is now in the core, but the health-lifesci extension adds its MedicalStudy property.
    • action has been explicitly described as an obsolete version of muscleAction; also added a link to potentialAction.
    • totalTime has been removed from MedicalProcedure since its definition is all about cooking; is a new dedicated property needed?
  • Type changes and non-changes:
    • Note that these are back in core (but still MedicalEntity): Dentist, Hospital, MedicalAudience, Pharmacy, Physician, Recipe.
    • Type terms that could be considered borderline between core and health-lifesci, but which are in the latter: Diet, MedicalBusiness, MedicalClinic, MedicalCode, Optician, Patient, Substance, Vessel.
  • Property questions and potential issues
    • What has legalStatus got to do with EventStatusType?
    • In future we should review these sub-property claims, maybe add more: diet subPropertyOf instrument; primaryPrevention subPropertyOf preventiveProcedure; possibleTreatment subPropertyOf treatment; exerciseRelatedDiet subPropertyOf instrument .
  • Types and enumerations
    • Note that VitalSign is now removed from PhysicalExam and modeled as a MedicalSign subtype per #492 confirmation from Marc.
    • DrugCost - in future explore aligning this with Product.
    • Why is a Diet a CreativeWork but not a LifestyleModification?
    • (double definition of) Radiography and its relationship to MedicalImagingTechnique ... why is Radiography a subtype too? There are two definitions to merge, see https://gist.github.com/danbri/9ecc0b02f080389f18adccaa3c6b4fdc ... these have been merged, but unclear if we want subClassOf vs type relating it to MedicalImagingTechnique. Using latter is it is an enumeration. This means the item is in two distinct medical enumerations but isn't considered instantiable.
    • Patient is both a class and an Enumeration.
    • Physician is an office/org - how is the individual represented, if at all?
@danbri
Contributor
danbri commented Apr 20, 2016

Ok, I am done with medical/health edits here.

We still need to clean the entry point homepage at http://health-lifesci.webschemas.org/ but there ought to be no more vocabulary changes now. Do please take a look, @twamarc et al.

@danbri danbri pushed a commit that referenced this issue Apr 20, 2016
Dan Brickley Removed deathPlace copy of definition that is now in core.
For #492
711d74a
@danbri
Contributor
danbri commented Apr 20, 2016

See also #1114 which has a list of terms that need further consideration in a future release, e.g. that give specialized meaning to general phrases, or which might be usefully generalized.

@danbri
Contributor
danbri commented Apr 20, 2016

I've also deferred the proposed 'profession' property for now, details recorded in #1114.

@twamarc
Contributor
twamarc commented Apr 21, 2016

@danbri : Regarding the above #492 (comment):

  • totalTime has been removed from MedicalProcedure since its definition is all about cooking; is a new dedicated property needed?
    R/No for now. Normally as we will have startDateTime and endDateTime for each MedicalProcedure the duration can be calculated (if really needed)
  • Property questions and potential issues:
    What has legalStatus got to do with EventStatusType?
    R/NO idea! It's strange This should be removed. Aah! The initial thoughts were 'everything that has a status' can have 'a legalStatus' as well. But here the EventStatusType is an enumerated type with members: EventCancelled, EventPostponed, EventRescheduled, EventScheduled. So it doesn't apply! Remove it.
  • In future we should review these sub-property claims, maybe add more: diet subPropertyOf instrument; primaryPrevention subPropertyOf preventiveProcedure; possibleTreatment subPropertyOf treatment; exerciseRelatedDiet subPropertyOf instrument .

R/I FULLY AGREE

  • VitalSign is now removed from PhysicalExam and modeled as a MedicalSign subtype
    R/Great! thanks
  • DrugCost - in future explore aligning this with Product.
    R/I agree (I will write all those pending items down to open related issues in near future)
  • Why is a Diet a CreativeWork but not a LifestyleModification?
    R/this is a bug I think.

Thing > MedicalEntity > MedicalProcedure > TherapeuticProcedure > MedicalTherapy > LifestyleModification > Diet
Thing > CreativeWork > Diet

We should remove Thing > CreativeWork > Diet
At the same level of scope: remove Thing > CreativeWork > ExercisePlan and Thing > CreativeWork > Recipe

  • (double definition of) Radiography and its relationship to MedicalImagingTechnique ... why is Radiography a subtype too? There are two definitions to merge, see https://gist.github.com/danbri/9ecc0b02f080389f18adccaa3c6b4fdc ... these have been merged, but unclear if we want subClassOf vs type relating it to MedicalImagingTechnique. Using latter is it is an enumeration. This means the item is in two distinct medical enumerations but isn't considered instantiable.
    R/I prefer having it as type relating it to MedicalImagingTechnique and NOT as subClassOf.

Additionnaly this is not well defined:
`


Radiography is the process or occupation of taking radiographs to assist in medical examinations.

`

The enumerated member corresponding to Radiography is Radiology NOT Radiography.

As we do not have Radiology yet, I would prefer to remove this part of definition.

  • Patient is both a class and an Enumeration.
    R/Ok, it makes sense.
  • Physician is an office/org - how is the individual represented, if at all?

R/This is an expensive disambiguation (between MedialBusiness/Office and Individual) task as we discussed offline earlier with @Leeza.
We should separate the HealthcareProvider enumerated values and the MedicalBusiness enumerated values and MedicalSpeciality enumerated values.

First we need to re-work on the current list on MedicalBusiness enumerated values (use the appropriate grammar/spelling in line with semantics):

*CommunityHealth 
*Dentist >> Dentistry ??? Not sure (as the profession or not science) 
*Dermatology
*DietNutrition 
*Emergency
*Geriatric  >>Geriatrics ?
*Gynecologic
*Hospital
*MedicalClinic
*Midwifery
*Nursing
*Obstetric
*Oncologic
*Optician >>Geriatrics ?
*Optometic >> There's a typo I think ''Optometric" NOT "Optometic" and then... in the same way
*Otolaryngologic
*Pediatric
*Pharmacy
*Physician
*Physiotherapy
*PlasticSurgery
*Podiatric
*PrimaryCare
*Psychiatric
*PublicHealth

Second we need to extend the vocabulary by CREATING the HealthcareProvider types.

HealthcareProvider  (TO BE CREATED)
         with enumerated values:
            > Dentist 
            > Optician
            > Pharmacist
            > Physician

So we can use the following statements (among others)

Dentist
   >medicalSpeciality
        > (one of enumerated values of MedicalSpeciality : TO BE EXTENDED with  f.eg. )
            >medicalDegree (TO BE CREATED)
                >(one of enumerated values of MedicalDegree : TO BE CREATED )           

This will be the next improvement I think.

@danbri danbri pushed a commit that referenced this issue Apr 21, 2016
Dan Brickley Removed legalStatus / EventStatusType domainIncludes association.
From #492
Details #492 (comment)
a355046
@danbri danbri pushed a commit that referenced this issue Apr 21, 2016
Dan Brickley Removed "Radiography is the process or occupation of taking radiograp…
…hs to assist in medical examinations." from Radiography definition.

See #492
#492 (comment)
ecd24d7
@danbri
Contributor
danbri commented Apr 21, 2016 edited

1.) What has legalStatus got to do with EventStatusType?

R/NO idea! It's strange This should be removed.
DONE.

2.) Why is a Diet a CreativeWork but not a LifestyleModification? R/this is a bug I think.

Looking at this, I want to keep Recipe under CreativeWork so let's keep all of them that are currently CreativeWorks.

3.) Radiology, Radiography

Additionally this is not well defined:

Radiography is the process or occupation of taking radiographs to assist in medical examinations.

The enumerated member corresponding to Radiography is Radiology NOT Radiography.
As we do not have Radiology yet, I would prefer to remove this part of definition.

I do not entirely understand what happened here, but I have removed the phrase "Radiography is the process or occupation of taking radiographs to assist in medical examinations."
from the merged description of the Radiography type. I am still unclear why it is a class; how can it
be instantiated usefully?

@danbri danbri pushed a commit that referenced this issue Apr 21, 2016
Dan Brickley Moved terms around PhysicalActivity and ExercisePlan into health-life…
…sci.

See #492
Also #1117 for general best practice documentation which is much needed!

This fixes and implementation issue discovered during v3.0 release candidate review.

We had terms in the leaves of the type hierarchy that were in core, but whose
supertypes were only defined in an extension. This does not work in our current
framework.

Details:
[core]Thing > [health-lifesci]MedicalEntity >[health-lifesci] MedicalTherapy >[health-lifesci] LifestyleModification > [core]PhysicalActivity >[core] ExercisePlan

Resolution (confirmed with @twamarc) was to move the subtrees across
into the health-lifesci extension. This makes sense also because the tone
of the documentation of these terms is in a professional/healthcare voice,
and the terms originated in the same 2013 collaboration (see docs/meddocs.html).

The ExercisePlan type also related to the ExerciseAction type in core. We
have moved the linking property here.

Finally, annotations on 'category' from core extend it to work with two
types from this extension.
950a7bf
@danbri danbri pushed a commit that referenced this issue Apr 21, 2016
Dan Brickley Moved ExercisePlan, PhysicalActivity and related into health-lifesci.
Detailed in previous commit see also #492 and #1117.
f458c03
@danbri danbri pushed a commit that referenced this issue Apr 21, 2016
Dan Brickley LifestyleModification is supertype of PhysicalActivity (restoring fro…
…m core).

For #492 #1117
680f4a7
@westurner
Contributor

re: "Optometic"/"Optometric"/optometrist

... [I'll post this again so that the whole text of this gets sent over the email]

@twamarc
Contributor
twamarc commented Apr 21, 2016 edited

Hmmmm! thanks @westurner!
Let's keep things simple (without being simplistic)!
Let's not try solve the problem the world has not solved, even if it would be a valuable contribution!
3. How do we link these with these Wikipedia URIs? (May be a question for core) In sentence form, one might say: "An ophthalmologist works in the field of ophthalmology" "An ophthalmologist practices ophthalmological medicine" "An ophthalmologist practices ophthalmology" see: dyslexia (Neurologist)
But also
-ic -logy
Ok! I was kidding, sorry!

Seriously we need to keep uniform/principle here. So we can claim monotonic principle. Let's stick on U.S. grammar here (as it was suggested in one of comments some months ago).
First in whatever grammar there's a typo in Optometic>> to change to Optometric and later for improvement to discuss how to disambiguate with optometrist.
Then re-work on the other list.
Lets' keep interacting on this in coming days.

Thanks @westurner!

@westurner
Contributor
westurner commented Apr 22, 2016 edited

So, questions to resolve re: schema.org/MedicalSpecialty :

  • Do we/can we normalize the existing MedicalSpecialty s which are listed?
    • The specialty / field names are mostly (?) -ology
    • Which of these are already published and need to be renamed?
  • Do we/should we just add all of the -ology s from wikipedia:Category:Medical_specialties as Enumeration s?

[edit] see:

@twamarc
Contributor
twamarc commented Apr 22, 2016

@westurner yes we have to normalize the existing MedicalSpecialty terms which are listed. This is a task which is on table since a while (2015):
twamarc/ScheMed#35
twamarc/ScheMed#34

and have been partially discussed but no concrete conclusion/action yet.
Can you screen existing terms and make some suggestions please?

@westurner
Contributor

@twamarc

@westurner yes we have to normalize the existing MedicalSpecialty terms which are listed. This is a task which is on table since a while (2015):
twamarc/ScheMed#35
twamarc/ScheMed#34

and have been partially discussed but no concrete conclusion/action yet.
Can you screen existing terms and make some suggestions please?

  • wikipedia:Category:Medical_speciality is the only resource I'm aware of
  • is there a MedicalSchool Organization which would have expertise here?
@westurner
Contributor

is there a MedicalSchool Organization which would have expertise here?

@twamarc
Contributor
twamarc commented Apr 22, 2016

@danbri
Done with reviewing the extension. Looks fine.

  • Minor typo: Optometic >>> should be Optometric
  • On the front page we have some terms which are displayed twice in the Enumeration values section. eg Optometic, PublicHealth
@jaygray0919
jaygray0919 commented Apr 22, 2016 edited

Have been watching the discussion about Medical/health vocab for some time and should have jumped in earlier. I say that by way of making a feeble excuse for suggesting potentially significant data late in your deliberation.

There are several places where many of the issues in this deliberation have been worked out. At the macro level the Open Biological Ontologies (OBO) define may of the issues raised in this thread. In addition, the US NIH Medical Subject Headings (MeSH) specifically address many of the terms I've seen referenced in this deliberation. The OBO definitions (all OWL-based) have been adjudicated. MeSH is technically not an ontology, although it recently has been rendered in RDF format and can be SPARQLed. However, one cannot 'reason' over MeSH as one can with data defined using OBO ontologies. But 'reasoning' is not an issue in this group, and therefore shouldn't preclude the consideration of MeSH. Further, I have many 'sameAs' declarations for MeSH:DBpedia equivalence, so that work can be marginally updated as needed. In addition to MeSH, there is complementary work done at the US Veterans Administration that could be used in this deliberation. Finally, there is good data integrating FDA medical vocabulary with both MeSH and OBO.

This may fall into the 'a day late and a dollar short' category and should be moved to 'for future consideration.' However, if you are open to considering work done in the specified areas, I'm willing to present a guided tour.

@danbri
Contributor
danbri commented Apr 22, 2016

Thanks @jaygray0919. I agree that it would be better to take a considered approach around specialities and other lists, echoing existing conventions where possible (like OBO) rather than rushing something through for this release. A guided tour of some kind sounds great. I suggest for tidying up this release we focus on typos and on improving the property names in #1114 to be more medical/health oriented.

I remember using MeSH (and UMLS) from my days on the Bristol biomedical image archive. If we can cross-reference (equivalentClass or seeAlso; sameAs in the OWL sense would be too strong) in the schemas that would be great; similarly with DBpedia or Wikidata. We have a few other mappings to external vocabularies already in our schema files (dublin core etc.) but they are not currently exposed in the use interface. The "more..." section of the page would be a natural place for these.

All that said - what should we do with "Optometic"? "Optometric" seems the natural change for now, but Optometry was also mentioned above.

@danbri danbri pushed a commit that referenced this issue Apr 22, 2016
Dan Brickley Optometic -> Optometric.
Per #492 unless there's a quick consensus on a better mapping.

As this is relatively obscure vocabulary I have here decided not to
use supersededBy and retain the old typo version. If it turns out the
typo had significant use we can restore the superseded version for the
records, but my sense is we just make the project look untidy for
minimal gain.
3c18a12
@danbri
Contributor
danbri commented Apr 22, 2016 edited

I've gone for http://health-lifesci.webschemas.org/Optometric for now, seems the obvious fix. We can look into all these names in more detail after sdo-deimos release ships.

@LeezaRodriguez
LeezaRodriguez commented Apr 22, 2016 edited

The existing enumerated list of Medical Specialties appears to be a mix of Medical Specialties and professions. We should consider refining the list to include only true 'Medical Specialties'.
In the US, there is a formal list of 'Medical Specialties' published by the ABMS (American Board of Medical Specialties). When a physician has completed the formal residency program in a Medical Specialty and passed written and oral Boards, he becomes 'Board Certified' in that Medical Specialty.

Each 'Medical Specialty' is regulated by a 'Medical Board'. In the US, the American Board of Medical Specialties (ABMS) regulates 24 Medical Boards which confer 'Medical Specialty' certificates to 37 Medical Specialties. Furthermore, many Medical Specialties have 'Subspecialties' which require an additional training/certification after completing the basic 'Medical Specialty' residency. The 37 Medical Specialties in the ABMS confer 84 Medical Subspecialty certificates.

At the very minimum, we should include each of the 37 Medical Specialties certified by the ABMS.
We can also collapse this list into the European and Worldwide lists of Medical Specialties at Wikipedia, and listed below. Note that the Wikipedia lists are a mix of Medical Specialties and Subspecialties.

  1. ABMS (American Board of Medical Specialties)
    http://www.abms.org/member-boards/specialty-subspecialty-certificates/
    37 Medical Specialties
    84 Medical Subspecialties

  2. Wikipedia List of European Medical Specialties
    56 Medical Specialties
    http://en.wikipedia.org/wiki/Specialty_(medicine)#List_of_specialties_recognized_in_the_European_Union_and_European_Economic_Area

  3. Wikipedia List of Worldwide Medical Specialties
    55 Medical Specialties
    http://en.wikipedia.org/wiki/Specialty_(medicine)#Specialties_that_are_common_world-wide

It is critical that the enumerated list of Medical Specialty members be comprehensive. In Medicine, hospital privileges to physicians are granted according to 'Medical Specialty'. Doctors orders for treatment and care flow down to other health care providers from the Medical Specialist. Standards of care are the jurisdiction of each formal Medical Specialty and associated Medical Board.

We know that consumers routinely make queries like 'what doctors treat epilepsy'. It would be a great service to the consumer if we could help connect the dots between Medical Specialties and treatment. We have a duty to help the search engines better understand these concepts. In a perfect world, all the Medical Subspecialties would be enumerated .

To start, I have made a public spreadsheet to list the existing enumerated members of MedicalSpecialty and proposed changes. This is a work in progress, so it is not complete by any means.

https://docs.google.com/spreadsheets/d/1y7KIP0icoqowZ1uX4H33rVJKfj5WAjIeqkEpnuN6A9U/edit?usp=sharing

Leeza Rodriguez

@jaygray0919

@danbri Ping when the guided tour is timely and appropriate. As you remember, UMLS is very well done. But we can't use it for schema.org because it's controlled by a strict license. In contrast, MeSH terms are in the public domain. MeSH significance meets two criteria: (1) each term is well defined; (2) each term is in a structured hierarchy. We have used schema.org Class, Property and supercededBy to build the MeSH tree in a JSON-LD structure. We're happy to share that work. As an aside, the Google Structured Data Testing Tool will not accept @reverse to create a child entry for a Class (to declare a subClass) which is part of our tree ( very frustrating).

@LeezaRodriguez

@twamarc @danbri , I love the idea of creating HealthcareProvider with an enumerated list of values.

But please remember that the vocabulary term 'Physician', https://schema.org/Physician , is currently being used to represent a Medical Organization, and not the physician person. While this may seem like splitting hairs, it is not.

As I have mentioned to both of you privately, in the US there are different NPI numbers (national provider identifier), https://nppes.cms.hhs.gov/NPPES/Welcome.do, for the physician person vs the physician organization entity. Insurance companies require the reporting of both on claim forms. Likewise, it is the physician person who gets Board Certified in a Medical Specialty, and not his organization entity . And it is the physician person who is the Primary Investigator of a Clinical Trial, and not his organization. The reason I mention these examples is to show the use case for physician person vs physician organization.

HealthcareProvider (TO BE CREATED)
with enumerated values:
> Dentist
> Optician
> Pharmacist
> Physician <---

@westurner
Contributor

I've gone for http://health-lifesci.webschemas.org/Optometric for now, seems the obvious fix. We can look into all these names in more detail after sdo-deimos release ships.

google ngrams: optometric, optometrist

@danbri
Contributor
danbri commented Apr 22, 2016

@westurner indeed, but that takes us beyond a modest typo fix. We have many more other specialities described with similar words: Obstetric, Oncologic, Psychiatric, Geriatric, Gynecologic, Hematologic etc...

@LeezaRodriguez

Just to clarify, this spreadsheet lists suggestions for turning the Medical Specialty adjective descriptions into nouns.
https://docs.google.com/spreadsheets/d/1y7KIP0icoqowZ1uX4H33rVJKfj5WAjIeqkEpnuN6A9U/edit#gid=0

@westurner
Contributor
westurner commented Apr 22, 2016 edited

Could/should there be an adjectiveForm?

Then:

  • MedicalSpecialty.name [noun]
  • MedicalSpecialty.adjectiveForm [adjective]
@twamarc
Contributor
twamarc commented Apr 23, 2016 edited

Hmmm! this is an interesting discussion but please let's keep this simple.
I would suggest to make a complete proposal on the spreadsheet shared by @LeezaRodriguez 👍

https://docs.google.com/spreadsheets/d/1y7KIP0icoqowZ1uX4H33rVJKfj5WAjIeqkEpnuN6A9U/edit#gid=0
So in the next improvement we will propose all the Medical Specialty adjective descriptions into nouns.
The individuals with such specialities will be enumerated under the HealthcareProvider types.

Most usecases we can use the following example model:

Physician
   >medicalSpeciality
        > (one of enumerated values of MedicalSpeciality : RE-FACTORED see the spreadsheet )
        >medicalDegree (TO BE CREATED)
            >(one of enumerated values of MedicalDegree : TO BE CREATED )   
        >certifyingBoard (TO BE CREATED)
            >(one of enumerated values of MedicalCertifyingBoard: TO BE CREATED )           

In this way we will cover both US and EU (taking example of Belgian model and EU commission) use cases.
Can we agree on this as a conclusion to this @westurner and @LeezaRodriguez ?
This will close the issue twamarc/ScheMed#34 as well.

Thanks for rich input on this!
Marc

cc/ @danbri , @davefeg , @vholland , @RichardWallis

@westurner
Contributor
westurner commented Apr 23, 2016 edited

re: Thing > Intangible > Credential > Degree > MedicalDegree

In order that we all might have equal rights,

From twamarc/ScheMed#34 (comment) [edit]:

from the Schema.org Course Extension "schema document":

Thing > Intangible > Credential > OpenBadgesBadgeClass
An OpenBadges BadgeClass.

Thing > Intangible > Credential > Badge > OpenBadgesBadge

@LeezaRodriguez

@twamarc Sounds great to me!

For Physician we could also have properties to identify medicineSystem and the recognizingAuthority of the Medical Board. This would allow search engines to better distinguish between doctors practicing traditional western medicine vs. osteopathic medicine. Consumers without a medical background might not even realize that a healthcare provider whose name is preceded by 'Dr.' can be a Medical Doctor (M.D), or an Osteopath (D.O). And there is big difference in how each doctor would approach the delivery of a baby ....

Joe Smith, M.D., an OB/GYN practicing western medicine

  • medicalDegree = Medical Doctor (M.D.)
  • medicineSystem=Western Conventional
  • medicalSpecialty= Obstetrics and Gynecology
  • certifyingBoard=American Board of Obstetrics and Gynecology
  • recognizingAuthority=American Board of Medical Specialties (ABMS)

Mary Grace, D.O., OB/GYN practicing osteopathic medicine

  • medicalDegree= Doctor of Osteopath (D.O.)
  • medicineSystem=Osteopathic
  • medicalSpecialty=Obstetrics and Gynecology
  • certifyingBoard=American Osteopathic Board of Obstetrics and Gynecology
  • recognizingAuthority=American Osteopathic Association
@westurner
Contributor

Is it possible to have multiple degrees?

@LeezaRodriguez

@westurner Yes, it is possible for a physician to have multiple degrees. In the US, there are some physicians who complete dental school (DDS ), and then apply to medical school to attain the MD degree. However, it is highly unusual to see an MD/OD combination.

What is more common in Medicine is to see MDs with Board Certification in two or more Medical Subspecialties or Medical Specialties. Each Board Certification means that they have completed a Residency in that Medical Specialty and successfully completed the examination requirements. However, these double boarded physicians will typically claim a primary Medical Specialty, and focus their medical practice on only one. Malpractice policies and hospital credentialing (admitting privileges) will typically require the physician to specify which is the primary Medical Specialty.

@LeezaRodriguez

@westurner : I see your recent post (#195) from today defining Credential. Which of these would be applicable to a Medical Specialty or Subspecialty certificate awarded to a M.D. or D.O. upon completion of a medical residency? For the record these credentials are not 'medical licenses', as 'licenses' are issued by individual State and Government jurisdictions. It would be great to make 'MedicalResidency' credential crystal clear for webmasters of medical teaching institutions/medical portals. Thx.

@westurner
Contributor
westurner commented Jun 23, 2016 edited

@LeezaRodriguez

  • Is it a Certificate or a Certification?
    • Certifications imply re-certification (and validFrom, validUntil, etc.)
  • This assumes fiat (that Credential, CredentialInstance, and DegreeType as in #195 #972 will be merged and then exist in schema.org core).
    • I just wrote this up today. I'm still working on examples. Thanks for reminding me of this use case.

Schema RDFa:

<div typeof="rdfs:Class" resource="http://schema.org/MedicalSpecialtyCertificate">
    <span class="h" property="rdfs:label">MedicalSpecialtyCertificate</span>
    <span property="rdfs:comment">A MedicalSpecialtyCertificate Credential TODO</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Certificate">Certificate</a></span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/CertificateType">CertificateType</a></span>
    <!-- TODO: OR -->
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Certification">Certification</a></span>
</div>

<div typeof="rdf:Property" resource="http://schema.org/medicalDegree">
  <span class="h" property="rdfs:label">medicalDegree</span>
  <span property="rdfs:comment">A MedicalDegree for this Person</span>
  <link property="rdfs:subPropertyOf" href="http://schema.org/credential" />
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Person">Person</a></span>
  <!-- TODO: see 'is a physician a person' -->
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Person">Physician</a></span>
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/MedicalDegree">MedicalDegree</a></span>
</div>

<div typeof="rdf:Property" resource="http://schema.org/certifyingBoard">
  <span class="h" property="rdfs:label">certifyingBoard</span>
  <span property="rdfs:comment">TODO</span>
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/MedicalSpecialtyCertificate">MedicalSpecialtyCertificate</a></span>
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Organization">Organization</a></span>
  <!-- this is not yet solved for: -->
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/CredentialInstance">CredentialInstance</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/MedicalDegreeType">
    <span class="h" property="rdfs:label">MedicalDegreeType</span>
    <span property="rdfs:comment">A type of an Medical Degree AcademicDegree</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/AcademicDegreeType">AcademicDegreeType</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/MedicalDoctorDegree">
    <span class="h" property="rdfs:label">MedicalDoctorDegree</span>
    <span property="rdfs:comment">A MedicalDoctor Degree MedicalDegreeType</span>
    <span property="schema:alternateName">MD</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalDegreeType">MedicalDegreeType</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/OsteopathicDoctorDegree">
    <span class="h" property="rdfs:label">OsteopathicDoctorDegree</span>
    <span property="rdfs:comment">A OsteopathicDoctor Degree MedicalDegreeType</span>
    <span property="schema:alternateName">DO</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalDegreeType">MedicalDegreeType</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/PodiatricDoctorDegree">
    <span class="h" property="rdfs:label">PodiatricDoctorDegree</span>
    <span property="rdfs:comment">A PodiatricDoctor Degree MedicalDegreeType</span>
    <span property="schema:alternateName">DPM</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalDegreeType">MedicalDegreeType</a></span>
</div>


<div typeof="rdf:Property" resource="http://schema.org/abbreviation">
  <span class="h" property="rdfs:label">abbreviation</span>
  <span property="rdfs:comment">An abbreviation (see also: alternateName)</span>
  <span>Thing: <a property="http://schema.org/domainIncludes" href="http://schema.org/Thing">Thing</a></span>
  <span>Text: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Text">Text</a></span>
  <span>Abbreviation: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Abbreviation">Abbreviation</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/Abbreviation">
    <span class="h" property="rdfs:label">Abbreviation</span>
    <span property="rdfs:comment">An abbreviation for something (name for abbreviation, description for a description of context)</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Intangible">Intangible</a></span>
</div>

JSON-LD example:

TYPES: #MedicalSpecialtyCertificate1 CredentialInstance, MedicalSpecialtyCertificate

"@type": "CredentialInstance",
  "credentialIssuee": {
    "@type": "Person",
    "name": "Joe Smith, M.D."
  },
  "credential": {
    "@type": "MedicalSpecialtyCertificate",
    "credentialType": "MedicalSpecialtyCertificate",
    "credentialIssuer": {
      "@type": "Organization",
      "name": "American Board of Obstetrics and Gynecology",
      "url": "..."
    },
    "medicalDegree": {
      "@type": "MedicalDegree",
      "credentialType": "MedicalDoctorDegree"
    },
    "medicineSystem": "WesternConventional",
    "medicalSpecialty": ["Obstetric", "Gynecologic"],
    "certifyingBoard": {
      "@type": "Organization",
      "name": "American Board of Obstetrics and Gynecology",
      "url": "..."
    },
    "recognizingAuthority": {
      "@type": "Organization",
      "name": "American Board of Medical Specialties (ABMS)",
      "url": "..."
    }
)

MedicalDegreeType

Regarding degrees:

  • Thing > CreativeWork > Credential > AcademicDegree > DoctoralDegree
  • [-] Thing > CreativeWork > Credential > AcademicDegree > MedicalDegree
  • [-] CredentialType > AcademicDegreeType > MedicalDegreeType
    • [-] MedicalDegreeType > MedicalDoctorDegree (MD)
    • [-] MedicalDegreeType > OsteopathicDoctorDegree (DO)
    • [-] MedicalDegreeType > PodiatricDoctorDegree (DPM)
    • MedicalDegree > NursingDegree
    • MedicalDegreeType > NursingDegreeType
      • Types are combinable (BachelorDegree, NursingDegreeType})
      • NursingDegreeType >
        • {BachelorDegree, NursingDegree} > BSN
        • {GraduateDegree, NursingDegree} > MSN
        • {DoctorateDegree, NursingDegree} > ND
        • LPN
        • LSN

is a Physician a Person?

Regarding http://schema.org/Physician :

  • Thing > Organization > MedicalOrganization > Physician
  • Thing > Person > Physician
how to specify a primary MedicalSpecialtyCertificate

I can think of twoo ways to do primaryMedicalSpecialtyCertificate:

  • subclass CredentialInstance and create a property
    • CredentialInstance > MedicalSpecialtyCertificateInstance
      • P: primaryMedicalSpecialtyCertificate d: Person r: MedicalSpecialtyCertificateInstance
        • d: Physician ? (Organization / Person)
  • create isPrimaryCredential and then
    isPrimaryMedicalSpecialtyCertificate as a subPropertyOf
    • P: CredentialInstance.isPrimaryCredential
      • P: CredentialInstance.isPrimaryMedicalSpecialtyCertificate r: MedicalSpecialtyCertificateInstance

And then there's trying to rely on the source order
so that the first listed is assumed the primary MedicalSpecialtyCertificate;
which works differently in different representations:

  • RDFa, Microdata: most parsers preserve source order
  • JSON-LD: the parser may preserve source order, JSON libraries may not preserve source order (of hash maps)
@danbri
Contributor
danbri commented Jun 23, 2016

"And then there's trying to rely on the source order" - for schema.org we need the order to be explicit; it is not enough to rely on the order that information is found within a document being parsed.

@LeezaRodriguez

@westurner I love the way you are thinking, especially associating the Medical Specialty certificates (ex: Obstetrics) with their certifyingBoard (American Board of Obstetrics and Gynecology) with oversight by a recognizingAuthority (American Board of Medical Specialties). YES! These relationships are critical for search engines to eventually figure out who the bogus Medical Boards are. Bogus Boards have little or no oversight (no recognizingAuthority).

To answer your questions:

Medical Residency certificate or certification?
Based on your description, in the USA, the Medical Specialty completion is a certification. Most certificates have 'issued' and 'valid until' fields. However, some Medical Specialties still have a grandfather clause such that 'valid until= indefinitely' appears on the certificate.

Is Schema.org/Physician a person?
No, it currently represents a doctor's office, a place. I believe this is confusing for webmasters and will create problems. @twamarc has assured me that this issue will be addressed in the next version. Personally, I don't think we should wait to do this. Why the rush? Not to sound too dramatic, but I think we are already facing an ontology alignment issue. Allow me:

  • In Freebase, Physician MID was typed as a person
  • In Wikidata, Physician QID is a person, and the associated MID from Freebase is already listed as a property on this item.

And to make it more interesting, the Google KG shows Physician as a 'profession'.

What to do?
We need to disambiguate between the Physician office and the Physician person. If we don't, this could become very messy with respect to Board Certification, licenses, insurance and Clinical Trial vocabulary . In the USA, the physician person and the physician office are two completely different entities. Each entity has it's own NPI (National Provider Identifier) number. Furthermore, Board Certifications and licenses to practice medicine are attached to the physician person, and not the organization entity. Just off the top of my head, here are some differences in the US:

Physician person gets these:

  • Medical Specialty Certification (from an academic institution upon completion of a residency)
  • Board Certification (from a Medical Board after taking exams following residency completion)
  • State License to practice medicine (from the State Government)
  • DEA number (from the US Gov to write prescriptions)
  • NPI number (from HHS Fed Gov)
  • Malpractice policy (commercial entity)
  • Tax ID number (Fed Gov)
  • Primary Investigator in a Clinical Trial (FDA)

Physician organization entity gets these:

  • NPI number (from HHS Fed Gov)
  • Tax ID number (Fed Gov)
  • Clinical Trial Site or Sponsor (FDA)

But there's more...
In the next version, we need to modify the Medical Specialty enumerations to all be nouns (not adjectives), as well as modify the existing list to be more aligned with ABMS and the Worldwide Medical Specialities listed in Wikipedia. At the moment, IMO, it's a bit of a hot mess!

@westurner
Contributor
westurner commented Jul 15, 2016 edited
  • These codes are different in different countries.
  • Q: What would be the best way to model these country-specific Physician codes?
@LeezaRodriguez

@westurner Can you please clarify which codes you are referring to?

@westurner
Contributor

@LeezaRodriguez Physician license and certification numbers could be modeled as http://schema.org/Number codeValues, or -- more completely -- with classes and properties for each Credential.

With something like PhysicianUnitedStates, there could be defined properties for each requisite Credential.

With something like http://schema.org/MedicalCode codeValue codingSystem, there wouldn't be need to define each country's specific coding systems in health-lifesci; but that would be lossy

@LeezaRodriguez

Thanks, and I agree http://schema.org/MedicalCode coding system does not need to be country specific.

But to digress a bit, I'm still not clear how the existing Physician organization type (http://schema.org/Physician) and the new Physician person type will be disambiguated in this schema.org hierarchy. ? Can you or @twamarc clarify for me?

  • Does http://schema.org/Physician remain as an organization/local business in the core?
  • Will a new ~ @PhysicianMD (person) type be designated in the extension or in the core?

WRT the physician person credentials , one could think of a medical 'license' to practice medicine in a particular state/jurisdiction/country as a 'permit' or a 'license'. However, the 'certification' in a MedicalSpecialty (following completion of a residency program) is absolutely it's own animal, not a 'degree', and is worthy of it's own property similar to what you outlined above.

@twamarc
Contributor
twamarc commented Jul 18, 2016 edited

within the current fixes, the existing Physician organization (http://schema.org/Physician) and the new Physician person will be 2 different types.
i.e http://schema.org/Physician will remain as an organization/local business and remain in the core (probably definition fine-tuned -or used as PhysicianOffice) and the Physician person will be in the extension.

@danbri
Contributor
danbri commented Jul 18, 2016

Just to clarify, it is a flat namespace: you can't have the same term in an extension and the core. So if the extension has a different notion of Physician-as-a-Person it can't be called 'Physician' if that term is used differently in the core.

@westurner
Contributor

In this instance, is there a reason that a Physician could not be both a
Person and an Organization?

Organization > Physician
Person > Physician

Organization > MedicalTeam might've been a more specific relation than
Organization > Physician. AFAIU, schema migrations are relatively
impractical?

https://en.wikipedia.org/wiki/Physician

  • Physician
  • Medical Doctor
  • Physician and Surgeon
  • Internist (-> MedicalSpecialty)
  • Hospitalist (-> MedicalSpeciality)
  • General Practitioner
  • General Internist

On Jul 18, 2016 8:00 AM, "Dan Brickley" notifications@github.com wrote:

Just to clarify, it is a flat namespace: you can't have the same term in
an extension and the core. So if the extension has a different notion of
Physician-as-a-Person it can't be called 'Physician' if that term is used
differently in the core.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#492 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADGy2ONyDj5UGkJekrVusM_7CqkR9x5ks5qW2rMgaJpZM4EZ8rH
.

@thadguidry
thadguidry commented Jul 19, 2016 edited

@LeezaRodriguez I have mentioned this before in your Freebase training days with me :) ... but to reiterate for all again... Schema.org (and in the past, Freebase) already has the 2 necessary types to disambiguate. There is no need to make a Physican#2 Type.

schema.org/Physician A PERSON (with a set of properties...to include all those you listed)
schema.org/MedicalOrganization A ORGANIZATION (with its own set of properties)

For us in Schema.org, both the Physician and the MedicalOrganization just need to have a few more properties defined under them, like npiID, (In fact, MedicalOrganization already has 4 useful ones like duns, leicode, vatID,, taxID) Reference: https://npiregistry.cms.hhs.gov/

The idea of our 2 existing Types already aligns perfectly with how Wikidata views things as well... internally Wikdata has Authority Control ID spaces for both our Types , Person and Organization !

https://www.wikidata.org/wiki/Q21745557 Wikidata property for authority control for organisations
https://www.wikidata.org/wiki/Q19595382 Wikidata property for authority control for people

So all that's needed is someone at or in Wikdata to make a proposal for a new property called NPI ID , such as all of these that exist already : SPARQL QUERY FOR UNIQUE IDS AND AUTHORITY CONTROL OF PEOPLE

@LeezaRodriguez

Hi Thad! I'm still ever so grateful for my training wheels! Much insight , much joy.

To clarify the data modeling that Thad and I are describing:
A Physician is a person who is associated with or works for a MedicalOrganization. Webmasters need ability to model this relationship exactly and with ease.

A good path forward would be to immediately redefine http://schema.org/Physician to be a person. In this capacity, this Type would be properly aligned with other linked nodes in the ontology ecosystem, especially Wikidata, the new mothernode.

To overview the landscape, Physician is currently defined as such:

As you can see from the above, Physician is a person in Wikidata (and Freebase). The logical step forward is to make it a person in Schema.org. If not,.... who among you is fearless enough to go into Wikidata and make changes to the definitions there? If you try, you will never come out alive!!! .

Now, let's consider the relationship between the Physician (person) and the Organization he works for. I see redundancy with the types that are currently listed in the full hierarchy:

Perhaps we only need one of these types to show a relationship between the Physician and who he is affiliated with. MedicalOrganization is the most versatile, as it can be for profit or non-profit. Should we consider eliminating one of these?

Thoughts?

@thadguidry

@LeezaRodriguez You forgot to mention the un-usefulness of bucket types (types without properties). :)

@LeezaRodriguez

I realize this is painful, but we need to address the http://schema.org/Physician dilemma ASAP. There is already confusion in the wild. We can't take the easy way out. We have to think about how this will scale in the future!

As the schema.org vocab grows for the clinical trial space and the insurance industry this will likely get messy and come back to haunt, especially as Wikidata grows simultaneously . With insurance, not all doctors within a medical office or organization will participate with an insurance carrier.

If we don't model this to clearly show the relationship between the physician and the medical organization he works for/is affiliated with/is credentialed by, we are going to make it very difficult for search engines to understand the relationships.

How would we dare to not align http://schema.org/Physician with Wikidata QID 'Physician'? Please enlighten me.

Sorry to be such a nag :)

@ppKrauss

Hi, I think is importante to notice and remember how ambiguous can be (some) SchemaOrg definitions, as "Physician", without a semantic link ... The issue#280 is to solve this problem with links to stable Wikidata concepts, but need help (!) and hands-on to evolve.

@LeezaRodriguez

@ppKrauss Yes, and as you know @thadguidry is working on that mapping. Thad sees confusion with the current schema.org definition, and so do I.

This is why we are both suggesting to redefine http://schema.org/Physician as a person. Again, I realize this is a bit of a headache.

But otherwise, we have to align the current http://schema.org/Physician with the Wikidata concept to be equivalent with 'a physician's office' , rather than 'physician' (the person) QID in Wikidata, https://www.wikidata.org/wiki/Q39631

And if we leave the current schema.org definition as it is, what vocab do we use for physician-the-person in the extension? You really can't use 'medicaldoctor', as that implies an M.D. degree, and does not include D.O.s, who are also physicians. Using the term 'doctor', could open up confusion with phD's.

@danbri
Contributor
danbri commented Aug 10, 2016

The health-lifesci.schema.org extension was published in 3.0 and announced (after we fixed some bugs!) with 3.1 yesterday, http://blog.schema.org/2016/08/schemaorg-update-hotels-datasets-health.html

There are various themes of discussion continuing here but all muddled together. I will close out this issue, and encourage all continued discussions to happen via more dedicated issues. Do create them if necessary but have a look for any pre-existing older issues first, we have 100s open and it's important to keep our open issue count under country.

Thanks again to everyone who contributed to the health-lifesci milestone - it was one of the largest structural changes we've made to how the schemas here are organized.

@danbri danbri closed this Aug 10, 2016
@jetaro1
jetaro1 commented Oct 7, 2016

thanks all :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment