First draft of medicalEntity extension proposal #11

Closed
wants to merge 76 commits into
from

Projects

None yet
@twamarc
Contributor
twamarc commented May 8, 2014

Edit: please see #492 for 2015 status of this work, using the new http://schema.org/docs/extension.html mechanism.

Dear colleagues,
I am pleased to introduce to you this healthcare community effort initiated in June 2013, to extend the medicalEntity vocabulary of schema.org. This aims to enable the use of schema.org not only in indexing health records, web, healthcare documents but also as a pillar source of medical ontology/vocabulary for formalization of healthcare information, exchange and interoperability and use in HL7 standards, CCD/C-CDA elements based APIs.
The intention here is neither to have a comprehensive medical ontology nor to define or codify a new controlled medical vocabulary, but to provide a scalable, use-driven vocabulary schema, in-line with the schema.org philosophy. In this design, few granular classes will be created, the priority is given to use the vocabulary in clinical information models which use classes from existing vocabularies and terminology (SNOMED, ICD, LOINC, ATC, RxNorm,etc.) and all properties from schema.org as pillar source.
This approach have been tested and used within SALUS EU FP7 project and was successful. All tools and services produced in SALUS EU FP7 project are public and accessible.

Expected use:
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. This is the momentum for schema.org to contribute to the healthcare information, exchange and interoperability. The consumers and publishers will find this extension also interesting as they can now enlarge the amount of indexable content, and beyond that they can index not only information and meta-data but also the data itself.

Feel free to provide your feedback, suggestions and comments, to improve the proposal.

Regards
Marc Twagirumukiza, Agfa HealthCare N.V.
Belgium.

@dbs
Contributor
dbs commented May 8, 2014

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

@twamarc
Contributor
twamarc commented May 8, 2014

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/rvguha/schemaorg/pull/11#issuecomment-42600314
.

@danbri
Contributor
danbri commented May 9, 2014

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.

-> 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.

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.

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? In the previous medical/health additions we made the mistake of including terms whose name was implicitly contextualised to medical/health scenarios. So we 'used up' the word 'action' on a property that we now call http://schema.org/muscleAction and so on. We need to be very careful not to do this again - so every change needs to make sense cross domain, since schema.org is a cross domain vocabulary.

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?

@twamarc
Contributor
twamarc commented May 9, 2014

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.

twamarc added some commits May 9, 2014
@twamarc twamarc Series of updates: lower case change in property/classes label, elimi…
…nating duplicates, namespace/URI changes, retracting the properties biologicalFather/biologicalMother initial quick feedback from Dan & Dan
11b39dc
@twamarc twamarc Fixing xsd: URI issue 6151a42
@twamarc
twamarc commented on 6151a42 May 9, 2014

I have committed the final stable proposal here. Feel free to interact for any recommendation/suggestion/discussion or question.

@twamarc
Contributor
twamarc commented May 22, 2014

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 twamarc changed the title from Submitting the medicalEntity proposal with integration to the existing s... to Submitting the medicalEntity proposal May 22, 2014
@twamarc twamarc changed the title from Submitting the medicalEntity proposal to Submitting the medicalEntity extension proposal May 22, 2014
@danbri
Contributor
danbri commented May 23, 2014

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

@twamarc
Contributor
twamarc commented May 23, 2014

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)
@jvandriel

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.

@davefeg
davefeg commented May 23, 2014

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.

@danbri
Contributor
danbri commented Jun 2, 2014

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?

@twamarc
Contributor
twamarc commented Jun 3, 2014

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.

@jvandriel

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/

@danbri
Contributor
danbri commented Jun 5, 2014

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.

@twamarc
Contributor
twamarc commented Jun 6, 2014

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 ?

@danbri
Contributor
danbri commented Jun 6, 2014

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.

@danbri danbri changed the title from Submitting the medicalEntity extension proposal to VOCAB: Submitting the medicalEntity extension proposal Jun 13, 2014
@danbri
Contributor
danbri commented Jun 13, 2014

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

@twamarc
Contributor
twamarc commented Jun 14, 2014

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.

@twamarc

