Hi Renato,
On 05/30/2016 01:43 AM, Renato Iannella wrote:
On 28 May 2016, at 00:56, David Booth <[email protected]> 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
