Need a minimum requirement for first version of health.schema.org extension

[RichardWallis]

I recommend that the first proposed release of heath.schema.org should be based upon those terms identified in the current core of schema.org as candidates for moving into a health extension.

The result of this being:

• to reduce the analysis work for a first proposal significantly
• to reduce the complexity of that analysis - at this stage it would be a question of move or not move
• to increase the likelihood of the extension proposal being accepted
• at this stage nothing would break

There may be a few other obvious changes that could be included, such as depreciating and replacing some conflicting property names. However anything more than that should be part of future proposals that can be created from clear use cases built upon this initial foundation.

[ghost]

Am afraid, I totally disagree on this.
From the beginning of this effort, the aim was to extend the existing vocab. Now the target is nearly reached. It's not the time to step back.
Probably we need to remind @RichardWallis that every term which was added was motivated by its use and need. Afterwards the proposal was reviewed and reviewed.
The proposal being large its not a problem itself, this is the nature of the healthcare domain (professionnals there correct me if am wrong).
The proposal will again increase in volume as we expect the health insurance, genetics, nutritionInfo, and clinical trial vocabs to come in.
The nice discussions I would like to have here would be based on term by term criticism. I saw some input in this sense and I support .
Sorry to jump in

James

[davefeg]

-1
I do not support this idea of pulling out all extensions as well. What should have been the effort then?
Let's keep moving forward, and ask the community to widely review the extension, term by term.
especially let us listen to people in healthcare domain.
from the beginning we never said the extension will be 10-15 terms! The healthcare domain is complex and the needs there cannot be compared with small domain like auto or bib.
@twamarc can you put here the pointer also to old discussions from Google Group?
.

[RichardWallis]

I feel I should clarify my position on this. I am not suggesting that the overall proposal should be limited to what is already in the core, or that the valuable efforts by this engaged community getting the proposal to this stage should be stepped back from.

In my comment:
I recommend that the first proposed release of heath.schema.org should be based...

I was expressing pragmatic concern as to the potential acceptance and adoption of the proposed extension being detrimentally impacted by trying to introduce it all in one large, and to the rest of the world complex, release.

The experts in the bibliographic and Automotive fields would probably acknowledge that their domains may be a little less complex than health but would also contest their categorisation a small. That is why there are many further enhancements and expansions to those extensions, building on their initial releases, waiting in the wings for proposal. In the most case this approach of evolving towards a conclusion, taking account of usage, adoption, and experience along the way, has been a strength in how Schema.org became what it is.

By proposing the large (currently 290+ Types, 380+ Properties) extension you will be asking for a significant investment in time and attention from the Schema.org community to review it, for potential name clashes; claiming of terms that have broader meaning across other domains; consistency in style with the rest of Schema.org; and then feeding back possible suggestions for change. This when there is little or no visibility for potential adoption in the public web.

There is an obvious chicken & egg argument around adoption that is valid here - to show adoption there must be some vocabulary available. Fortunately health has a head start, with several terms already available for use. An analysis of the use of those terms should obviously form part of the supporting material accompanying the proposal. I see that MedicalEntity is already used by between 100 and 1000 domains, so is MedicalCause - others I scanned were used by between 10 and 100.

I'm a firm believer in the old saying that the best way to eat an elephant is one bite at a time.

In that spirit I made my recommendation that a good first, easily consumable, bite would be to get agreement on what in the current core would form a good foundation for the health extension. I suspect this could happen fairly rapidly.

In the meanwhile a good next subset, and most importantly parters willing to implement it on the public web, can be identified documented and form a proposal to closely follow this first one, with others then to follow. My experience in the way that the Schema.org community operates tells me that these steps may only be a few months or even weeks apart.

I am eager also to see these signifiant, in many ways, efforts come to a successful conclusion and I hope my pragmatic advice based upon my experience is taken in the spirit that is offered.

~Richard.

[ghost]

@RichardWallis :
I quite see what you mean and thanks for clarifications added.
However I continue to think-as someone who was there at the beginning of this effort, that the current discussions should be based on terms assessment: something like 'why this is there', 'the definition is not correct', the domain/range should be xyz', etc.

As I read in the Healcare vocab CG inhouse-rules/procedures such items should be raised as issue (term by term) on Github. I am fully convinced that this is the best way forward.

We can't pull out a term without any reason (just because the proposal is big), whereas it was suggested with a rationale and a real need. Also let's avoid comparing extensions, they are specific at their own, there's no big no small, all of them are needed. Also the statistics of use can't apply on new terms-as they are yet unknown before they are published. Anyway am very positive that age as we are we will find a suitable approach to give long life to this health.schema.org extension

So please let's move forward.

My 2 cents,
James

[danbri]

Let me try to rephrase the concern (also articulated by Guha in last week's call) from a schema.org perspective:

We do not have a problem with the size as such. The concern is that this is a large set of additions, without any clear connection to parties who are committing to use the data in some way. In particular, regarding schema.org's general emphasis on public data in the Web, it is hard to imagine usecases for much of the vocabulary, which seems to be oriented towards very private/personal data records. On the call last week we touched on the need to explore and strengthen usecases around public data e.g. clinical trials. There may be huge demand to extend schema.org for non-Web medical informatics scenarios - but if so let's gather evidence of that more explicitly.

Schema.org extensions btw do come in two "kinds": hosted and external. We certainly need to do some work around the existing medical/health terms, and moving them to a hosted "health" extension seems the obvious step. However it might be possible to rethink the larger proposal as an external extension. Such extensions live in their own namespace and therefore there is reduced need for review and debate. At this time we have no finalized external extensions, but there is work under way with www.gs1.org who have very substantial, rich and large schemas that have a life of their own. I would suggest proceeding as Richard outlined; do the "obvious" fixes (moving terms from Core to hosted Health.schema.org) ASAP, and at the same time (re)collect use cases and publisher/consumer interest for the larger vocabulary. I think we can expect something from GS1 in the next few weeks which should give us a clearer picture of how "external extensions" might look.

[ghost]

Within this scope I think we will need to re-start (re-do the job which was done) from the beginning. what @twamarc think about this?

[danbri]

Perhaps start by pulling together the back-story behind the proposed vocabulary? How did each term get in there? What are people expecting to use them for?

[twamarc]

Hi @jamrob:
This is a normal process and I support it as a good way forward.
Quoting @rvguha experience (http://www.w3.org/2015/08/28-schemed-minutes.html), it would be hard to convince everyone to use it and find what he needs if it's given as big vocab. Exactly 'the best way to eat an elephant is one bite at a time' (@RichardWallis) applies here.

I would remind what I communicated in the Webex (and in inhouse rules/requirements-wiki page) that our intention is not to cover the whole healthcare domain, and the health ext should be demand/use cases driven.

Please note that integrated vocabs in schema.org are judged (at schema side) from the perspective of data consumption and use cases. Of course I know this may disappoint some of our colleagues in the community but am afraid I see it as the best and pragmatic approach.
Well I agree with you that medical domain is complex and most use cases are not public (eg. your initial submission; or the editions I personally suggested, etc). Probably we need to find a way of balancing the extension (not fully add all and not exclude all).
But here we need a starting point (a well published extension ) we can continue to extend.
Sorry to disappoint you (and others maybe) but someone needs to bring this message up.
Let's work on a cleaned version of already published/existing terms in schema (maybe with very minimum workable suggestions for extension).

@danbri / @RichardWallis :
Working on the high-level description/rational of the extension: probably we will not need to provide description or rationale of existing terms (as this was already done). am correct?
This would reduce the redaction work to just provide a rationale paragraph update (no terms description-expect those eventually edited) and including the future plans.

~Marc

[twamarc]

@RichardWallis
As we are preparing the new version of the extension proposal based upon those terms identified in the current core of schema.org as candidates for moving into a health extension; is it possible to have this existing version (0.1) as archive (so we can always refer to it as working document in future)?
Keep a pointer something like: http://health.sdo-schemedex.appspot.com/MedicalEntity

-Marc

[RichardWallis]

@twamarc https://github.com/twamarc I would agree that we in general
would not need to provide description/rationale of existing terms to be
moved to an extension beyond that supplied with the terms themselves.

For some individual terms this might be needed when questioning the need to
move, or not, and naming etc.

Once we have a first draft of this extract proposal we can then work
through those individual terms identifying issues and comments, to get it
ready for proposal. The type of thing I have in mind was posted by @danbri
https://github.com/danbri last week:
#2 (comment)

If you can supply me with the RDFa and examples.txt files that cover this,
I will put it up on a prototype site for others to view.

~Richard

On Wed, Sep 2, 2015 at 7:14 AM, Marc notifications@github.com wrote:

Hi @jamrob https://github.com/jamrob:
This is a normal process and I support it as a good way forward.
Quoting @rvguha https://github.com/rvguha experience (
http://www.w3.org/2015/08/28-schemed-minutes.html), it would be hard to
convince everyone to use it and find what he needs if it's given as big
vocab. Exactly 'the best way to eat an elephant is one bite at a time' (
@RichardWallis https://github.com/RichardWallis) applies here.

I would remind what I communicated in the Webex (and in inhouse
rules/requirements-wiki page) that our intention is not to cover the whole
healthcare domain, and the health ext should be demand/use cases driven.

Please note that integrated vocabs in schema.org are judged (at schema
sida) from the perspective of data consumption and use cases. Of course I
know this may disappoint some of our colleagues in the community but am
afraid I see it as the best and pragmatic approach.
Well I agree with you that medical domain is complex and most use cases
are not public (eg. your initial submission; or the editions I personally
suggested, etc). Probably we need to find a way of balancing the extension
(not fully add all and not exclude all).
But here we need a starting point (a well published extension ) we can
continue to extend.
Sorry to disappoint you (and others maybe) but someone needs to bring this
message up.
Let's work on a cleaned version of already published/existing terms in
schema (maybe with very minimum workable suggestions for extension).

@danbri https://github.com/danbri / @RichardWallis
https://github.com/RichardWallis :
Working on the high-level description/rational of the extension: probably
we will not need to provide description or rationale of existing terms (as
this was already done). am correct?
This would reduce the redaction work to just provide a rationale paragraph
update (no terms description-expect those eventually edited) and including
the future plans.

~Marc

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

[twamarc]

@RichardWallis:
Great! I have created issue items for each of listed terms as posted by @danbri #2 (comment), so we can make a proper follow up.
In next days I will first extract the proposal, then I will come back to the list and example text files.
And what about keeping as archive this existing version (0.1) as archive (so we can always refer to it as working document in future)? I mean something like to keep alive a the pointer http://health.sdo-schemedex.appspot.com/MedicalEntity

[RichardWallis]

@twamarc https://github.com/twamarc I would suggest that the [current]
version you proposed last week be captured as a branch in the github
repository. We can then refer back to it at any time.

I would prefer to keep http://health.sdo-schemedex.appspot.com
http://health.sdo-schemedex.appspot.com/MedicalEntity as representing the
current work in progress state for members of both schemed and schmaorg to
reference in discussions.

It is not that difficult to create other appspot.com instances that could
reflect other branches of what are under discussion. For example a working
version of the 'next' proposal building on the first extraction proposal.

On Wed, Sep 2, 2015 at 9:37 AM, Marc notifications@github.com wrote:

@RichardWallis https://github.com/RichardWallis:
Great! I have created issue items for each of listed terms as posted by
@danbri https://github.com/danbri #2 (comment)
#2 (comment), so
we can make a proper follow up.
In next days I will first extract the proposal, then I will come back to
the list and example text files.
And what about keeping as archive this existing version (0.1) as archive
(so we can always refer to it as working document in future)? I mean
something like to keep alive a the pointer
http://health.sdo-schemedex.appspot.com/MedicalEntity

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

[twamarc]

@RichardWallis: Thanks. I created a branch in git hub (sdo-schemed.v0.1) Can you help in creating another appspot.com instance that could reflect sdo-schemed.v0.1 branch ? I think it can help first to do this and then move forward with extraction.
Not sure am correct!

[RichardWallis]

@twamarc I have created an appspot instance that holds the initial proposal for reference: http://health.sdo-schemedex-0-1.appspot.com/MedicalEntity

The original test instance http://health.sdo-schemedex.appspot.com/MedicalEntity is still in place ready to be used to show later proposals. Currently both instances are demonstrating an identical state.

As soon as you let me have a copy of your first pass, extract from core, version I will test and load it into sdo-schemadex.

cc/@danbri

[twamarc]

Thanks! I will be back to you as soon as I finish the initial pass.

[twamarc]

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.