With this new commit, I merged with recent updates in schema.org, and replaced 'QualifierConcept' with 'MedicalEnumeration' and 'PhyisicalExamination' with 'PhysicalExam' to harmonize with already existing labels in schema.org.
The summary count of changes/additions: +2569 (additions) , -35 (changes/deletions).
I have provided a full human-readable file of the changes and additions on the Google discussion group (https://groups.google.com/forum/#!categories/schemed).

@twamarc
Contributor
twamarc commented Jul 4, 2014

@danbri
Can you help providing feedback about the further steps?

@twamarc
Contributor
twamarc commented Aug 1, 2014

This is the monthly maintenance activity report.
The following fixes were done:

  • Align with recent updates in schema.org : fetch/merge upstream
  • Adding as range schema:Place in birthPlace predicate.
  • Re-commit the properties :drugPackage, medicalSpecimen, specimenDonor, specimenReceiver
  • Superfluous white spaces and indent removal
@danbri
Contributor
danbri commented Aug 5, 2014

twamarc, a while back you wrote "I will prepare this human-oriented overview of the main changes in a separate file and post it soon." - did you ever post such a document?

Also you mentioned "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." .... could you post a version to public appspot.com via AppEngine, so that the rest of us can take a look?

It is a very large proposal to understand without this kind of help!

@twamarc
Contributor
twamarc commented Aug 5, 2014

Yes, the diff file was circulated (message of 19 june above), I shared a link to google group. Can you try to access it? It's a attachment there.
https://groups.google.com/forum/#!category-topic/schemed/ZbeYCdHo6cY
If needed I can put it here in comment (but it's quite long--I will see the best way then).

A version to public appspot.com via AppEngine: Sure I can prepare it. I circulate the pointer once ready.

@danbri
Contributor
danbri commented Aug 5, 2014

Thanks re public appspot.

I saw schemaDiff.rdfa (and we can see similar in Github), however that's not what I thought you were working on.

I asked "Do you have a human-oriented overview of the main changes in this proposal? How many are fixes versus additions, etc.?", to which you responded "I will prepare this human-oriented overview of the main changes in a separate file and post it soon."

I guess we have different sense of what counts as "human oriented" :) I was looking more for paragraphs of English text giving a high level description of how the new schema differs. For example, what new areas it adds vocabulary for, what mistakes it fixes, if any, etc.

In general I should say we are a bit wary/concerned about the scale of changes / detail this proposal asks for, but I think it is useful working through the options for how/where such a detailed schema might live, since it does seem useful to take schema.org as a base for detailed efforts like this.

@twamarc
Contributor
twamarc commented Aug 5, 2014

Thanks for clarification. Actually the file I circulated it's mainly for developers, now I see what you mean, sorry :). I had another understanding of "human-oriented overview". I will post this text giving a high level description of how the new schema differs.
In parallel I will send some suggestions to update the 'Documentation for health/medical types' published here: http://schema.org/docs/meddocs.html.

I was now working on the version to public appspot.com via AppEngine, and I have the demo here: http://demoschemed.appspot.com/MedicalEntity
Can you have a look and give me a feedback? (It seems the search function is not working, I will investigate this later on).

@twamarc
Contributor
twamarc commented Aug 6, 2014

We are running the tests (run_tests.py) on the patch proposal and every thing is OK except the "test_finalExampleParsers (test_basics.SDOBasicsTestCase) ... expected failure".
Do we need to investigate this?

@danbri
Contributor
danbri commented Aug 6, 2014

That's fine - ignore
On 6 Aug 2014 10:25, "Marc" notifications@github.com wrote:

We are running the tests (run_tests.py) on the patch proposal and every
thing is OK except the "test_finalExampleParsers
(test_basics.SDOBasicsTestCase) ... expected failure".
Do we need to investigate this?


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

@twamarc
Contributor
twamarc commented Aug 8, 2014

The human-readable changeLog file reflecting at high-level the difference between existing schema.org/medicalEntity vocabulary and the proposed patch is available.
As this changeLog file is now circulated, I suggest to freeze all future changes suggestions (except from schema.org) from now onwards, to keep the submission not changed (processable) until the final feedback from schema.org team.
However, comments and suggestions are still welcome, they will be gathered for ultimate discussion and process.
Attached: https://groups.google.com/d/msgid/schemed/524bdbde-8e07-4bae-bd5e-69546c646a9a%40googlegroups.com.
-changeLog file (human-readble version)
-suggestions for 'Documentation for health/medical types'.

@danbri danbri added the needs review label Sep 12, 2014
@twamarc
Contributor
twamarc commented Sep 12, 2014

Good, noticed. Just a clarification: Do we need external review (who/how) or it's an internal review at schema.org?. Just to know if any kind of job is needed to be done there from our side. please let us know.

@danbri
Contributor
danbri commented Sep 12, 2014

It's more with us. While this is obviously an interesting and important topic, we are wary of such a substantial addition and need to give it some careful thought. Let's check back here in 1 month.

BTW https://groups.google.com/d/msgid/schemed/524bdbde-8e07-4bae-bd5e-69546c646a9a%40googlegroups.com is only visible to members of your mailing list. Would you consider publishing it somewhere public? e.g. copy into the Wiki here?

@twamarc
Contributor
twamarc commented Sep 12, 2014

Thanks.
For general public (thanks to point this out): I made accessible version of the two files: the human-readable changeLog file reflecting at high-level the difference between existing schema.org/medicalEntity vocabulary and the proposed patch + the update of 'Documentation for health/medical types' (already published here: http://schema.org/docs/meddocs.html).

Please find those 2 files here: https://drive.google.com/folderview?id=0B3XqWCPGZuTeTGc2ZlVxRXZhYWM&usp=sharing and report to me for any -whatever, comment/suggestions.

@ghost
ghost commented Sep 13, 2014

+1 Thanks Dan. Thanks Marc. This is a good progress.

@davefeg
davefeg commented Sep 13, 2014

+1 Needs also to fetch/merge upstream with recent updates in schema.org (at a very last stage). Good progress. Thanks Dan, James, Marc et al.

@danbri danbri self-assigned this Jan 22, 2015
@danbri danbri referenced this pull request Jan 26, 2015
Closed

Extension Mechanism #284

vholland added some commits May 14, 2015
@vholland vholland Merge pull request #339 from unor/unor-patch-2
Fixed "VideoGame" example + minor formatting
6d3ad8c
@vholland vholland Merge pull request #357 from unor/unor-patch-4
Invalid HTML in 'Question' example
37ebff3
@vholland vholland Merge pull request #435 from dschulten/sdo-gozer
Fixed json on "Top 5 covers of Bob Dylan Songs"
36aac16
@vholland vholland Merge pull request #438 from unor/fix-itemlist-example
Fixed ItemList examples
0da42f0
@danbri
Contributor
danbri commented May 15, 2015

@twamarc and others -

(to recap)
The Medical/health vocabulary is one we have long struggled with at schema.org. It is a hugely important topic, but also very detailed and technical. Our original vocabulary was poorly integrated, using many generic terms in med-specific ways. We were even considering removing it when this proposal arrived last year. Meanwhile, we have also been working on an improved mechanism for extending schema.org which partially decentralizes the creation of schemas, while keeping them integrated within a flat namespace. Yesterday's update to schema.org v2.0 included a revision to the extensions page, presenting that idea: http://schema.org/docs/extension.html

We now anticipate handling some bibliographic and automobile terminology as extensions. Each of these is supported by a W3C Community Group, and would show up as e.g. bib.schema.org, auto.schema.org. Within markup the prefixes could be omitted when needed in syntax (e.g. Microdata) or used for clarity (in JSON-LD).

What do you think about this route as a way forward for medical/health schemas at schema.org?

Apologies for the long time it has taken us to respond to your hard work here. I look forward to getting things moving again...

@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. Let's move ongoing discussion into the #492 issue.

@danbri danbri changed the title from VOCAB: Submitting the medicalEntity extension proposal to First draft of medicalEntity extension proposal May 19, 2015
@ghost
ghost commented May 19, 2015

Fully support!

On 15 May 2015 at 14:36, Dan Brickley notifications@github.com wrote:

@twamarc https://github.com/twamarc and others -

(to recap)
The Medical/health vocabulary is one we have long struggled with at
schema.org. It is a hugely important topic, but also very detailed and
technical. Our original vocabulary was poorly integrated, using many
generic terms in med-specific ways. We were even considering removing it
when this proposal arrived last year. Meanwhile, we have also been working
on an improved mechanism for extending schema.org which partially
decentralizes the creation of schemas, while keeping them integrated within
a flat namespace. Yesterday's update to schema.org v2.0 included a
revision to the extensions page, presenting that idea:
http://schema.org/docs/extension.html

We now anticipate handling some bibliographic and automobile terminology
as extensions. Each of these is supported by a W3C Community Group, and
would show up as e.g. bib.schema.org, auto.schema.org. Within markup the
prefixes could be omitted when needed in syntax (e.g. Microdata) or used
for clarity (in JSON-LD).

What do you think about this route as a way forward for medical/health
schemas at schema.org?

Apologies for the long time it has taken us to respond to your hard work
here. I look forward to getting things moving again...


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

@hschema hschema referenced this pull request in healthschema/healthschema.github.io Aug 19, 2015
Closed

.. #7

@danbri danbri pushed a commit that referenced this pull request Mar 24, 2016
Dan Brickley Fixed various issues w.r.t. merging #11 via #1056 into sdo-deimos.
Merge branch 'master' of https://github.com/twamarc/schemaorg into twamarc-master
e018d10
@danbri
Contributor
danbri commented Mar 24, 2016

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

@Dataliberate
Contributor

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.

@danbri
Contributor
danbri commented Mar 24, 2016

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)

@twamarc
Contributor
twamarc commented Mar 25, 2016

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

@egonw
egonw commented Mar 25, 2016

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.

@danbri
Contributor
danbri commented Mar 25, 2016

@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.

@danbri
Contributor
danbri commented Mar 25, 2016

@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.

@danbri
Contributor
danbri commented Mar 25, 2016

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

@danbri danbri closed this Mar 25, 2016
@twamarc
Contributor
twamarc commented Mar 26, 2016

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

  • #492
    or start another one, what do you think?
@danbri
Contributor
danbri commented Mar 26, 2016

Sounds good, #492 it is.

@danbri danbri reopened this Mar 26, 2016
@danbri danbri closed this Mar 26, 2016
@twamarc
Contributor
twamarc commented Mar 26, 2016

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.

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