-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shorten FHIR property names or use superproperties? #69
Comments
+1 to shortening names. Superproperties would only be useful when FHIR/RDF was used with RDFS inference. @jmandel, thoughts? |
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 ( 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 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 Schema with multiple codes
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 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
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] |
Excellent summary! This will be very helpful for getting input from other FHIR/RDF users, to decide what we want in R5. |
Related documents: https://github.com/HL7/fhir/blob/master/source/w5.ini Don't know which, if any, apply |
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 . |
AGREED: Shorten property names |
Re-opening to discuss: Punning: property fhir:Medication.code shortened to fhir:code, but fhir:code is already a class |
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 |
I propose eliminating options 2 and 4, which I think @ericprud suggested on Thursday's call. |
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"). |
Discussed on today's FHIR RDF call: https://www.w3.org/2023/02/06-hcls-minutes.html#t07 |
Assuming this is resolved with R5 ballot. |
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 justfhir: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:
perhaps we could now write this:
Would this be a good idea? Would it work out well or cause problems?
The text was updated successfully, but these errors were encountered: