15 Apr 2014

See also: IRC log


Claude, DBooth, EricP, Mike, Mike_Denny, Neda, EricP


People's updates

Mike: Working on FHIR, and understanding how their profiles would be represented in OWL. Haven't tried to implement anything yet.
... Trying to understand how RDF would provide benefit over FHIR.

Eric: FHIR people should use LDP tooling for FHIR.

Mike: JSON-LD?

Eric: Could probably add JSON-LD contexts to JSON to spit out RDF.
... Using JSON @profile

Mike: JSON-LD is more palatable from FHIR perspective, because JSON is already there.

David: JSON-LD is an RDF serialization, so you get both JSON and RDF at once!

<Claude> https://global.gotomeeting.com/join/483444365

Eric: But a native RDF representation might be simpler
... Though I'm not certain how well a JSON-LD context could be made. It would be good to explore.
... Can we coerce a JSON-LD @profile to make the current FHIR JSON be JSON-LD?

Claude: But we could do a different JSON-LD representation. It could be done with content negotiation.

Eric: Yes, but easier to manage fewer representations.

Claude: As long as you don't have too many FHIR representations it would be okay. The consumer can pick.

David: Would be nice to see if a JSON-LD context could be made for the existing JSON FHIR.

Eric: Jose was goign to build a JSON analog for GenX, which would allow tight control of JSON structure, which would be needed for the return trip from RDF to JSON (or JSON-LD).
... Mike, can FHIR profiles be thought of as constraints? Can profiles in FHIR be represented in XML Schema?

Mike: Yes. Everything is a profile.
... They could be restrictions, but not necessarily. They could be extensions.
... YOu could define additional valuesets or replace them. It's not just restrictions.

Claude: But I look at the profiles . . . the model gives you flexibility, you can define attributes. The profile tells you that you have a fairly flexible underlying model, but there's a set of constraints that will make you interoperable, and some of them can be defined in XML Schema.
... You could disallow a particular attribute, e.g. But there are also semantic constraints that are better to express e.g. in schematron.
... Restriction of terminologies cannot be expressed in either XML Schema or Schematron. So Profile is complex.

Eric: Suppose I have a set of resources and an extensibility mechanism: 1 where I get to put attributes whereever I want; 2. subclass it to create resources that FHIR folks have not offered.
... Then profiles allow me to create a closed content model, including the abilty to add new properties. And to create new things using Other. And I can specify valuesets in three ways.
... Accurate so far?

Claude: Yes.

Eric: So far, this sounds like somethign that ShapeExpressions could do pretty well. What about schematron for semantic constraints. If you see this path over here, you need that path over there, right? (Claude: Yes)
... Valuesets can be referenced by name; exhaustively enumerated; by substring: everything that starts with this URL.

Claude: And subsumption

Eric: ShEx allows dereferencing to GET a SPARQL result set, so you could construct a valueset on the fly.

Claude: Subsumption says you can put here anything that is a beta blocker. So a SPARQL query should be able to do that.

Eric: How are they coding those in the current FHIR profiles?

<Claude> http://www.hl7.org/implement/standards/fhir/profile.html

Claude: You can define a valueset intensionally or extensionally. Extensionally you give all of the elements. Intensionally you can say anything below this concept, or a valueset given by a query.

Eric: For interop, there would have to be a notion of some set of protocols that an implementation must understand. Or an impl must know what it means when I say "beta blocker".

Claude: I'll have to get back to you about how it does subsumption.
... I can construct a valueset of anything with the word "blocker" in them.
... Subsumption is another approach, that says give me anything in the subtree of your taxonomy.
... Mike mentioned using profiles for extensibility. There are two aspects of profiles. One is constraints. The other is they represent a way to specialize concepts.
... For example I can define a notion of Observation -- generic concept. If I want to create BloodPressureObservation, I'd create a profile allowing only certain attributes and certain values of them.
... In OWL you'd probably do it just by adding a BP concept -- probably not by a set of rules.

Mike: But as soon as it is modified you have a new class.

Claude: Modifying is tricky, because in FHIR an attribute can completely negate the semantics.

Mike: FHIR has lots of governance issues.
... Recently they seem to be backtracking and restricting the latitude.

Eric: When you have a modifiable extension, whenever you interpret something you need to look at least one level down to see if it has been modified.
... But their overarching use case is display, so if a BP extension is the inverse (1 over the systolic), and I have a display system that needs to find the systolic and display it, even if it cannot understand it.
... So they opted for enabling them to be displayed.
... I think that is anathema to the SW crowd.

Claude: If you have a blood sugar observation and you're uncertain if the measurement is reliable, it is still a blood sugar observation, but your confidence in it is low.
... You could have a statement of uncertainty about the observation. It's cleaner: the uncertainty is in the observation.
... But any measure can have some uncertainty.
... So if it is being denied it should be a different concept.

David: Would be great to see if a JSON-LD context could be created for the existing FHIR JSON.

<Claude> https://global.gotomeeting.com/join/483444365

Claude's FHIR ontology progress

Claude: All of the resources are now represented in OWL.
... FHIR allows you to extend the basic core types.
... When you have a required datatype, then both the simple property and the extendedProperty would be required.
... Or I could say that the range coudl be either the simple or the extended. My preference is to mandate the simple one, and leave the extended as optional.

Mike: But simple properties might not be required.

Claude: I'm only talking about the case where the FHIR property is required. But there aren't many of them.
... This approach would mean that if you do use the extended property then both would have to be required, and they would have to match.

Mike: Or the cardinality of the simple one would have to change.

Claude: I'd like to have a way to say that you must have one or the other but not both.
... But we could leave that check for a ShEx.
... or SPARQL.

David: One goal is to use the ont to enable automatic transformation to/from other representations that the sender or receiver systems either have or can understand.

Next week

Claude: Talk about profiles?
... Or terminologies. How to model Codes. I've modeled it as having a string value, but it can have a synonym. When you look at any FHIR concept that is type code, there is no string variant. You can only put a code, and this enforces the notion that you'd want an IRI for anything that is a Code.
... So there's no such thing as priorityExtended, because it's a Code.

Mike: Why cardinality max 1 for Code?

Claude: That's the way FHIR defined it for that particular attribute.

Mike: Representing coding might be a good progression of the current discussion.

<scribe> ACTION: Claude to prepare something on coding for next time [recorded in http://www.w3.org/2014/04/15-hcls-minutes.html#action01]


Summary of Action Items

[NEW] ACTION: Claude to prepare something on coding for next time [recorded in http://www.w3.org/2014/04/15-hcls-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-04-15 17:39:23 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth
Default Present: ericP, DBooth, +1.469.226.aaaa, Neda, Mike_Denny, Claude
Present: Claude DBooth EricP Mike Mike_Denny Neda EricP
Got date from IRC log name: 15 Apr 2014
Guessing minutes URL: http://www.w3.org/2014/04/15-hcls-minutes.html
People with action items: claude

[End of scribe.perl diagnostic output]