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

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!

any progress there?

Hi everyone,

Regarding: #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

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.

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

Hi Marc,

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

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

• All extension definitions (rdfa) and example files live in a directory
  with the data directory in the source:
  • schemaorg/data/ext/[extension name]
  • eg. schemaorg/data/ext/health
  • You will find a fairly complete example for bib in
    schemaorg/data/ext/bib
  • As per the core, you can split your definitions into more than one
    rdfa/exmples.txt files
• Each term defined in an extension has to be associated with that
  extension with an isPartOf statement:
  eg.
• If a term is already defined in the core vocabulary and the definition
  in the extension rdfa file is only adding to that core definition. For
  example adding an extra rdfs:subClassOf or domainIncludes or rangeIncludes
  statements. Do NOT add the isPartOf statement.

• It is worth adding some basic info the top of the rdfa files - see the
  bsdo-1.0.rdfa for examples (both not yet used but will come in handy later):

  • Default vocabulary prefix: 'bib:'

  • bib.schema.org Version
    0.1
• To enable the use of the extension it needs to be included in
  the ENABLED_EXTENSIONS and ALL_LAYERS lists in the sdoapp.py file -
  currently about line 60

Any questions / issues just yell.

~Richard

On Wed, Jul 29, 2015 at 2:52 PM, Marc [email protected] wrote:

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

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

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

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

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 [email protected] 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.

Good!

Thanks

Marc

Sincerely yours

Sent from my iPad Device
On 18 Aug 2015 18:47, "RichardWallis" [email protected] 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 [email protected] 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
#2 (comment).

Marc,

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

~Richard

On 18 Aug 2015, at 08:33, Marc [email protected] 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.

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.

@jamrob the sdo-ganymede is the 2.1

@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

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:

​

• "Defined in the ealth.schema.org extension" - the missing 'h' is
  down to a defect in the api code I will investigate
• 'birthPlace' (like several other properties) have a range of
  http://purl.bioontology.org/ontology/SNOMEDCT/*.
  The software is treating the 169812000 in this case as a term in an
  undefined extension. We can identify such a case (it is already
  complaining about it in the logs) The question is, how do we want to
  display such types?
• Not obvious from the screenshot but the definition of
  http://schema.org/birthPlace occurs both in schema.rdfa and
  health_core-0.1.rdfa - the core (schema.rdfa) wins which it it's label is
  not in blue. In both files however the range value of
  http://purl.bioontology.org/ontology/SNOMEDCT/169812000 is defined. My
  presumption being that that should only be defined in the extension.
  • I am thinking about adding some more error checking to identify
    when a property already defined in the core is being overwritten, as
    against being extended, by an extension definition
  • For the moment we should remove the SNOWMEDCT rangeIncludes from
    schema.rdfa and the Place rangeIncludes from the extension file.

Thats all for now...

~Richard.

On Tue, Aug 18, 2015 at 6:19 PM, Marc [email protected] 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
#2 (comment).

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

• Moved to health extension but still to be discussed: birthPlace, deathPlace.
• Range:http://purl.bioontology.org/ontology/SNOMEDCT/*.
  Can we use owl:equivalentProperty/Class so that rangeIncludes and domainIncludes are only used for internal links.? When this was discussed last year with @danbri , This was under experimentation at schema.org side.

-additionally picked some obvious fixes in line with schemaorg/schemaorg#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

Great to see this moving along!

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

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.

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

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.

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
schemaorg/schemaorg#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 [email protected] 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
#2 (comment).

@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

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)

/cc @rvguha fyi

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

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 [email protected] 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
#2 (comment).

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 [email protected]
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 [email protected] 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
#2 (comment).

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

@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

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 [email protected] 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
#2 (comment).

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

Yes you can use.

I'll be there!

~Richard

On 28 Aug 2015, at 13:19, Marc [email protected] 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.

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

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

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

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)

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

• see above

activityDuration
activityFrequency

• for non-health activities, actions and events too?

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

• very broad wording. health only or more broadly applicable?

birthPlace

• vs. general / core treatment of people? (revisit family tree stalled work?)

calories
cookingMethod
cookTime

• recipes stay in core? see above

code

• always was v general, should we generalize it beyond health for core?
• be aware that we also have an related type spelled http://schema.org/Code :(

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

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.