search

twamarc / ScheMed

Healthcare Schema Vocabulary
12 stars 8 forks source link

Technical work of revisiting the draft and re-structuring it #2

Closed twamarc closed 8 years ago

twamarc commented 9 years ago

While we are preparing the health.schema.org extension, we need to revisit and restructure the initial submitted draft. A couple of predicates/classes have been already added in schema.org; and we need to list some predicates which will be moved to extension from core and vice versa. The current RDFa file: https://github.com/twamarc/ScheMed/blob/master/medicalEntity.rdfa

On the TO DO list we have also to document the following: -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).

davefeg commented 9 years ago

Sorry I will not be able to contribute here! I think you are in best position to deal with that @twamarc! This holds for other maintenance task, although you can delegate (of course).

My 2 cents again!

ghost commented 9 years ago

any progress there?

twamarc commented 9 years ago

Hi everyone,

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

We finished the initial job of restructuring and we have generated up-to-date rdfa files both for -health.schema.org extension ONLY see: https://github.com/twamarc/ScheMed/HealthSchemaOrg/health_schema_org_new.rdfa -current version of schema.rdfa integrating health.schema.org extension. see: (https://github.com/twamarc/schemaorg/data/schema.rdfa)

We performed schema.org tests (scripts/run_tests.py) on the latter and they are successful. Thanks to Jos De Roo (@josd ) for his help there.

The final remaining steps/tasks are:

1-To deploy on the GAE the files (schemed/HealthSchemaOrg/health_schema_org_new.rdfa & scheamaorg/data/schema.rdfa) under 'sdo-schemed.appspot.com' and 'sdo-health-schema-org.appspot.com' or other names. (for this we need to create a public google account---accessible by some people -or any other suggestion?)

2-To use the inserted subClassOf CreatedInExtension/MaintainedInCore/MovedFromCore to list all terms below each category (needed for extension rationale)

3-To take the 2 rdfa files and drop (remove) all inserted subClassOf used for classifications above: "Subclass of: CreatedInExtension" "Subclass of: MaintainedInCore" "Subclass of: MovedFromCore"

4-To re-deploy the final cleaned files for final review 5-Make a pull request to schema.org

@danbri: something forgotten here towards pull request?

Q: Can someone provide a help there by taking over one or multiple of those tasks?

Kind Regards,

Marc

danbri commented 9 years ago

Thanks - you've been busy! :)

/cc @RichardWallis who is working on the extensions implementation

The latest implementation mechanism for extensions uses assertions such as "isPartOf http://health.schema.org/" to indicate whether something is considered to be in an extension. You can see this in the sdo-ganymede branch, and in test sites currently at http://sdo-ganymede.appspot.com and http://webschemas.org/

I'll arrange the DNS for webschemas.org (an 'upstream' unstable testing site) to have 'health' as a subdomain, for testing this. I suggest you may want to add isPartOf triples for "CreatedInExtension' and "MovedFromCore' terms. There are new unit tests to make sure each declared term has a 'home' either in Core or an extension.

twamarc commented 9 years ago

Great! I will add isPartOf triples for "CreatedInExtension' and "MovedFromCore' terms. Thx

RichardWallis commented 9 years ago

Hi Marc,

Ping me on G+ or email if I can help.

Few pointers as a start (excuse if you already know this)

Any questions / issues just yell.

~Richard

On Wed, Jul 29, 2015 at 2:52 PM, Marc notifications@github.com wrote:

Great! I will add isPartOf triples for "CreatedInExtension' and "MovedFromCore' terms. Thx

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-125959381.

twamarc commented 9 years ago

Thanks Richard, indeed I need some technical help --will mail you soon for details.

twamarc commented 9 years ago

Hi @RichardWallis , @danbri , @josd We have now finished the all cleaning work and made some examples. Locally here, the tests are OK.

We expect additional discussions with the Healthcare Schema Vocabulary Community Group - normally to take place next week, before we release a final copy (no big changes expected). But this pre-final release is ready to be tested at your end. Can you check out these, test in your environment and provide us a feedback? https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa and: https://github.com/twamarc/schemaorg/tree/master/data/ext/health

In next steps the extension will accommodate the input from #6 and #3 (/cc @ccorak @DavidXPortnoy @markwoon) . Currently we moved all medical related vocabs and Recipe #5 to the extension (--inventory to be shared soon) but next discussions will deal with some other particular terms.

Marc

RichardWallis commented 9 years ago

Hi Marc,

