Re: HL7/W3C FHIR/RDF properties

* João Moreira (UTwente) <j.luizrebelomoreira@utwente.nl> [2018-02-15 11:28+0100]
>  Dear,
> 
> I've been studying the current version of FHIR RDF ("Structural Ontology")
> serialized as TTL ( http://build.fhir.org/fhir.ttl ) and I identified two
> issues regarding the properties:
> 
> (1) I wonder why each object property was specialized according the source
> "concept" (term)? For example:
> - "fhir:AllergyIntolerance.reaction.description"
> - "fhir:Account.description"
> - "fhir:ActivityDefinition.description"
> 
> In my opinion, this has the advantage of organizing and specializing the
> property for each concept, i.e. the "description" property of
> ActivityDefinition has different semantics (meaning) of the "description"
> property of Account. On the other hand, with this approach we make the
> ontology more complex (bigger), lose extensibility and knowledge discovery.
> A simple example: if you want to query all objects that has description
> "XPTO" you'll need to specify each ".description" in the SPARQL (as
> commonly done in relational DB/SQL).
> 
> This is not limited to the properties ".description", there are plenty of
> other examples, e.g. location, note, created, comment, identifier, etc.

I completely agree with your appraisal; the schema would be much
better if "we" took the time to come up with the minimal set of
properties to capture the semantics and share those properties between
different resources. The problem that the current editing mechanism
doesn't capture this.

You may think of the FHIR/RDF task force as being responsible for
minting predicates and imposing a sensible model. In fact, resource
authoring happens by task forces composed of domain experts who think
in terms of FHIR ElementDefinitions. There is currently no process for
getting the clinical observation folks together with the clinical
procedure folks to decide that they have certain properties in common
and we are NOT invited to make those calls on our own. So in effect,
we have a very conservative (in that it conserves everything) mapping
from pairs of a class and locally-scoped property to global URLs which
preserve both elements of that pair. (IIRC, this mapping pretty
closely mirrors the model used in OMG's ODM, which you can also see in
the BRIDG model.)

I believe Tony Mallia (Cc'd) reviewed the bulk of the resources to
see what date-like predicates there were and found ~ six different
semantics spread across I don't know how many unique property names.
Dropping the domain name from the property would have the unfortunate
affect of merging those together.

There is hope, however. FHIR architects want to raise the bar in order
to capture the fact that multiple resources have properties with the
same semantics. The W5 vocabulary represents a start on this but I
don't believe a significant fraction of the task forces have reviewed
those properties enough to say that "yes, that's what we meant; the
common term should be used instead of ours."

It's worth noting that since all the juicy semantics are in the
terminologies, reuse or subsumption in the information model won't
enable many clinical use cases. Ontologies like SNOMED-CT and HPO
already do a good job with those. I think the biggest ROI on a
better-engineered FHIR/RDF vocabulary will be in abstracting (and
ideally simplifying) some workflow use cases, e.g. employing generic
tracking for fulfillment of medication orders and procedure orders.


> (2) A common approach in ontology engineering is to reuse predicates from
> other ontologies, as in [1], especially the ones that are standardized
> (e.g. from W3C, RDFS, Dublin Core, etc). For example, "description",
> "title", "issued", etc are properties already standardized within DC terms (
> http://dublincore.org/2012/06/14/dcterms). Why not reusing these properties
> instead of creating new ones? Ultimately, this can improve the
> interoperability capability of the ontology. I understand when we need to
> specialize a property for something specific of the health domain, but
> anyway, in this case we can still use a standardized property and
> specialize it, e.g. if there is the specific limit of text length of
> "fhir:DocumentReference.description", we can specialize it as a
> "dc:description" and add an axiom limiting the text size.

Many organizations feel more comfortable owning their vocabulary so I
don't know how this will shake out. That said, if we factor some or
all of the resource-specific properties into generic properties, it
shouldn't matter if a few (very few, I expect) come from outside
vocabularies. Once again, use cases will likely affect these decisions
as much as aesthetics will.


> - ACTION:
> I propose to: (a) make a list of the properties that have the same meaning
> in FHIR; (b) check whether these properties are already provided in other
> standardized ontologies; and (c) discuss how to change the FHIR RDF
> ontology, i.e. exchange the existing properties for the ones found.

I think w5 is a great place to start.
  <http://build.fhir.org/w5.html>
and look for "identity": "w5" mappings in e.g.
<http://build.fhir.org/observation.profile.json.html>


> Best regards,
> 
> João Moreira
> University of Twente
> 
> 
> [1]
> https://github.com/DTL-FAIRData/FAIRDataPoint/wiki/FAIR-Data-Point-Specification
> 
> 
> >

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 15 February 2018 18:40:01 UTC