This is a huge change.

At a basic submission process level, I would recommend:

• a real git commit message (to help those following the evolution of schema.org)
• taking out the inline comment to danbri (we don't really want those comments in the production version of schema.org)
• double-checking the patch (there are duplicate entries for Birth and BodySubstance

After a quick glance at the patch, I would recommend at least the following (there is probably more that a deeper analysis would draw out):

• changing Hormonetherapy to HormoneTherapy
• changing Vitalsign to VitalSign

Overly generic type and property name alerts (perhaps prefix with "Medical"?):

• Admission
• LifeEvent
• Sign
• Transfer
• admission
• discharge
• encounter
• indication

QualifierConcept - perhaps this would be superseded by the simple SKOS proposal?

belongsTo - might overlap with a property from the Periodical proposal

New updated file is committed with suggestions made and approved by the WG.
Within text reply:

At a basic submission process level, I would recommend:
-a real git commit message (to help those following the evolution of schema.org)
+>Done but will be submitted separately as README!

-taking out the inline comment to danbri (we don't really want those comments in the production version of schema.org)
+>Done!

-double-checking the patch (there are duplicate entries for Birth and BodySubstance)
+>Done! that was a bug in RDFa generated file

After a quick glance at the patch, I would recommend at least the following (there is probably more that a deeper analysis would draw out):

-changing Hormonetherapy to HormoneTherapy
+>Approved and Done!
-changing Vitalsign to VitalSign
+>Approved and Done!

Overly generic type and property name alerts (perhaps prefix with "Medical"?):
Admission ++>Approved and Done!
LifeEvent - ->Not approved : we would keep this class broader than only for medical life events!
Sign ++>Approved and Done!
Transfer ++>Approved and Done!
admission ++>Approved and Done!
discharge ++>Approved and Done!
encounter ++>Approved and Done!
indication - ->Not approved : this property is already existing in schema and changing it would be first largely discussed!

QualifierConcept - perhaps this would be superseded by the simple SKOS proposal?

• ->Not approved : This needs discussions at upper level in schema.org

belongsTo - might overlap with a property from the Periodical proposal

• ->Not approved : This needs discussions at upper level in schema.org

Thanks

Thanks for this quick feedback Dan Scott.

Well, it's a quite huge patch, this is a healthcare community effort
initiated last year, to enable the use of schema.org not only in indexing
healthcare web/documents but also as a pillar source of medical
ontology/vocabulary for HL7 standards based APIs and for Semantic layer of
ICD11 under preparation at world health organization. The test was already
done with SALUS EU FP7 project- with AGFA Healthcare as a partner, and was
successful.

So I agree with you, about the real git message. We have prepared a whole
page and a summary paragraph to explain the rationale behind the patch,
and introduce this to our colleagues but so far was not in the commit
message- I will add it tomorrow.

The recommendations are implemented (except renaming property--- will do it
tomorrow with discussion with the working group who worked on this).
Sure there will be other recommendations and we will be available to
implement those (class/property discuscussions, good practices compliance,
extends, etc).
QualifierConcept --we need discussions with the WG
belongsTo - Yeah we need to harmonize! will look at this.

Tomorrow I will commit the updated file.

Thanks

Marc

On 8 May 2014 22:12, Dan Scott notifications@github.com wrote:

This is a huge change.

At a basic submission process level, I would recommend:

• a real git commit message (to help those following the evolution of
  schema.org)
• taking out the inline comment to danbri (we don't really want those
  comments in the production version of schema.org)
• double-checking the patch (there are duplicate entries for Birth and
  BodySubstance

After a quick glance at the patch, I would recommend at least the
following (there is probably more that a deeper analysis would draw out):

• changing Hormonetherapy to HormoneTherapy
• changing Vitalsign to VitalSign

Overly generic type and property name alerts (perhaps prefix with
"Medical"?):

• Admission
• LifeEvent
• Sign
• Transfer
• admission
• discharge
• encounter
• indication

QualifierConcept - perhaps this would be superseded by the simple SKOS
proposal?

belongsTo - might overlap with a property from the Periodical proposal

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/11#issuecomment-42600314
.

Hi. Thanks for the proposal. As Dan mentions, it is (by schema.org standards) a large proposal. It will take some time to digest.

I took a very quick skim through the document (I can't find a 'diff' view in the github UI for some reason). Some quick notes on issues that jump out at me:

1. ...Range: decimal ... what is 'decimal'? I don't see it in the proposal, and it isn't in the current schema.
2. ... Range: http://snomed.info/169812000

-> The IHTSDO website is currently being reorganized to make it easier to navigate. Unfortunately one effect of this is to change the addresses of some pages

... did the snomed site change since you created these links?

We should probably document a clearer approach for expressing mappings to external types/properties. So far we've used owl:equivalentProperty experimentally, so that rangeIncludes and domainIncludes are only used for internal links.
1.

-> no mention of Place here? or in the other place-related proposed types?
1.

Related - the family tree stuff should be reconciled with non-medical family history use cases, https://www.w3.org/wiki/WebSchemas/HistoricalDataSchema ... esp considering cases like adoption, where implying 'biological parent' may be inappropriate and exclude reasonable usage.

Have you tried running the site with AppEngine to see if this schema is read properly?

Thanks Dan.
This is a very contributing feedback. We are quite aware about the extent of proposal. It was not possible to submit it gradually as it was necessary to have a comprehensive file with all related concepts linked. So we are aware that it may take some time to digest. However the whole WG will be always available for any other discussion/suggestion/question.

All your suggestions are relevant and have been implemented. Some comments within the text below:

...Range: decimal
... what is 'decimal'? I don't see it in the proposal, and it isn't in the current schema.
+1 Fixed: this was a bug in RDFa generated file
...
Range/Domain: http://snomed.info/169812000
-> The IHTSDO website is currently being reorganized to make it easier to navigate. Unfortunately one effect of this is to change the addresses of some pages
... did the snomed site change since you created these links?

         +1 Fixed: With couple of discussions here and with our team in Geneva  (Dave et al.) using SNOMED CT we adopted using the stable and publicly resorvable URI <http://purl.bioontology.org/ontology/SNOMEDCT/169812000>. For the visualisation purposes we use "sctid:169812000".

All snomed ct concepts will follow this principle. We welcome discussions at schema.org level about to document a clearer approach for expressing mappings to external types/properties.

...
deathPlace Specifying the place of death for a person Domain: http://schema.org/Person Domain: Death Range: http://snomed.info/169812000
-> no mention of Place here? or in the other place-related proposed types?
+1 Fixed: schema:Place was added as well as rangeIncludes object.
...
familyHistory Specifying a personal history as a part of a full medical history provided by the patient during an anamnesis procedure . Domain: http://schema.org/Person Range: http://snomed.info/57177007 SubProperty of: medicalHistory
... is this family medical history?
+1 Fixed: we welcome this constructive feedback, familyHistory was changed to familyMedicalHistory to avoid any use/mis-use or ambiguity.

Related - the family tree stuff should be reconciled with non-medical family history use cases, https://www.w3.org/wiki/WebSchemas/HistoricalDataSchema ... esp considering cases like adoption, where implying 'biological parent' may be inappropriate and exclude reasonable usage.
+1 Agreed: following the discussions there about family tree stuff and the example given here, we suggested to retract the properties 'biologicalFather/biologicalMother' until any further agreement within the community.

Have you tried running the site with AppEngine to see if this schema is read properly?
-1 No: We have not used AppEngine but Jos De Roo is using in similar way RDFa internal tool visualiser he developed and it's quite OK! We will test this with other engine as well.

The reworked file will be committed in asap with pull request.

Minor fixing
1.Restoring a lost property medicalScore
2.Fixing rdfs:subPropertyOf issues:
*the automatically generated rdfs:subPropertyOf http://www.w3.org/2002/07/owl#topObjectProperty was removed
*the error in hierarchy was fixed: maritalStatus,encounter, race and ethnicity

twamarc, can you outline any expected use of this new vocabulary? are any publishers or consumers currently involved with the proposal?

Current use:
Already consumers are using 90% of the properties/classes included in the proposal (as not yet accepted in schema.org all services are using a temporarly namespace to be replaced by schema: once the proposal accepted).

Consumers /also involved in proposal design:

1. Software Research and Development and Consultancy Ltd.(SRDC, Turkey), - only through SALUS EU Project
2. European Institute for Health Records (EUROREC, France) also as a partner in SALUS EU Project
3. Uppsala Collaborating Centre for International Drug Monitoring (UMC) - World Health Organization (WHO) Collaborating Centre - only through SALUS EU Project
4. Institute for Information Technology (OFFIS), Germany also as a partner in SALUS EU Project
5. AGFA Healthcare N.V. AGFA, Belgium -- Advance Clinical Application group services
6. Electronic Record Services BV (ERS, Netherlands) - only through SALUS EU Project
7. Lombardia Informatica S.p.A.(LISPA, Italy)- only through SALUS EU Project
8. Institut National de la Santé et de la Recherche Médical (INSERM), France -also as a partner in SALUS EU Project
9. Technische Universitaet Dresden (TUD, Germany) -also as a partner in SALUS EU Project
10. F. Hoffmann-La ROCHE AG (ROCHE), Switzerland - only through SALUS EU Project

Tools and services developed by SALUS EU Project using the properties/classes included in the proposal (all will be openSource):

• Toolsets for Enabling Adverse Drug Events (ADE) Detection on EHRs based on temporal patterns, the ADE Notification Tool (ANT).
• Semantic Interoperability Layer (SIL)
• SALUS Harmonized Ontology for Pharmaceutical Post Market Safety Studies - the Comon Information Model (http://www.srdc.com.tr/projects/salus/blog/?p=342)
• Tools and environments enabling the re-use of electronic health records (ICSR Reporting Tool)
• Architecture of the Technical Interoperability Profile for SALUS (TIL)

Expected use:

• CosmeticSurg, Lutherville Timonium, Maryland (team of Leeza Rodriguez, Jarno Van Driel) -http://www.cosmeticsurg.net/
• The 11th International Statistical Classification of Diseases (ICD) being drafted at World Health Organization (WHO) -Already the team of Dave working on this collaborated and reviewed the proposal.
• Academic instututions (UGent-iMinds, etc)
• Hospital institutions ( some services used in HIS eg at "Assistance publique – Hôpitaux de Paris")

Personal note:

• In line with healthcare IT community new initiatives (HL7 FHIR, CIMI, OpenEHR etc) and the real need in interoperability, the trend is now to develop clinical models not using local/internal ontology or a proper new ontology but only 3rd party ontology (mainly the schema.org but also W3C and others). This highlights the place of such extended vocabulary.

People involved in the initial proposal drafting (I will not quote all people who interacted in mailing list/Google group):
-Marc Twagirumukiza
-Jos De Roo
-Dirk Colaert
-Kristof Depraetere
-Leeza Rodriguez
-Jarno Van Driel
Other resources

• Former DebugIT EU Project work, thanks the team collaboration and partners(E. Pasche, J. Gobeill, P. Ruch, et al)

Just a note:

As indicated earlier, this proposal is quite extensive and I feel that if we want the average medical website to start making use of it as well, than an effort to make providers of medical care become aware of it and some guidance in implementing it has to be made as well.

Now in regards to the expected use, if there's any support needed in making of code examples, test-cases, feedback about usability from a web developer's perspective, etc, just let me know. I'm always happy to help out.

ScheMed use perspective:
Although am not talking on behalf of any organization or working groups/consultancy task forces am affiliated to, I think effort was the missing piece for the majority schema.org user in indexing health/mdical data and informations( meta-data, webpages, and documents). There's a big hope that once this is integrated and published this my help a lot in the work of putting semantic layer on the 11th International Statistical Classification of Diseases (ICD) being drafted at World Health Organization (WHO). Also as I communicated with Marc on this, it will be a good momentum to work on interoperability using a single 3rd party source of our medical ontology/vocabulary. I had a look on the CIMv2 models used in SALUS project, and I think this will be a nice experience to follow. Why not discuss this with FHIR team (from HL7) already? any use case can help here as well preparing such big step. Thanks to Jarno for any further help on this. But first le'ts have this reviewed by schema.org and published.
Finally we have to accept that this is not including all desiderata of health IT community so we have humbly to expect further extensions or polishing efforts.

Thanks for the extra background information.

Have you had any success yet in running a copy of the schema.org site software using the RDFa patched in this pull request? It would also be great to have a high level overview of the principle changes, since these are difficult to discern from a textual diff of the schemas. What are the main changes here? Are there non-backwards-compatible edits, for example?

Unfortunately we do not have the Google App Engine to run the RDFa patched in this pull request.
We just ran the RDFa copy on our internal RDFa visualization tool and I tested on online free tools. Can someone here-within community, help running this with Google App Engine and send me a feedback? Or can someone heIp with extra info on how to run this?
I do not know how relevant and mandatory this is but any help on this is welcome.
Maybe Jarno team can help on this?
We will continue to maintain the RDFa file of course.

The patch is mainly additions and is following the schema.org phylosopy/best practices. We avoided some discussions interfering with high-level schema.org design. There is however one point new in the patch (not really new following the discussions on it), it is the use of snomed ct classes as object of domainIncludes/rangeIncludes.
So we have no changes, just some necessary updates to relate the new classes/properties with the existing ones, like declaring existing schema classes/properties as subClass of or subPropertyOf.
Mainly:
-Added AnatomicalOrgan and AnatomicalRegion classes under hierarchy of AnatomicalEntity class and related properties
-Extended subclass of AnatomicalSystem class and related properties
-Extended subclass of MedicalSignOrSymptom class and related properties
-Big extension in MedicalProcedure with a one change (actually additional declaration) of making the MedicalTherapy a subclass of TherapeuticProcedure class, itself a subclass of MedicalProcedure class. The PreventieProcedure become a subclass of MedicalProcedure class as well.
-extending Person class with Patient class as subclass.
-making the Drug also a subclass in low level hierarchy of Substance (the new class).

On properties:
-adverseOutcome, location, provider, medicalSpeciality and procedure was extended with granular subproperties
-status was extended with 2 granular subproperties

The big merge with all very recent updates in schema.org (typo fixing, US english use, etc...) will be done at final stage to avoid granular separates commits.
So far there no there non-backwards-compatible edits in the patch.

I'd be willing to help, if I only knew how to use the software.
Unfortunately it's still a mystery to me. Extra info on how to do this
would be much appreciated.

2014-06-03 11:34 GMT+02:00 Marc notifications@github.com:

Unfortunately we do not have the Google App Engine to run the RDFa patched
in this pull request.
We just ran the RDFa copy on our internal RDFa visualization tool and I
tested on online free tools. Can someone here-within community, help
running this with Google App Engine and send me a feedback? Or can someone
heIp with extra info on how to run this?
I do not know how relevant and mandatory this is but any help on this is
welcome.
Maybe Jarno team can help on this?
We will continue to maintain the RDFa file of course.

The patch is mainly additions and is following the schema.org
phylosopy/best practices. We avoided some discussions interfering with
high-level schema.org design. There is however one point new in the patch
(not really new following the discussions on it), it is the use of snomed
ct classes as object of domainIncludes/rangeIncludes.
So we have no changes, just some necessary updates to relate the new
classes/properties with the existing ones, like declaring existing schema
classes/properties as subClass of or subPropertyOf.
Mainly:
-Added AnatomicalOrgan and AnatomicalRegion classes under hierarchy of
AnatomicalEntity class and related properties
-Extended subclass of AnatomicalSystem class and related properties
-Extended subclass of MedicalSignOrSymptom class and related properties
-Big extension in MedicalProcedure with a one change (actually additional
declaration) of making the MedicalTherapy a subclass of
TherapeuticProcedure class, itself a subclass of MedicalProcedure class.
The PreventieProcedure become a subclass of MedicalProcedure class as well.
-extending Person class with Patient class as subclass.
-making the Drug also a subclass in low level hierarchy of Substance (the
new class).

On properties:
-adverseOutcome, location, provider, medicalSpeciality and procedure was
extended with granular subproperties
-status was extended with 2 granular subproperties

The big merge with all very recent updates in schema.org (typo fixing, US
english use, etc...) will be done at final stage to avoid granular
separates commits.
So far there no there non-backwards-compatible edits in the patch.

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

Jarno van Driel
Technical & Semantic SEO Consultant
8 Digits - Digital Marketing Technologies

Tel: +31 652 847 608
Google+: https://plus.google.com/u/0/+JarnovanDriel
Linkedin: linkedin.com/pub/jarno-van-driel/75/470/36a/

The site software is a very basic Google App Engine python application. The only complexity should be the basic installation of AppEngine. On OSX this is very self contained. On Windows, I understand that there is more difficulty since you need to install Python yourself. Once you appengine.google.com working (and a basic understanding of the appengine approach) it should be trivial. I suggest first getting appengine running, then trying it with the standard lateset version of this repo; once you've achieved that, it should be easy to test and adapt the RDFa.

Thanks to Giovani, Kristof and Jos (ACA team), we have run a copy of the schema.org site software using the RDFa patched in this pull request and the tests were successful. We could also browse throughout the classes and properties.

There was one test failing, even from the origin rdfa file, the following:
FAIL: test_suggestedAnswerSuperpropertiesArrayLen (test_basics.SchemaPropertyMetadataTestCase)
Traceback (most recent call last):
File "D:\Users\axpzc\GitHub\schemaorg\tests\test_basics.py", line 195, in test_suggestedAnswerSuperp
ropertiesArrayLen
self.assertEqual( len(sa_supers), 1, "suggestedAnswer subproperties() gives array of len 1." )
AssertionError: suggestedAnswer subproperties() gives array of len 1.

Do you know why?
By the way how can we regenerate the files under .../docs ?

I'm glad you have the site running!

Thanks for the note on the test failing. The tests are new, and there was a mistake which I had fixed in data but not in code. This shows I should run tests on every commit, rather than on every site release!

You can ignore this test. I've replaced it with

def test_acceptedAnswerSuperpropertiesArrayLen(self):
p_acceptedAnswer = Unit.GetUnit("acceptedAnswer")
aa_supers = p_acceptedAnswer.superproperties()
self.assertEqual( len(aa_supers), 1, "acceptedAnswer subproperties() gives array of len 1." )

but will post those changes later as I'm trying to set up a branch/fork structure for cleaner workflow.

Regarding docs/ they aren't currently autogenerated. I'll work on the 'full view' page next week.

Do you have a human-oriented overview of the main changes in this proposal? How many are fixes versus additions, etc.?

Comparing the existing schema.rdfa file and the medicalEntity.rdfa patch there are in total 2569 additions, 7 fixes (addition of subPropertyOf/subClassOf in existing properties/classes) , 0 changes and 0 deletions.
This was done intentionally we did not want to make huge changes/deletions in existing schema.
We are aware that some improvement in existing schema will be done later, once the patch is published (esp. in hierarchy i.e subClassOf , in range/domain objects and in rdfs:comment and/or definitions).
Few of them are being discussed in mailing list or have been already implimented like MedicalEnumeration or MedicalProcedure.
I will prepare this human-oriented overview of the main changes in a separate file and post it soon.

I made a new PR #1056 targetting sdo-deimos, and have (with some manual tweaks) just merged it into that branch for review.

This (PR #1056) needs some review.

From a quick look, some core properties have been wrongly pulled into the extension. For example 'status' and 'purpose' They may be modified in the extension (eg. extending the domain and/or range) but their original definition belongs in the core.

Yes, review is what it needs. There is a very rough first cut up at http://health-lifesci.webschemas.org/ but note that I've not yet made the general front page text, so it just gives a big ugly list of terms from the extension. However you can also navigate in from http://webschemas.org/docs/meddocs.html

(btw think of webschemas.org as a volatile work-in-progress upstream test version, in sync with the latest proposed changes committed to our next release branch)

Good progress! Thanks
I will review again to fix those core properties inadequately pulled into the extension.

MedicalScholarlyArticle seems needless. I understand a wish to introduce the pubType field, but the terms listed by MeSH are generic and apply to any ScholarlyArticle. I would prefer to see it added then to that type.

@egonw for better or worse, we have had http://schema.org/MedicalScholarlyArticle since http://blog.schema.org/2012/06/health-and-medical-vocabulary-for.html in 2012. The bulk of the work in this set of changes is to move the super-detailed medical and health vocabulary that we already have into a dedicated health-lifesci extension, where other related efforts can also live.

@twamarc if you have further change suggestions it may be best to outline them here textually, rather than via Pull Request. If you do make a pull request, it should be based on the current state of the sdo-deimos branch here to avoid complexity.

(I'm going to close the pull request since it has effectively been merged, but we can continue to discuss here)

@danbri : Thanks. Maybe we can completery close this thread and follow the comments, improvements at

• Medical/health vocabulary as an extension #492
  or start another one, what do you think?

Sounds good, #492 it is.

Agree!
@ALL: Please do not make comments on this issue anymore. We want to centralize all threads and we would invite you to make all your comments/suggestions/discussion/edits at :
#492

Thanks
Marc.