I'll pull this locally and produce a test health.schema.org to take a look.

~Richard

On 18 Aug 2015, at 08:33, Marc notifications@github.com wrote:

Hi @RichardWallis , @danbri , @josd We have now finished the all cleaning work and made some examples. Locally here, the tests are OK.

We expect additional discussions with the Healthcare Schema Vocabulary Community Group - normally to take place next week, before we release a final copy (no big changes expected). But this pre-final release is ready to be tested at your end. Can you check out these, test in your environment and provide us a feedback? https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa and: https://github.com/twamarc/schemaorg/tree/master/data/ext/health

In next steps the extension will accommodate the input from #6 and #3 (/cc @ccorak @DavidXPortnoy @markwoon) . Currently we moved all medical related vocabs and Recipe #5 to the extension but next discussions will deal with some other particular terms.

Marc

— Reply to this email directly or view it on GitHub.

twamarc commented 9 years ago

Good!

Thanks

Marc

Sincerely yours

Sent from my iPad Device On 18 Aug 2015 18:47, "RichardWallis" notifications@github.com wrote:

Hi Marc,

I'll pull this locally and produce a test health.schema.org to take a look.

~Richard

On 18 Aug 2015, at 08:33, Marc notifications@github.com wrote:

Hi @RichardWallis , @danbri , @josd We have now finished the all cleaning work and made some examples. Locally here, the tests are OK.

We expect additional discussions with the Healthcare Schema Vocabulary Community Group - normally to take place next week, before we release a final copy (no big changes expected). But this pre-final release is ready to be tested at your end. Can you check out these, test in your environment and provide us a feedback? https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa and: https://github.com/twamarc/schemaorg/tree/master/data/ext/health

In next steps the extension will accommodate the input from #6 and #3 (/cc @ccorak @DavidXPortnoy @markwoon) . Currently we moved all medical related vocabs and Recipe #5 to the extension but next discussions will deal with some other particular terms.

Marc

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-132272326.

RichardWallis commented 9 years ago

Marc,

Which version of schema.rdfa did you start with - 2.0 or 2.1?

~Richard

On 18 Aug 2015, at 08:33, Marc notifications@github.com wrote:

Hi @RichardWallis , @danbri , @josd We have now finished the all cleaning work and made some examples. Locally here, the tests are OK.

We expect additional discussions with the Healthcare Schema Vocabulary Community Group - normally to take place next week, before we release a final copy (no big changes expected). But this pre-final release is ready to be tested at your end. Can you check out these, test in your environment and provide us a feedback? https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa and: https://github.com/twamarc/schemaorg/tree/master/data/ext/health

In next steps the extension will accommodate the input from #6 and #3 (/cc @ccorak @DavidXPortnoy @markwoon) . Currently we moved all medical related vocabs and Recipe #5 to the extension but next discussions will deal with some other particular terms.

Marc

— Reply to this email directly or view it on GitHub.

ghost commented 9 years ago

2.1 I was confused when I started fetch upstream. I did a merging with sdo-phobos. Afterwards I saw there are differences with the published version and I merged with sdo-ganymede (I think is the one called 2.1). Let me know if am not confusing the two.

twamarc commented 9 years ago

@jamrob the sdo-ganymede is the 2.1

twamarc commented 9 years ago

@RichardWallis I see the used version is sdo-ganymede buy I see some work inside from sdo-phobos. Let me know if I have to re-do the fetch/merge upstream with sdo-ganymede.

the files in extensions will not change it would be only to check the file https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa

RichardWallis commented 9 years ago

Few points after a quick scan:

Firstly 'AdmissionProcedure': Although defined as in the range of medicalAdmission it is itself not defined anywhere.

Secondly the attached image highlights a few other things:

​

Thats all for now...

~Richard.

On Tue, Aug 18, 2015 at 6:19 PM, Marc notifications@github.com wrote:

@RichardWallis https://github.com/RichardWallis I see the used version is sdo-ganymede buy I see some work inside from sdo-phobos. Let me know if I have to re-do the fetch/merge upstream with sdo-ganymede.

the files in extensions will not change it would be only to check the file https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-132285258.

twamarc commented 9 years ago

Thanks @RichardWallis for a quick feedback. -'AdmissionProcedure' is now defined

-additionally picked some obvious fixes in line with https://github.com/schemaorg/schemaorg/issues/417 (cc/ @vholland)

-Nice to have those extra error checkers (+1). Can you also add an extra constraint that domain can't be schema:text ? (don't know if it's mattering but I crossed one case once while drafting) I have committed the new updated files.

~ Marc

danbri commented 9 years ago

Great to see this moving along!

danbri commented 9 years ago

On the equivalence mappings aspect, we have a few external mappings in the system. AFAIK currently not exploited in the UI although we could do so trivially (e.g. in the 'more...' section). I believe we expose these mappings in per-term pages RDFa/RDFS markup.

rdfa data/schema.rdfa   | grep '#equiv' 

<http://schema.org/DataDownload> <http://www.w3.org/2002/07/owl#equivalentClass> <http://www.w3.org/ns/dcat#Distribution> .
<http://schema.org/Dataset> <http://www.w3.org/2002/07/owl#equivalentClass> <http://www.w3.org/ns/dcat#Dataset> .
<http://schema.org/Dataset> <http://www.w3.org/2002/07/owl#equivalentClass> <http://purl.org/dc/dcmitype/Dataset> .
<http://schema.org/Periodical> <http://www.w3.org/2002/07/owl#equivalentClass> <http://purl.org/ontology/bibo/Periodical> .
<http://schema.org/volumeNumber> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/volume> .
<http://schema.org/ImageObject> <http://www.w3.org/2002/07/owl#equivalentClass> <http://purl.org/dc/dcmitype/Image> .
<http://schema.org/pageStart> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/pageStart> .
<http://schema.org/PublicationIssue> <http://www.w3.org/2002/07/owl#equivalentClass> <http://purl.org/ontology/bibo/Issue> .
<http://schema.org/DataCatalog> <http://www.w3.org/2002/07/owl#equivalentClass> <http://www.w3.org/ns/dcat#Catalog> .
<http://schema.org/pageEnd> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/pageEnd> .
<http://schema.org/description> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/dc/terms/description> .
<http://schema.org/Event> <http://www.w3.org/2002/07/owl#equivalentClass> <http://purl.org/dc/dcmitype/Event> .
<http://schema.org/recordLabel> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/mo/label> .
<http://schema.org/pagination> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/pages> .
<http://schema.org/isbn> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/isbn> .
<http://schema.org/Dataset> <http://www.w3.org/2002/07/owl#equivalentClass> <http://rdfs.org/ns/void#Dataset> .
<http://schema.org/issn> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/issn> .
<http://schema.org/Person> <http://www.w3.org/2002/07/owl#equivalentClass> <http://xmlns.com/foaf/0.1/Person> .
<http://schema.org/issueNumber> <http://www.w3.org/2002/07/owl#equivalentProperty> <http://purl.org/ontology/bibo/issue> .

RDFa

In per-term properties we have e.g.

<div id="mainContent" vocab="http://schema.org/" typeof="rdfs:Property" 
resource="http://schema.org/issueNumber">
  <link property="owl:equivalentProperty" href="http://purl.org/ontology/bibo/issue"/>

In per-term type pages we have:

<div id="mainContent" vocab="http://schema.org/" typeof="rdfs:Class" 
resource="http://schema.org/Dataset">
  <link property="owl:equivalentClass" href="http://www.w3.org/ns/dcat#Dataset"/>
<link property="owl:equivalentClass" href="http://rdfs.org/ns/void#Dataset"/>
<link property="owl:equivalentClass" href="http://purl.org/dc/dcmitype/Dataset"/>

I presume we should be able to handle SNOMED similarly for small numbers of terms. For large external vocabularies we sometimes use the idiom that their expected type is "URL".

mgh128 commented 9 years ago

Within GS1 we are developing a web vocabulary for describing product information in greater detail. Among other things, our current draft vocabulary includes properties for nutritional information for food and beverage products and also includes a nutrient basis unit property, to explicitly indicate whether the values are per 100g / 100ml of product or relative to some other quantity (e.g. a serving size or pack size of a particular weight). The nutritional properties currently include the following:

gs1:biotinPerNutrientBasis gs1:calciumPerNutrientBasis gs1:carbohydratesPerNutrientBasis gs1:chloridePerNutrientBasis gs1:chromiumPerNutrientBasis gs1:copperPerNutrientBasis gs1:energyPerNutrientBasis gs1:fatPerNutrientBasis gs1:fibrePerNutrientBasis gs1:fluoridePerNutrientBasis gs1:folicAcidPerNutrientBasis gs1:iodinePerNutrientBasis gs1:ironPerNutrientBasis gs1:magnesiumPerNutrientBasis gs1:manganesePerNutrientBasis gs1:molybdenumPerNutrientBasis gs1:monounsaturatedFatPerNutrientBasis gs1:niacinPerNutrientBasis gs1:pantothenicAcidPerNutrientBasis gs1:phosphorusPerNutrientBasis gs1:polyolsPerNutrientBasis gs1:polyunsaturatedFatPerNutrientBasis gs1:potassiumPerNutrientBasis gs1:proteinPerNutrientBasis gs1:riboflavinPerNutrientBasis gs1:saltPerNutrientBasis gs1:saturatedFatPerNutrientBasis gs1:seleniumPerNutrientBasis gs1:sodiumPerNutrientBasis gs1:starchPerNutrientBasis gs1:sugarsPerNutrientBasis gs1:thiaminPerNutrientBasis gs1:vitaminAPerNutrientBasis gs1:vitaminB12PerNutrientBasis gs1:vitaminB6PerNutrientBasis gs1:vitaminCPerNutrientBasis gs1:vitaminDPerNutrientBasis gs1:vitaminEPerNutrientBasis gs1:vitaminKPerNutrientBasis gs1:zincPerNutrientBasis

Each of these can enable a manufacturer to express an amount of a particular nutrient relative to the specified nutrient basis quantity, as well as the percentage recommended daily intake value that this represents for the specified nutrient basis quantity, taking into account recommended daily intake amounts for the intended target market of the product.

twamarc commented 9 years ago

@danbri Sure! It will be possible to make those mappings-, we have only classes no properties- I populated so far 56 unique Classes. The challenge: This will suppose to have 'always' an internal Class in schema.org. Doing this it's not a problem itself, normally we were directly using the SNOMED concept URI as a range/domain without creating the equivalent class in schema.org. The philosophy behind at the beginning was to avoid recreating already existing classes in HL7 or ICD or SNOMED. Advice? Less difficult but challenging will be also who to use the SNOMED concept as range/domain. As they will be mapped already, isn't more cleaner to use just one (the schema.org internal one--I guess) and skip the equivalent?

mgh128 commented 9 years ago

We took this approach because:

(1) we are trying to ensure that anyone using the GS1 web vocabulary can do so intuitively, minimising the need to be familiar with other code lists. Of course we can link the property within our GS1 vocabulary to the corresponding concept URIs in SNOMED, HL7 or ICD. That is certainly worth doing. However, rather than having a generic property for all nutrients, we felt it was more straightforward to define one property per nutrient for the major nutrients.

(2) the properties defined within http://schema.org/NutritionInformation are not sufficiently comprehensive for most nutritional properties that appear on food / beverage labels. We did refer to EU 1169/2011 food labelling legislation, to ensure that we supported the main nutrient information properties that are required to be stated for food/beverage products purchased online.

(3) the properties within http://schema.org/NutritionInformation are really intended for use with a http://schema.org/Recipe and are not ideally suited for use with a http://schema.org/Product because of the ambiguity over the nutrient basis quantity. Because different regions of the world require / permit different nutrient basis quantities (e.g. per 100g / 100ml throughout the EU, versus per serving in the USA), we decided to introduce an explicit property gs1:nutrientBasisQuantity that would enable a manufacturer or brand owner to state whether the nutritional value is per 100g / 100ml or per 1 oz serving etc., leaving no ambiguity about whether they were expressed per 100g / per serving / per pack etc.

In our GS1 web vocabulary, we have not created a large number of additional classes for nutritional information - instead we define one property per nutrient.
The rdfs:range of the nutrient properties I listed previously (e.g. gs1:zincPerNutrientBasis ) is a gs1:NutritionMeasurementType which is an rdfs:subClassOf gs1:QuantitativeValue (which in turn is an rdfs:subClassOf schema:QuantitativeValue). gs1:NutritionMeasurementType is the rdfs:domain for gs1:dailyValueIntakePercent , which expects an xsd:float as its rdfs:range.

We have recently been making changes to our GS1 web vocabulary to more closely align with schema.org as a potential extension - and have been having some conversations with Dan Brickley to keep him updated of these efforts. He recommended that we get in touch with you to see where we can align efforts regarding provision of detailed nutritional information for food/beverage products.

RichardWallis commented 9 years ago

Apart from how to handle the SNOMED concept URI, things are now looking good for the extension. I haven't done a property by property, type by type, review of what is in there, but my simple error checking is not complaining anymore.

So, once that issue is resolved I thing we could go to adding it into a ship of some sort. The question then is how/when to do that.

