IRC log of hcls on 2014-03-25

Timestamps are in UTC.

14:58:04 [RRSAgent]
RRSAgent has joined #hcls
14:58:04 [RRSAgent]
logging to
14:58:07 [ericP]
Zakim, this is hcls
14:58:07 [Zakim]
ok, ericP; that matches SW_HCLS()11:00AM
15:00:25 [agray]
agray has joined #hcls
15:00:43 [Zakim]
15:01:12 [Zakim]
15:01:33 [ericP]
Zakim, ??P11 is agray
15:01:33 [Zakim]
+agray; got it
15:01:58 [dbooth]
dbooth has joined #hcls
15:03:24 [Zakim]
15:04:28 [Claude]
Claude has joined #hcls
15:04:50 [ericP]
Zakim, [IPcaller] is Claude
15:04:50 [Zakim]
+Claude; got it
15:06:59 [Zakim]
15:07:35 [dbooth]
Topic: Shape Expressions
15:08:32 [dbooth]
Eric: In Sept W3C had an RDF validation workshop. As outcome, a Shape Expression language that I worked on, a BNF-grammar-like way to describe how an RDF graph should work.
15:09:02 [dbooth]
... People tended to use SPARQL for validation, but terrible for implementing validation rules as a whole. Like writing a yacc parser by hand.
15:09:44 [dbooth]
... People tried hand-tooled sparql queries, sparql path expressions. OWL with CWA and unique name assumption.
15:10:31 [dbooth]
... Another language presented was Resource Shapes, from IBM; and Description Set Profile, from Dublin Core people.
15:10:51 [agray]
Description set profile
15:11:54 [dbooth]
... I've been working on Shape Expressions, which draws from those languages. It does conjunctions, disjunctions, optional groups, and more expressivity. Has an algebra: defined semantics such that for any schema and data there's a definite pass/fail answer.
15:12:13 [agray]
Shape expression
15:12:14 [dbooth]
... Designed to be similar to Relax NG.
15:12:35 [ericP]
15:12:59 [dbooth]
... Click "Test with cut" or "Test without cut" at the above link.
15:13:58 [dbooth]
... The goal is to start a WG on it. I've been working on a submission, with Harold Holbrig. Trying to get some AC reps to sign off and send in by tomorrow or the next day.
15:14:14 [dbooth]
... to have it ready for charter for RDF Validation WG
15:15:26 [dbooth]
... Use cases were around FHIR in RDF. We have a mechanical transformation of FHIR to RDF, then using Shape Expressions to convert back to XML.
15:15:42 [ericP]
-> ShEx Primer
15:15:53 [dbooth]
q+ to ask about compatibility with SPARQL
15:15:59 [ericP]
-> ShEx Examples
15:16:27 [ericP]
-> GenX example
15:16:36 [dbooth]
... and here's a GenX example (above)
15:18:01 [dbooth]
... GenX takes an RDF schema and instance data. If you load the above page and hit popup, there's a new window with transformations generated.
15:18:32 [dbooth]
... Purpose is to demo the extensibility of Shape Expressions -- you can have your own expressions in {...}
15:19:16 [dbooth]
... And the ability to turn the generated RDF back into XML. Because it didn't have 0/1 cardinality, genX is a much more declaritive way to handle this.
15:19:44 [dbooth]
... GenX uses RDF with Shape Expression to generate XML?
15:19:53 [dbooth]
Eric: Yes.
15:20:02 [dbooth]
s/... GenX/David: GenX/
15:20:40 [dbooth]
... You can also change the schema so that the state is not written as at-state but at-condition or something else.
15:21:09 [dbooth]
... In the ShEx on the left is generic ShEx except for the GenX expressions.
15:22:36 [dbooth]
q+ to ask if ShEx is really a transformation language
15:23:46 [ericP]
15:24:25 [dbooth]
15:25:06 [dbooth]
Eric: ShEx can be used as a transformation language via the actions.
15:25:49 [dbooth]
... In this case the action generated XML.
15:26:03 [dbooth]
... Regarding SPARQL, see above URL
15:28:17 [Neda]
Neda has joined #hcls
15:30:24 [dbooth]
Eric: In it uses JavaScript and SPARQL semantic extensions. When you click "View as Sparql Query" the added functionality gets stuck into the SPARQL implementation to check the order of the dates.
15:31:01 [dbooth]
... If you click the link to view as a SPARQL query, that query will validate that the dates are in the right order.
15:31:22 [dbooth]
... When you use one of these semantic extension, it is implementation dependent to support it.
15:32:24 [dbooth]
... After the WG works on this, they might add a date validation mechanism, but this illustrates extensibility.
15:34:08 [agray]
For the dataset descriptions, we need to be able to do the choice between items. "One of dct:issued or dct:created MUST be provided"
15:34:15 [dbooth]
... IBM wants to start the Validation WG. They'll most want to work with REsource Shapes, because they've been using it for years, but it doesn't have group optional, sem extension or disjunctions. I'm hoping to start with ShEx, but I expect IBM to say that it's too complicated. We'll see. I've sent the submission to several members to sign onto it. That would improve the odds of ShEx being the starting point.
15:34:53 [dbooth]
Alistair: We need disjunction.
15:36:06 [dbooth]
Eric: Some of the complexity is due to disjunction, but the majority comes from the fact that it gives you semantic actions in a particular order. Things like GenX demands those.
15:36:51 [dbooth]
... I suspect people will want known ordering.
15:37:12 [dbooth]
David: I also think extensibility is important also.
15:37:41 [dbooth]
Eric: That also came out of the workshop. Question is: what is the API promise for ext? Ordered or not?
15:37:48 [dbooth]
David: Ordered is nice.
15:38:11 [dbooth]
Eric: Yes, it also allows you to do thinks like SQL inserts.
15:38:27 [dbooth]
... List is:
15:40:06 [dbooth]
Eric: Alistair has use cases on metadata. ShEx covers most, but a couple of things are left to semantic actions: note has SHOULD/MUST/MUST NOT, and if you fail a SHOULD it will go to a sem action, for a warning.
15:40:13 [dbooth]
David: nice!
15:41:57 [dbooth]
David: Would be nice to have a cleaner simpler FHIR RDF representation, so that when people see it they'll like it. Would be nice to try ShEx for that purpose.
15:42:33 [dbooth]
... Auto-generated FHIR RDF is rather verbose at present -- not very pretty.
15:42:59 [dbooth]
15:43:36 [ericP]
15:43:59 [dbooth]
Eric: Without sem actions, there are scripts that gen ShEx for FHIR RDF.
15:44:42 [dbooth]
Eric: Hard job is round tripping from RDF back to FHIR. Need that for a good story.
15:45:00 [dbooth]
15:45:31 [Claude]
15:46:16 [dbooth]
Eric: A while ago Josh and I worked on this, making it more or less friendly to RDF heads versus FHIR heads. Whether to rename the properties of the structure that's in FHIR XML/JSON? And whether to faithfully emulate the FHIR datatypes versus more terse RDF-typed nodes.
15:47:26 [dbooth]
... There were ObjectIdentifier structures in FHIR, but in XSLT i put it out as a URL instead of a bnode with a bunch of properties. There are other opportunities for that kind of thing.
15:48:14 [dbooth]
... The question of using properties that are RDF friendly vs FHIR friendly, my inclination is to lean toward FHIR heads: underbars in names instead of camelCase.
15:49:12 [dbooth]
David: Fine. I'm more concerned about ugly structures, like bnodes with a bunch of properties instead of a simple URL.
15:49:43 [dbooth]
Eric: We created this a while ago, then Claude started working on an ont for this. Ideally the ont and data that we're producing should be aligned.
15:50:09 [dbooth]
... Now we're more concerned with the subsumption rules.
15:50:22 [dbooth]
15:50:35 [dbooth]
Claude is screen sharing at
15:51:04 [dbooth]
Claude: Concern that I have, looking for feedback: I'm taking FHIR concepts and modeling them in an ont.
15:51:28 [dbooth]
... Didn't want to add any hierarchy that wasn't already there in FHIR.
15:52:25 [dbooth]
... Want to discuss FHIR extension mechanism, and building an ont, need to figure out the intent and audience.
15:52:59 [dbooth]
... My assumption: desire for clinical sem representation, and FHIR is the next gen of models from HL7, but that's where it ends.
15:53:29 [dbooth]
... When you think of a clinical model, it's to maximize interop. So it's designed to be extended in a generic fashion.
15:54:25 [dbooth]
... Designed for closed world. Very strong constraints. I think an OWL ont for FHIR should inform itself on FHIR, but not necessarily tied to HL7 use cases for FHIR. Should look at FHIR as a common core, but in semantic world it's an open world.
15:54:45 [dbooth]
... Core ontology could be extended, would support open world.
15:55:20 [dbooth]
... Two areas to address: 1. extensibility of FHIR; 2. constraining via profiles.
15:56:00 [dbooth]
... Extensions have an element w a URL that uniquely identifies that extension. That extension can contain other extensions. Or the value can be a code.
15:56:22 [dbooth]
... That's attribute extension.
15:57:04 [dbooth]
... The other approach is the Other concept. It has an identifier, and author and a created date. This is how you add new concepts in FHIR.
15:57:22 [dbooth]
... if you have a library of core FHIR resources, the existing library should still be able to parse it.
15:58:47 [dbooth]
... This extension mechanism, but if you use a semantic KR approach, it's very awkward because extensibility in a semantic world is part of the fabric of that world.
16:00:04 [dbooth]
... My proposed approach would be a core ont with extension points. And when you want to add new properties to a concept, instead of using the FHIR approach, you just use the predicate, create an ont that imports the core ont and add that extension.
16:01:14 [dbooth]
Eric: If I want to add a property "OrganDonor" to a Person, is it an open content model or closed? Non-monotonic changes? Can I add any property I want?
16:01:45 [dbooth]
... FHIR XML as specified, can I add any element I want to a resource?
16:01:59 [dbooth]
Claude: Yes, but you have to follow that structure.
16:04:23 [dbooth]
... I defined an extension property, which would never be used directly, but would then define a new ont with OrganDonor that imports the core ont.
16:05:44 [dbooth]
... This allows that property to be recognized as an extension property, rather than using the FHIR approach. Then if you want to add new concepts, there's an Other concept, and you define the new concept as a subclass of that in your new ont.
16:07:04 [dbooth]
... The alternative, how FHIR does it, is you'd have a node of type Extension, where you add attributes. Suppose you want to add a new string value to Person. You'd have to name it "value...". It's pre-coordinated.
16:07:34 [dbooth]
... Even primitive types are extensible. You'd have to represent all of the FHIR types are extensible.
16:08:18 [Neda]
Neda has joined #hcls
16:09:21 [dbooth]
s/FHIR types are extensible/FHIR types as classes/
16:09:35 [dbooth]
Eric: Suppose we skip the extensible types?
16:10:25 [dbooth]
Claude: yes, we could.
16:12:39 [dbooth]
Eric: Does their model require you to have an extension? Do they think of themselves as having an extension? If I put an XML extension element into Person, and I say it's got a URL and a value, to what degree do they think creating an ext and giving it a value versus ....
16:13:02 [dbooth]
... In RDF, we just add properties, we don't think of creating an extension. But in FHIR they create extensions.
16:13:30 [dbooth]
Claude: But the reason they do this is because one requirement is that if they see a new concept they don't want to modify their data models.
16:15:01 [dbooth]
... If you have multiple extensions, I don't think it would be hard to add the classes formally. And if you need to use this generic approach and say it inherits from Other, when serializing to XML all predicates can be standard extension.
16:15:13 [dbooth]
Eric: So GenX might be able to spit that back out as XML.
16:16:01 [dbooth]
Eric: A reason for having Element name extension and properties encoded in the URL of that extension, is that you still have a closed concept model.
16:16:26 [dbooth]
zakim, mute neda
16:16:26 [Zakim]
neda should now be muted
16:17:34 [dbooth]
16:18:29 [dbooth]
Eric: In RDF we're doing the same job by saying "this is derived from Extension".
16:20:12 [dbooth]
David: ShEx could indicate what's supposed to be there. And when you add an extension, you could supply a ShEx to indicate what else is supposed to be there.
16:21:39 [dbooth]
Claude: How do you express a constraint in RDF? Suppose I have Person and a datatype property isOrganDonor, and it's boolean.
16:22:27 [dbooth]
... In FHIR this is done by saying Person is an extension [ valueBoolean true, .. and maybe an other extension ]
16:22:36 [dbooth]
... This is if you translated XML to RDF w bnodes.
16:23:09 [dbooth]
... "Person dt:name STRING Nanjo, Claude " in RDF
16:24:05 [dbooth]
... But in FHIR you'd say: Person extension ]valueString Nanjo,Claude, extension [ uri: parsingFormat ; valueString lastName,givenname*
16:25:43 [dbooth]
... I think the reason ISO 21090 doesn't just say something is a string, it adds 20 other attributes to help you understand it. But since FHIR didn't want to be burdened that, it gives you simple datatypes and let's you extend it to do things like that.
16:26:48 [dbooth]
... Could we say: Person dt:name [ value "Nanjo, Claude", parsingFormat "SN, GN*"]
16:26:56 [dbooth]
... and that would follow stadnard OWL approaches.
16:27:33 [dbooth]
... The other approach would be to say: Person dt:name xs:string ; and Person dt:nameFormat xs:string.
16:28:00 [dbooth]
Eric: You lose the vapid value property.
16:28:34 [dbooth]
... You could do either one.
16:29:50 [dbooth]
Eric: I like some properties of both of those approaches.
16:30:20 [ericP]
16:31:45 [ericP]
16:32:49 [dbooth]
Eric: In FDA workk we've been doing, there's a concept of Observation. There's a code for it, might use SNOMED or LOINC to say serum creatinine level.
16:33:19 [dbooth]
... There aren't any constraints on the codes or values.
16:33:49 [dbooth]
... That means that peopel get to do whatever coding system they want, and they're promising a serum creatinine test.
16:34:03 [dbooth]
... So blank node that you're generating could have a useful label.
16:34:27 [dbooth]
... For strings you're less likely to have two different people asserting the same things on strings.
16:34:42 [dbooth]
(See pirate pad nodes: )
16:41:33 [dbooth]
Claude: Do we want to support both ways in OWL, the FHIR way and the RDF-way?
16:43:18 [dbooth]
David: Prefer the simplest way.
16:43:42 [egonw__]
egonw__ has joined #HCLS
16:44:44 [dbooth]
Claude: Someone could add a 'NOT' extension that would negate the meaning.
16:45:35 [dbooth]
... Any attribute that dramatically changes the semantics of the class is a problem.
16:47:30 [dbooth]
David: Want it to look simple and easy in RDF, so that people can look at it and say "hey, that's not bad". We want to gain RDF acceptance.
16:48:20 [dbooth]
Eric: Were there use cases where desirable naive interpretation was enabled in XML but disabled in RDF?
16:48:47 [dbooth]
... Don't want to show them nice RDF that disables some of their use cases.
16:49:16 [dbooth]
... There are some people already sympathetic to RDF, but we'd better not throw away serious use cases.
16:49:49 [dbooth]
Claude: I suspect expressivity to be stronger in OWL than XML.
16:51:07 [dbooth]
... I could have adverse event, which has an agent 0..*. But if the adverse event is a reaction, then it must have an agent. That's a need for a profile.
16:51:25 [dbooth]
... Another is a problem code can only be bound to this value set.
16:52:41 [dbooth]
David: What about closed content model? Not yet sure if this is being sufficiently addressed in RDF.
16:53:34 [dbooth]
Claude: Next time: profiles.
16:53:41 [Zakim]
17:02:21 [dbooth]
Meeting: HCLS
17:02:24 [dbooth]
Chair: EricP
17:02:31 [dbooth]
17:02:39 [dbooth]
rrsagent, draft minutes
17:02:39 [RRSAgent]
I have made the request to generate dbooth
17:02:55 [Zakim]
17:02:56 [Zakim]
17:02:57 [Zakim]
17:04:45 [dbooth]
rrsagent, make logs public
17:05:30 [dbooth]
Present: Alistair Claude DBooth David Eric IPcaller P11 agray egonw__ ericP https neda
17:05:42 [dbooth]
rrsagent, draft minutes
17:05:42 [RRSAgent]
I have made the request to generate dbooth
17:07:06 [egonw]
mscottm: you saw there will be a European location for the Network of BioThings hackathon? In Maastricht, in fact?
17:07:58 [Zakim]
disconnecting the lone participant, agray, in SW_HCLS()11:00AM
17:08:00 [Zakim]
SW_HCLS()11:00AM has ended
17:08:00 [Zakim]
Attendees were ericP, DBooth, agray, Claude, neda
17:44:09 [mscottm]
mscottm has joined #hcls
18:46:29 [Zakim]
Zakim has left #hcls
18:47:07 [ericP]
RRSAgent, please draft minutes
18:47:07 [RRSAgent]
I have made the request to generate ericP
21:18:35 [mscottm]
mscottm has joined #hcls
22:45:48 [mscottm]
mscottm has joined #hcls