Re: FHIR on schema.org

Hi Renato,

On 05/30/2016 01:43 AM, Renato Iannella wrote:
>
>> On 28 May 2016, at 00:56, David Booth <david@dbooth.org> wrote:
>>
>> It seems to me that privacy needs to be addressed at the level of
>> protocols and policies.  What are you suggesting relevant to
>> vocabularies, such as schema.org?
>
> I am raising the concern that the FHIR vocabulary includes
> personal/private details (eg patient etc) which is *not consistent*
> with the scope and purpose of Schema.org
>
> Schema.Org has no protocols/policies when it comes to the use of its
> vocabularies (and it does not need them, as the intent is to maximise
> publication of structured data).
>
> So for privacy/policy sensitive sectors, schema.org is not the right
> path.

I am having trouble understanding your concern.  Are you concerned that 
the publication of a *vocabulary* -- in this case, the schema.org 
vocabulary -- will somehow cause private information expressed in that 
vocabulary to be published unintentionally?  If so, please explain how.

To my mind, the publication of a *vocabulary* is completely different 
from the publication of data that is expressed using that vocabulary. I 
am not understanding why you are concerned about the publication of a 
*vocabulary*. What harm do you think would be caused by the publication 
of a healthcare vocabulary on schema.org that is fully aligned with a 
widely used healthcare standard?

The schema.org vocabulary already allows phone numbers to be expressed:
https://schema.org/telephone
Phone number can be intentionally or unintentionally made either be 
public or private, just as healthcare data can.

>
>> One step toward standards convergence is to have formal semantic
>> linkage between vocabularies.  This is essential to prevent
>> babelization that would otherwise occur when yet another standard
>> (such as FHIR or schema.org) is defined: http://xkcd.com/927/
>
> This is ironic then? By creating the FHIR Schema.Org vocabulary, you
> just created the 101st standard to deal with?

No, exactly the opposite.  The point is to *not* make a new vocabulary. 
  The point is to make the vocabulary in schema.org exactly match the 
vocabulary in FHIR -- not have schema.org use a different and 
conflicting vocabulary of its own.  The schema.org URIs would be 
synonyms for FHIR URIs.

>
>> Once concepts from other vocabularies (such as FHIR) are brought
>> into a vocabulary (such as schema.org) then the overlaps and
>> differences between concepts become more visible, and it becomes
>> easier for the community to reconcile them and converge on a set of
>> shared concepts.
>
> I would argue against that.

I hope you mean that you would argue against the use of schema.org, 
rather than the goal of converging on a set of shared concepts!

> Schema.Org was never designed as a
> vocabulary mapping tool. By “dumping” all the 101 health vocabularies
> into Schema.Org will not address mappings either.

Agreed, and it may not be the best choice.  But to my mind there can 
only be benefit in encouraging the used of *shared* concepts rather than 
having each new vocabulary inventing its own concepts that overlap and 
conflict with existing concepts that are already defined in other standards.

>
> SKOS should be used to express mappings. And should be maintained by
> an reputable health/clinical SDO.
>
> Also, what use cases are trying to be solved here??

Broadly, semantic interoperability: enabling the exchange of data with 
shared meaning.

>
>> There is a lot of visibility and institutional backing behind
>> schema.org.  Rightly or wrongly this gives it the possibility of
>> acting as an uber-vocabulary that spans many domains -- including
>> healthcare -- and helps toward standards convergence.
>
> A lot of people get captivated by the allure of Schema.Org (must be
> good if Google is doing it ;-) Schema.Org is *controlled* by a small
> steering committee [1] (Search Engine representatives only). Hence,
> it does not represent open consensus in standards - including the
> ability to change the schemas without notice [2].

Again, it may not be the ideal choice.  But alignment with existing 
standards whenever possible is still beneficial.

David Booth

>
>
> Renato
>
>
> [1] http://schema.org/docs/about.html [2]
> http://schema.org/docs/terms.html
>
>

Received on Thursday, 2 June 2016 02:56:07 UTC