We could do it as part of sdo-phobos, or we could do it out of band from the core release sequence. There is a minor code change to 'enable' the health extension plus small fix required to do that - both safe enough to apply directly to the master branch.

Currently all extensions (auto, bib, health) are described as: (This is an initial exploratory release.). Obviously over time we will end up with extensions in various states - released, exploratory release, released with proposed new/changed terms, etc. - I have raised an issue (#742 https://github.com/schemaorg/schemaorg/issues/742) to address how we can represent these in the associated .rdfa files and reflect in display.

On Wed, Aug 19, 2015 at 4:35 PM, Marc notifications@github.com wrote:

Sure! It will be possible to make those mappings-, we have only classes no properties- I populated so far 56 unique Classes. The challenge: This will suppose to have 'always' an internal Class in schema.org. Doing this it's not a problem itself, but what are your thoughts? Normally we were directly using the SNOMED concept URI as a range/domain without creating the equivalent class in schema.org. The philosophy behind at the beginning was to avoid recreating already existing classes in HL7 or ICD or SNOMED. Less difficult but challenging will be also who to use the SNOMED concept as range/domain. As they will be mapped already, isn't more cleaner to use just one (the schema.org internal one--I guess) and skip the equivalent?

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-132640734.

twamarc commented 9 years ago

@RichardWallis

Nice to hear that things are now looking good for the extension--except the pending issue of how to handle the SNOMED concept URIs. I wait for @danbri input here (maybe others as well) then I will know how to proceed. +1 for #742

mgh128 commented 9 years ago

I should also say that in addition to defining properties for nutritional information, we also define a class, gs1:AllergenType with several enumerated instances to cover the following allergens:

Almond and Almond Products, Alpha-Isomethyl Ionone, Amylcinnamyl Alcohol, Amyl Cinnamal, Anise Alcohol, Barley and Barley Products, Benzyl Alcohol, Benzyl Benzoate, Benzyl Cinnamate., Benzyl Salicylate, Brazil Nut and Brazil Nut Products, Butylphenyl Methylpropionate., Carrot and Derivatives, Cashew and Cashew Products, Celery or Derivatives, Cereals Containing Gluten and Their Derivatives, Cinnamal, Cinnamyl Alcohol, Citral, Citronellol, Cocoa and Derivatives, Coriander Derivatives, Corn and Derivatives, Coumarin, Crustaceans and Their Derivatives, Eggs and Their Derivatives, Eugenol, Evernia Furfuracea, Evernia Prunastri, Farnesol, Fish and Their Derivatives, Geraniol, Gluten, Hazelnut and Hazelnut Products, Hexyl Cinnamal, Hydroxycitronellal, Hydroxyisohexyl 3-Cyclohexene Carboxaldehyde Isoeugenol Limonene Linal, Kamut and Kamut Products, Lactose, Lupine and Derivatives, Macadamia Nut and Macadamia Nut Products, Methyl 2-Octynoate, Milk and Derivatives, Molluscs and Their Derivatives, Mustard and Derivatives , Oat and Oat Products, Peanuts and Their Derivatives, Peas and Pea Products, Pecan Nut and Pecan Nut Products, Pistachio and Pistachio Products, Pod Fruits Derivatives, Queensland Nut and Queensland Nut Products, Rye and Derivatives, Sesame Seeds or Their Derivatives, Soybeans and Their Derivatives, Spelt and Spelt Products, Sulphur Dioxide and Sulphites, Tree Nuts and Their Derivatives, Traces of Tree Nuts, Walnut and Walnut Products, Wheat and Their Derivatives

We also define a class gs1:NutritionalClaimTypeCode with instances to indicate declared nutritional claims including:

"Additive Free", "Artificially Sweetened", "Cholesterol Free", "Colouring Agent Free", "Contains Glyzyrrhizin", "Contains Liquorice", "Contains Soy", "Egg Free", "Energy Free", "Energy Reduced", "Enriched or Fortified in Vitamins Minerals", "Fat Free", "Free From Gluten", "Guarantee Lactose Free", "High Fibre", "High Protein", "High in Vitamins Minerals", "Lactose Free", "Light or Lite", "Low Energy", "Low Protein", "Low in Fat", "Low in Lactose", "Low in Saturated Fat", "Low in Sodium", "Low in sugars", "Milk Free", "Milk Protein Free", "Natural Source of Vitamins Minerals", "No Added Sugar", "Non-alcoholic", "Nut Free", "Peanut Free", "Preservative Free", "Saturated Fat Free", "Sodium of Salt Free", "Source of Fibre", "Source of Protein", "Soy Free", "Strongly Salted", "Sugar Free", "Sweetened With Agave Syrup", "Sweetened With Came Sugar", "Sweetened With Corn Syrup", "Sweetened With Fructose", "Sweetened With Fruit Juice", "Sweetened With Fruit Syrup", "Sweetened With Honey", "Sweetened With Malt", "Sweetened With Raw Beet Sugar", "Sweetened With White Sugar", "Very Low Gluten", "Very Low in Sodium Salt", "Wheat Free"

We also define a gs1:DietTypeCode with instances to represent the following:

"Coeliac","Dietetic","Free From Gluten","Halal","Kosher","Organic","Vegan","Vegetarian","Without Beef","Without Pork"

We have further properties to enable manufacturers and brand owners to specify which independent accreditation organisation verified the claims for products (whether dietary / health, ethical or environmental)

danbri commented 9 years ago

/cc @rvguha fyi

twamarc commented 9 years ago

Hi @RichardWallis, I have now fixed the SNOMED concept URIs issues. All SNOMED concept URIs are mapped using the approach ( Thanks @danbri ) : "link property="owl:equivalentClass" href="http://purl.bioontology.org/ontology/SNOMEDCT/ID"/"

I tested locally, it's OK . Can you check at your side?

At the same time I complied all info about global overview of the vocabulary (terms inventory) and the file is accessible in GitHub as well: https://github.com/twamarc/ScheMed/blob/master/documents/overview_vocab.doc @danbri : Can you have a look and revert to me for any feedback? @jamrob @hugle and others: Thanks for your inputs.

Hope to talk with you all tomorrow. Marc

RichardWallis commented 8 years ago

The RDFa descriptions are now looking good enough to add to the schemaorg source ready for a ship.

There are a few problems with the examples - naming of, and labeling within, the files. Also there is some Turtle code in there which is currently not supported.

Lets talk through with @danbri when and which branch we use for this, and if we can fix these few problems on the way in or do we get them fixed in SchemaMed first. Also we need to discuss wording on the health equivalent of current other extension home pages eg. auto.schema.org/

Hoping to attend tomorrow, so maybe we can discuss some of this then.

~Richard

On Thu, Aug 27, 2015 at 4:30 PM, Marc notifications@github.com wrote:

Hi @RichardWallis https://github.com/RichardWallis, I have now fixed the SNOMED concept URIs issues. All SNOMED concept URIs are mapped using the approach:

( Thanks @danbri https://github.com/danbri ) . I tested locally, it's OK . Can you check at your side?

At the same time I complied all info about global overview of the vocabulary (terms inventory) and the file is accessible in GitHub as well: https://github.com/twamarc/ScheMed/blob/master/documents/overview_vocab.doc @danbri https://github.com/danbri : Can you have a look and revert to me for any feedback? @jamrob https://github.com/jamrob @hugle https://github.com/hugle and others: Thanks for your inputs.

Hope to talk with you all tomorrow. Marc

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-135469811.

rvguha commented 8 years ago

Marc,

Can you post a summary of the changes you are proposing, so that we can get a discussion started?

guha

On Thu, Aug 27, 2015 at 4:22 PM, RichardWallis notifications@github.com wrote:

The RDFa descriptions are now looking good enough to add to the schemaorg source ready for a ship.

There are a few problems with the examples - naming of, and labeling within, the files. Also there is some Turtle code in there which is currently not supported.

Lets talk through with @danbri when and which branch we use for this, and if we can fix these few problems on the way in or do we get them fixed in SchemaMed first. Also we need to discuss wording on the health equivalent of current other extension home pages eg. auto.schema.org/

Hoping to attend tomorrow, so maybe we can discuss some of this then.

~Richard

On Thu, Aug 27, 2015 at 4:30 PM, Marc notifications@github.com wrote:

Hi @RichardWallis https://github.com/RichardWallis, I have now fixed the SNOMED concept URIs issues. All SNOMED concept URIs are mapped using the approach:

( Thanks @danbri https://github.com/danbri ) . I tested locally, it's OK . Can you check at your side?

At the same time I complied all info about global overview of the vocabulary (terms inventory) and the file is accessible in GitHub as well:

https://github.com/twamarc/ScheMed/blob/master/documents/overview_vocab.doc @danbri https://github.com/danbri : Can you have a look and revert to me for any feedback? @jamrob https://github.com/jamrob @hugle https://github.com/hugle and others: Thanks for your inputs.

Hope to talk with you all tomorrow. Marc

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-135469811.

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-135581595.

twamarc commented 8 years ago

@rvguha : Can this quoted before file be enough? It shows a global overview of the vocabulary (terms inventory) + summary of changes (terms moved from the core to the extension, terms created in the extension, terms to be discussed, etc.) in GitHub: https://github.com/twamarc/ScheMed/blob/master/documents/overview_vocab.doc

in Google docs: https://drive.google.com/file/d/0B3XqWCPGZuTeRkRBelJxOVJEcWc/view

It's a little bit big to post it here, let me know if it is what you expected

@RichardWallis / Nice to hear that it's OK at your side as well. Now the content review and extension track can start within a wide community. About the examples, the tutle part can be skipped (let me know in due time--when this is needed)

Marc

RichardWallis commented 8 years ago

Marc,

Take a look at: http://health.sdo-schemedex.appspot.com/Diagnosis

Examples changes not in this version

~Richard

On Fri, Aug 28, 2015 at 9:16 AM, Marc notifications@github.com wrote:

@rvguha https://github.com/rvguha : Can this quoted before file be enough? It shows a global overview of the vocabulary (terms inventory) + summary of changes (terms moved from the core to the extension, terms created in the extension, terms to be discussed, etc.) in GitHub: https://github.com/twamarc/ScheMed/blob/master/documents/overview_vocab.doc

in Google docs: https://drive.google.com/file/d/0B3XqWCPGZuTeRkRBelJxOVJEcWc/view

It's a little bit big to post it here, let me know if it is what you expected

@RichardWallis https://github.com/RichardWallis / Nice to hear that it's OK at your side as well. Now the content review and extension track can start within a wide community. About the examples, the tutle part can be skipped (let me know in due time--when this is needed)

Marc

— Reply to this email directly or view it on GitHub https://github.com/twamarc/ScheMed/issues/2#issuecomment-135668811.

twamarc commented 8 years ago

Hi Richard, This looks nice. Can we use this as work document for our discussions in coming meeting? BTW: I saw a confusion in coming Webex meeting I said 11.am Boston time ( 4.00pm GMT) I meant 4.00 UK Time (at GMT it will be at 3.00pm I think). Is Ok you will be available to attend? Am sending out this precision to our colleagues in Europe as well

Thx Marc

RichardWallis commented 8 years ago

Yes you can use.

I'll be there!

~Richard

On 28 Aug 2015, at 13:19, Marc notifications@github.com wrote:

Hi Richard, This looks nice. Can we use this as work document for our discussions in coming meeting? BTW: I saw a confusion in coming Webex meeting I said 11.am Boston time ( 4.00pm GMT) I meant 4.00 UK Time (at GMT it will be at 3.00pm I think). Is Ok you will be available to attend? Am sending out this precision to our colleagues in Europe as well

Thx Marc

— Reply to this email directly or view it on GitHub.

danbri commented 8 years ago

@twamarc the overview document is useful, but we should also have some high level overview of the (scope, purpose, coverage etc.) for the many new terms added in the extension. This looks like the best summary so far: https://drive.google.com/file/d/0B3XqWCPGZuTeUTV6ZnVnYjBqdEU/view?pli=1

(via https://drive.google.com/folderview?id=0B3XqWCPGZuTeTGc2ZlVxRXZhYWM&usp=sharing with some other useful files)

I'll post an extract from that document here:

2. Rationale:

MedicalEntity and subtypes vocabulary provided in schema.org are largely used by content 

publishers that wish to mark up health and medical content on the web. Like all schema.org 

schemas, the health and medical schema is intended to make it easier for people to find the right 

web pages by exposing structured information contained in web pages to search engines, and may

also enable other applications that make use of the structure. 

However, given the complexity of health and medical content, some classes and predicates were 

missing, or incompletely defined to achieve this indexing use. Today, most of health and medical 

web content are structured documents, based on clinical information models or HL7 standards (HL7 

V3 RIM, CDA, C-CDA, FHIR etc.) and are integrating existing vocabularies and terminology 

(SNOMED, ICD, LOINC, ATC, RxNorm etc.).

Moreover, some case use scenarios go beyond this simple indexing: schema.org has been used in 

recent health APIs, as a pillar source of medical ontology/vocabulary for formalization of healthcare 

information, through RDF graphs which is a high contribution to the semantic web interoperability. 

To meet those challenges it was necessary to extend the MedicalEntity vocabulary and take this

opportunity to refine some of existing concept (classes and predicates).

The intention here is neither to have a comprehensive medical ontology nor provide a clinical 

information model nor define or codify a new controlled medical vocabulary, but to provide a 

scalable, use-driven vocabulary schema, in-line with the schema.org philosophy. 

3. Approach used:

In this design, none of existing concepts (classes and predicates) are renamed or deleted. There are 

only additions of new classes/predicates and extensions (definitions or domain and range) on the 

existing concepts. For granular classes the priority is given to use the schema.org vocabulary in 

clinical information models which use classes from existing vocabularies and terminology 

(SNOMED, ICD, LOINC, ATC, RxNorm etc.) so the new concepts are minimized. This is a 

scalable approach as schema.org can’t include all those granular concepts.

Additional, staying in schema.org best practice and philosophy we avoided some discussions 

interfering with high-level schema.org design. Finally to refine existing concepts or for a better 

Page 2 of 8

integration of new concepts, there was hierarchy rebuild, like declaring existing schema 

classes/properties as subClass of or subPropertyOf.

4. High level overview of the principle changes

The proposal contains 3 types of changes:

1) Changes: only hierarchies (purpose: corrections of existing hierarchy or for integrating new 

proposed classes/predicates)

a. Class : 18

b. Predicates : 9

2) Deletions: 0

3) Additions/extension

a. Class : 172 (Overview here)

b. Predicates : 173 (Overview here)

A table showing all changes details is provided below, but in nutshell changes are:

Classes:

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

- Extended subclass MedicalEnumeration (some of subclasses are the existing ones: see below 

table).

-New classes added.

Properties:

-adverseOutcome, location, provider, medicalSpeciality and procedure were extended with granular 

subproperties

-status was extended with 2 granular subproperties

Page 3 of 8

-introduction of Snomed concepts use as domain/range objects (not always but where there was no 

clear similar schema.org existing class)

-new properties added.

Comparing the existing schema.rdfa file and the proposed schema.rdfa patch, there are in total 2578 

insertions (+), 59 deletions (-), 25 fixes (changes in subPropertyOf/subClassOf/rdfs:comment in 

existing properties/classes) , 0 class/predicate rename and 0 class/predicate deletions.

We are aware that some improvement may be required even beyond official publication, but those 

will be minimal.
twamarc commented 8 years ago

@danbri Thanks. I will update this file as well to meet all current structures of the extension.

danbri commented 8 years ago

I made some rough (and very very partial) notes on one issue: the exact choice of name for each term. This is probably not the best place for that review but just to quickly share, I copy below. The basic idea is that we need to avoid "using up" words for health that may be more generally applicable, and that we should also look for opportunities to integrate with the core, and for difficult areas where extension schemas overlap (e.g. food/nutrition).

Rough notes on term choice

1) We should consider if we move Place / LocalBusiness -related types: Dentist Hospital Optician Pharmacy Physician Clinician etc

