IRC log of hcls on 2014-04-15

Timestamps are in UTC.

14:48:32 [RRSAgent]
RRSAgent has joined #hcls
14:48:32 [RRSAgent]
logging to
14:55:33 [ericP]
Zakim, this will be hcls
14:55:33 [Zakim]
ok, ericP; I see SW_HCLS()11:00AM scheduled to start in 5 minutes
15:00:36 [Zakim]
SW_HCLS()11:00AM has now started
15:00:45 [Zakim]
15:00:50 [dbooth]
dbooth has joined #hcls
15:01:10 [Neda]
Neda has joined #hcls
15:01:34 [Zakim]
15:03:14 [Zakim]
+ +1.469.226.aaaa
15:03:34 [ericP]
Zakim, aaaa is Neda
15:03:34 [Zakim]
+Neda; got it
15:05:17 [Zakim]
15:05:18 [Zakim]
15:05:39 [ericP]
Zakim, [IPcaller]
15:05:40 [Zakim]
I don't understand '[IPcaller]', ericP
15:05:46 [Claude]
Claude has joined #hcls
15:05:49 [ericP]
Zakim, [IPcaller] is Claude
15:05:49 [Zakim]
+Claude; got it
15:06:15 [dbooth]
Topic: People's updates
15:06:44 [dbooth]
Mike: Working on FHIR, and understanding how their profiles would be represented in OWL. Haven't tried to implement anything yet.
15:07:09 [dbooth]
... Trying to understand how RDF would provide benefit over FHIR.
15:07:24 [dbooth]
Eric: FHIR people should use LDP tooling for FHIR.
15:07:33 [dbooth]
Mike: JSON-LD?
15:07:53 [dbooth]
Eric: Could probably add JSON-LD contexts to JSON to spit out RDF.
15:08:18 [dbooth]
Meeting: HCLS
15:08:26 [dbooth]
Chair: EricP
15:09:20 [dbooth]
Eric: Using JSON @profile
15:09:43 [dbooth]
Mike: JSON-LD is more palatable from FHIR perspective, because JSON is already there.
15:10:48 [dbooth]
David: JSON-LD is an RDF serialization, so you get both JSON and RDF at once!
15:11:13 [Claude]
15:11:25 [dbooth]
Eric: But a native RDF representation might be simpler
15:13:08 [dbooth]
... Though I'm not certain how well a JSON-LD context could be made. It would be good to explore.
15:13:44 [dbooth]
... Can we coerce a JSON-LD @profile to make the current FHIR JSON be JSON-LD?
15:15:04 [dbooth]
Claude: But we could do a different JSON-LD representation. It could be done with content negotiation.
15:15:31 [dbooth]
Eric: Yes, but easier to manage fewer representations.
15:16:39 [dbooth]
Claude: As long as you don't have too many FHIR representations it would be okay. The consumer can pick.
15:17:29 [dbooth]
David: Would be nice to see if a JSON-LD context could be made for the existing JSON FHIR.
15:18:36 [dbooth]
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).
15:19:17 [dbooth]
Eric: Mike, can FHIR profiles be thought of as constraints? Can profiles in FHIR be represented in XML Schema?
15:19:26 [dbooth]
Mike: Yes. Everything is a profile.
15:20:01 [dbooth]
... They could be restrictions, but not necessarily. They could be extensions.
15:20:22 [dbooth]
... YOu could define additional valuesets or replace them. It's not just restrictions.
15:21:22 [dbooth]
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.
15:21:55 [dbooth]
... You could disallow a particular attribute, e.g. But there are also semantic constraints that are better to express e.g. in schematron.
15:22:19 [dbooth]
... Restriction of terminologies cannot be expressed in either XML Schema or Schematron. So Profile is complex.
15:23:08 [dbooth]
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.
15:23:54 [dbooth]
... 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.
15:24:07 [dbooth]
... Accurate so far?
15:24:19 [dbooth]
Claude: Yes.
15:25:03 [dbooth]
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)
15:25:44 [dbooth]
... Valuesets can be referenced by name; exhaustively enumerated; by substring: everything that starts with this URL.
15:25:58 [dbooth]
Claude: And subsumption
15:26:42 [dbooth]
Eric: ShEx allows dereferencing to GET a SPARQL result set, so you could construct a valueset on the fly.
15:27:14 [dbooth]
Claude: Subsumption says you can put here anything that is a beta blocker. So a SPARQL query should be able to do that.
15:27:28 [dbooth]
Eric: How are they coding those in the current FHIR profiles?
15:28:21 [Claude]
15:29:12 [dbooth]
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.
15:29:25 [Mikke_Denny]
Mikke_Denny has joined #hcls
15:31:16 [dbooth]
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".
15:32:02 [dbooth]
Claude: I'll have to get back to you about how it does subsumption.
15:32:34 [dbooth]
... I can construct a valueset of anything with the word "blocker" in them.
15:32:51 [dbooth]
... Subsumption is another approach, that says give me anything in the subtree of your taxonomy.
15:34:06 [dbooth]
... 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.
15:34:46 [dbooth]
... 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.
15:35:22 [dbooth]
... In OWL you'd probably do it just by adding a BP concept -- probably not by a set of rules.
15:35:34 [dbooth]
Mike: But as soon as it is modified you have a new class.
15:36:26 [dbooth]
Claude: Modifying is tricky, because in FHIR an attribute can completely negate the semantics.
15:36:43 [dbooth]
Mike: FHIR has lots of governance issues.
15:37:11 [dbooth]
... Recently they seem to be backtracking and restricting the latitude.
15:37:52 [dbooth]
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.
15:38:47 [dbooth]
... 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.
15:39:30 [dbooth]
... So they opted for enabling them to be displayed.
15:39:47 [dbooth]
... I think that is anathema to the SW crowd.
15:40:28 [dbooth]
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.
15:41:04 [dbooth]
... You could have a statement of uncertainty about the observation. It's cleaner: the uncertainty is in the observation.
15:41:26 [dbooth]
... But any measure can have some uncertainty.
15:41:45 [dbooth]
... So if it is being denied it should be a different concept.
15:43:08 [dbooth]
David: Would be great to see if a JSON-LD context could be created for the existing FHIR JSON.
15:43:16 [Claude]
15:43:31 [dbooth]
Topic: Claude's FHIR ontology progress
15:43:39 [dbooth]
rrsagent, make logs public
15:44:41 [dbooth]
Claude: All of the resources are now represented in OWL.
15:45:25 [dbooth]
... FHIR allows you to extend the basic core types.
15:47:08 [Zakim]
15:47:20 [Zakim]
15:49:15 [mscottm]
mscottm has joined #hcls
15:54:05 [dbooth]
Claude: When you have a required datatype, then both the simple property and the extendedProperty would be required.
15:54:41 [dbooth]
... 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.
15:55:01 [dbooth]
Mike: But simple properties might not be required.
15:55:31 [dbooth]
Claude: I'm only talking about the case where the FHIR property is required. But there aren't many of them.
15:56:51 [dbooth]
... 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.
15:57:08 [dbooth]
Mike: Or the cardinality of the simple one would have to change.
15:57:33 [dbooth]
Claude: I'd like to have a way to say that you must have one or the other but not both.
15:57:58 [dbooth]
... But we could leave that check for a ShEx.
15:58:36 [dbooth]
... or SPARQL.
16:04:01 [dbooth]
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.
16:04:20 [dbooth]
Topic: Next week
16:04:32 [dbooth]
Claude: Talk about profiles?
16:05:42 [dbooth]
... 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.
16:06:05 [dbooth]
... So there's no such thing as priorityExtended, because it's a Code.
16:06:45 [dbooth]
Mike: Why cardinality max 1 for Code?
16:08:21 [dbooth]
Claude: That's the way FHIR defined it for that particular attribute.
16:09:59 [dbooth]
Mike: Representing coding might be a good progression of the current discussion.
16:10:40 [dbooth]
ACTION: Claude to prepare something on coding for next time
16:11:07 [dbooth]
16:11:18 [dbooth]
rrsagent, draft minutes
16:11:18 [RRSAgent]
I have made the request to generate dbooth
16:11:19 [Zakim]
16:11:20 [Zakim]
16:11:20 [Zakim]
16:11:25 [Zakim]
16:11:43 [Zakim]
16:11:45 [Zakim]
SW_HCLS()11:00AM has ended
16:11:45 [Zakim]
Attendees were ericP, DBooth, +1.469.226.aaaa, Neda, Mike_Denny, Claude
16:58:45 [mscottm]
mscottm has joined #hcls
17:36:19 [dbooth]
dbooth has joined #hcls
17:38:41 [dbooth]
Present: Claude DBooth EricP Mike Mike_Denny Neda EricP
17:39:17 [dbooth]
rrsagent, draft minutes
17:39:17 [RRSAgent]
I have made the request to generate dbooth
17:39:39 [ericP]
tx dbooth!
17:49:23 [Zakim]
Zakim has left #hcls
17:51:26 [ericP]
RRSAgent, bye
17:51:26 [RRSAgent]
I see 1 open action item saved in :
17:51:26 [RRSAgent]
ACTION: Claude to prepare something on coding for next time [1]
17:51:26 [RRSAgent]
recorded in