See also: IRC log
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: 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.
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]
ADJOURNED
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]