(Dentistry vs Dentist?)

(some of these are also person-as-organization awkward)

2) Diet, DietarySupplement ... ... these touch on other things too e.g. restaurants, menus, recipes, nutrition labels (see upcoming GS1 external extension) - possible some should be handled as core?

3) MedicalAudience ... let's check that Audience navigation looks ok if we break out audiences this way; otherwise core should be fine.

4) Recipe and existing Recipe vocab

I don't think Recipe should move to health from core - although there is clearly a connection

5) action

propose adding muscleAction instead, and potentially removing the medical sense of 'action' (deprecate). The other sense is served ok by potentialAction already.

6) word choice - too broad or vague (cf. v2.0 cleanup)? e.g. words that have other senses. Expand or qualify acronyms?

e.g. Vessel, Appearance, Balance, CT, Completed, Emergency, Genetic, body parts (Ear, Head, ...?), MRI (e.g. MRIScan? MRIScanning?), Retail (rel. to ecommerce vocab?), Suspended, Wholesale, ..., Withdrawn,

(noting that there is still a sense in which the namespace is flat; both in terms of term allocation, and eventual markup)

6) properties

action

activityDuration activityFrequency

affectedBy, availableIn, cost, warning, ....

birthPlace

calories cookingMethod cookTime

code

ghost commented 8 years ago

+1 This is a nice discussion. @twamarc add this to next agenda?

twamarc commented 8 years ago

I clossed this issue, is done. I invite all next comments to this one to be done on the issue schemaorg/schemaorg#492 as a new track for the health extension.