Shorten FHIR property names or use superproperties?

[dbooth-boston]

Back when FHIR RDF R4 was first designed, the FHIR community allowed different FHIR resources to use the same property names for potentially different purposes: there was no official coordination of property names across resources. As a consequence, when R4 was designed, we opted to fully qualify the property names to ensure that they would be semantically distinct. For example, the "severity" property within an AllergyIntolerance reaction was given the fully qualified name fhir:AllergyIntolerance.reaction.severity instead of just fhir:severity.

Fast forward a few years, and the the FHIR community is now trying to be more rigorous about consistent naming of properties across FHIR resources, such that the same property name should have the same semantics across different resources. This could allow us to shorten property names in RDF instead of using a path to construct a fully qualified name. Should we shorten property names? Or define superproperties with short names? See FHIR Five Ws page

For example (but we need a better one), instead of writing this:

fhir:AllergyIntolerance.reaction.severity [ fhir:value "moderate" ];

perhaps we could now write this:

fhir:severity [ fhir:value "moderate" ];

Would this be a good idea? Would it work out well or cause problems?

[ericprud]

+1 to shortening names. Superproperties would only be useful when FHIR/RDF was used with RDFS inference. @jmandel, thoughts?

[ericprud]

When @jmandel and I started on this venture, Josh pointed out that there was no management to align the property names in different Resources (e.g. an Observation.foo may not equal Procedure.foo). StructureDefinitions already included fully-qualified names so it made sense to use those for FHIR/RDF. Since then, the fivews effort has aligned some (most? all?) of the properties in the core Resources. (Need link to the very wide fivews table that maps Resource-specific properties to fivews concepts.)

This effort has lead to re-used semantic names for properties (e.g. Observation.subject and Condition.subject) and good reasons when they differ. For instance, Observation.subject and Immunization.patient differ because the specificity of the recipient of an Immunization is higher (Reference(Patient)) than that of an Observation (Patient | Group | Device | Location | Organization | Procedure | Practitioner | Medication | Substance). The fivews heading for both of these is @@TBD1 [resolve with spreadsheet].

On a conceptual level, this is all easily captured in RDFS:

fhir:Observation.subject rdfs:subPropertyOf fhir:subject .
fhir:Condition.subject rdfs:subPropertyOf fhir:subject .
fhir:Immunization.patient rdfs:subPropertyOf fhir:patient .

If we take the fivews headings as hallowed, we could add:

fhir:subject rdfs:subPropertyOf fhir:@@TBD1 .
fhir:patient rdfs:subPropertyOf fhir:@@TBD1 .

Note, I'm not advocating for real-time involvement of RDFS; just using it to formalize the apparent subsumption.

So now we have three possible names for Observation.subject and I would argue we want to choose exactly one to make interop practical. DL modeling principles suggest reusing general properties (c.f. using a "topping" property for both pizzas and ice cream), so we could use the fivews column name if possible. It would not be possible if fivews column names are not unique.

In addition to semantic clarity, we have to consider pallatability. FHIR developers are used to seeing the names of properties in those nice HTML tables and using those property names in instance data. Right now, that's a bit painful for RDF-heads because they have to add the full qualification. We could improve dev's lives by restricting to just the property name (in the fhir: namespace).

Using property will never be ambiguous because if it were, it would be ambiguous in every FHIR representation and addressed immediately. Note that the same property name may appear in multiple places in a Resource, e.g. the fhir:codes in:

Schema with multiple codes

<#Observation> CLOSED {
  a [fhir:Observation] ;
  fhir:code @<#CodeableConcept> ;
  fhir:component CLOSED {
    fhir:code  @<#CodeableConcept> ;
    fhir:value  @<#CodeableConcept> OR @<#Quantity> ;
  } *
}

Data with multiple codes

<Observation/BP123> a fhir:Observation ;
  fhir:code [ a fhir:CodeableConcept ;
    fhir:coding [ a fhir:Coding ;
                  fhir:system [ fhir:value "http://loinc.org" ] ;
                  fhir:code [ fhir:value "35094-2" ] ] ] ;
  fhir:component [
      fhir:code [ a fhir:CodeableConcept ;
        fhir:coding [ a fhir:Coding ;
                      fhir:system [ fhir:value "http://loinc.org" ] ;
                      fhir:code [ fhir:value "8480-6" ] ] ] ;
      fhir:value [ a fhir:Quantity ; fhir:value 120.0 ]
    ], [
      fhir:code [ a fhir:CodeableConcept ;
        fhir:coding [ a fhir:Coding ;
                      fhir:system [ fhir:value "http://loinc.org" ] ;
                      fhir:code [ fhir:value "8453-3" ] ] ] ;
      fhir:value [ a fhir:Quantity ; fhir:value 80.0 ]
    ]
.

[try it]

This unifies three kinds of code into one term:

1. Observation.code
2. Observation.component.code
3. Coding.code

1 and 2 are pretty obviously the same thing so I believe it's non-controversial to merge them. 3 is a different beast in structure (it's a string (well, a bnode with a fhir:value if we're being persnickety)) instead of a CodeableConcept. Ordinarily, I don't think that datatypes should differentiate RDF properties (valueQuantity vs. valueCodeableConcept) but 3 feels so different as to maybe be worth differentiating. One principled way to attack this would be to only shortent Resource properties, not datatype properties:

Schema with fully-qualified datatypes

<#CodeableConcept> CLOSED {
  a [fhir:CodeableConcept] ;
  fhir:CodeableConcept.coding @<#Coding> *
}

<#Coding> CLOSED {
  a [fhir:Coding] ;
  fhir:Coding.system @<#string> ;
  fhir:Coding.code @<#string> ;
}

Data with fully-qualified datatypes

<Observation/BP123> a fhir:Observation ;
  fhir:code [ a fhir:CodeableConcept ;
    fhir:CodeableConcept.coding [ a fhir:Coding ;
                  fhir:Coding.system [ fhir:value "http://loinc.org" ] ;
                  fhir:Coding.code [ fhir:value "35094-2" ] ] ] ;
  fhir:component [
      fhir:code [ a fhir:CodeableConcept ;
        fhir:CodeableConcept.coding [ a fhir:Coding ;
                      fhir:Coding.system [ fhir:value "http://loinc.org" ] ;
                      fhir:Coding.code [ fhir:value "8480-6" ] ] ] ;
      fhir:value [ a fhir:Quantity ; fhir:value 120.0 ]
    ], [
      fhir:code [ a fhir:CodeableConcept ;
        fhir:CodeableConcept.coding [ a fhir:Coding ;
                      fhir:Coding.system [ fhir:value "http://loinc.org" ] ;
                      fhir:Coding.code [ fhir:value "8453-3" ] ] ] ;
      fhir:value [ a fhir:Quantity ; fhir:value 80.0 ]
    ]
.

[try it]

[dbooth-boston]

Excellent summary! This will be very helpful for getting input from other FHIR/RDF users, to decide what we want in R5.

[hsolbrig]

Related documents:

https://github.com/HL7/fhir/blob/master/source/w5.ini
https://github.com/HL7/fhir/blob/master/source/status-codes.xml
https://github.com/HL7/fhir/blob/master/source/compartments.xml

Don't know which, if any, apply

[dbooth-boston]

I think the main question is whether we could shorten property names without causing the property to become both an object property and a datatype property, as described in issue #102 .

[dbooth-boston]

AGREED: Shorten property names

https://www.w3.org/2022/07/28-hcls-minutes.html#t03

[dbooth-boston]

Re-opening to discuss: Punning: property fhir:Medication.code shortened to fhir:code, but fhir:code is already a class

[dbooth-boston]

Option 1: Use OWL punning. Have both a class fhir:code and a property fhir:code

Option 2: Revert to fully qualified property names, such as fhir:Medication.code

Option 3: Change the class to start with an upper case: fhir:Code

Option 4: Use some other naming convention for the class, such as a"C_" or "Class_" prefix: fhir:C_code or fhir:Class_code

[dbooth-boston]

I propose eliminating options 2 and 4, which I think @ericprud suggested on Thursday's call.

[dbooth-boston]

Option 3 would have the benefit that all classes would then uniformly start with an upper case letter. I think I'm favoring option 3, because it gives that uniformity while avoiding punning, even though it slightly doesn't align with the lower case FHIR spelling of the type ("code").

[dbooth-boston]

Discussed on today's FHIR RDF call: https://www.w3.org/2023/02/06-hcls-minutes.html#t07

[ericprud]

Assuming this is resolved with R5 ballot.