See also: IRC log
<trackbot> Date: 30 December 2014
<drjava> Test
<drjava> Drjava is peter hendler
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20141223
Resolved: Minutes appoved
<Claude> https://global.gotomeeting.com/join/157514853
<scribe> ACTION: Guoqian to figure out whether he can share URI conventions for ICD-11 [recorded in http://www.w3.org/2014/11/25-hcls-minutes.html#action07] -- DONE
<trackbot> Created ACTION-15 - Figure out whether he can share uri conventions for icd-11 [recorded in http://www.w3.org/2014/11/25-hcls-minutes.html#action07] -- done [on Guoqian Jiang - due 2015-01-06].
<scribe> ACTION: [PENDING] Kerstin and Ingeborg to prepare a status and future state ideas for PhUSE-FDA work [recorded in http://www.w3.org/2014/11/18-hcls-minutes.html#action05]
<scribe> ACTION: Tony to find out more details about how iCat handles ICD-11 ont and report back [recorded in http://www.w3.org/2014/11/18-hcls-minutes.html#action01] -- DONE
<trackbot> Error finding 'Tony'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
Tony: Proceeding on high level concepts work. Paper being formulated. Starting to compare different approaches: Eric &Josh, Cecil, Tony, Claude's work.
http://www.hl7.org/events/wgm012015/
<Tony> Link to High Level Mapping http://wiki.hl7.org/index.php?title=FHIR_RDF_Mapping
David: Others interested in exploring the JSON-LD route?
Claude: Represent Josh and Eric's RDF as JSON-LD?
David: JSON-LD could influence the FHIR ontology choices
Tony: How widely supported is JSON-LD yet?
<inserted> Scott: (voiced support for JSON-LD)
lloyd: fine with JSON-LD approach
because it removes discussion about what RDF would look like.
And if we could add a single @context we may get that accepted
as part of standard JSON syntax -- always there by
default.
... Then we could add an appropriate RDF processor to auto
consume and expose other RDF syntaxes also.
... Lots of benefits, though not essential. Could do massive
conversion to RDF, but shouldn't do that if we don't need
to.
David: I'll work on JSON-LD. Anyone else want to help?
Scott: Also interested, though
more as a consumer than developer of it.
... I have radiotherapy use cases.
http://wiki.hl7.org/index.php?title=FHIR_Ontology_Requirements
"1. (MUST?) We must define mappings from FHIR XML/JSON to FHIR RDF instance data and vice versa, and an OWL/RDFS ontology for the structure and semantics of that RDF instance data. "
lloyd: Suggest merging #1 and #3.
tony: RDF might have extra information that is not essential to the JSON
lloyd: the same information must be round trippable, so the RDF cannot have any extra info.
<ericP> Lloyd, my guess is this will sort itself out. it seems that if there are some constant triples added to the RDF model to facilitate logic for inference cases not met by the XML, it can be removed when being mapped back without any practical impact.
David: Suppose FHIR JSON is sent to me, I turn it into RDF and add some other non-FHIR RDF data to it, and then send it back. The result has both FHIR data and non-FHIR data.
lloyd: That extra data needs to be turned back into FHIR JSON using the FHIR extension mechanisms.
tony: Example would be a reference to a type, pointing to the metadata. That could be part of the RDF but not JSON.
lloyd: When it goes back into RDF
the type would come back, right?
... It would have to be a type based on the resource, not a
profile, because the profile may not be available.
... Going between XML and JSON there's no information added.
Simiilarly the RDF <-> XML/JSON must not add or lose
information.
... Resources are the base units of exchange -- Observation,
Medications, etc. But there are also additional Profiles that
further stipulate what a blood pressure should look like, or a
dental procedure should look like.
... There will be 10s of thousands of profiles.
... All implementors should be aware of all of the Resources
(but not all of the profiles).
... Profiles can be created by anyone at any time.
... So the conversion cannot depend on them.
Paul: Profiles can change cardinality but not datatype.
lloyd: Profiles can be conveyed
in an instance.
... We can do that in RDF also. We'd want to be cautious about
exposing that to reasoning.
Paul: It wouldn't be valuable to expose it to a reasoner. It may not be there.
lloyd: My concern is that it 's not guarnteed to be correct. You can make an assertion that an instance is valid against profile X, when in fact it is not.
guoqian: Meaningful to validate instance data against its declared profile.
lloyd: If an instance does not
validate against its declared profile then it is invalid, but
the recipient might still process it.
... So if the reasoner validates that, it may be more
difficult.
claude: If a resource specifies a profile, but the instance data does not conform to that profile, is that a valid instance?
lloyd: you should conform to it, and it's an error if you don't. But it's still possible to process the instance.
paul: the sender of the instance
may put on a profile, and the receiver may validate against it.
A separate circumstance is that the sender didn't send a
profile, and the recipient adds one, then it does not seem
meaningful.
... We should separate those two cases.
lloyd: In a profile you may have
something that says there are 3 repetitions of a code, bound to
particular code sets.
... In the instance you would specify the profile, but the
types would not be declared inside the instance. They would be
declared in the profiles.
... Important that we not expose more than what's in the
JSON/XML. You may need to reason against the profile, beyond
what's in the instance.
<mscottm> Would creating a use case (straw man) example in RDF/JSON/XML/OWL be something we could do for future discussions of this sort? I think these discussions would be much more grounded in the context of an actual profile and instance that we adapt to the scenario being discussed. Is that feasible?
lloyd: If you have an instance that its declared valid against 3 different profiles, you can strip the profile declarations without loss, as long as you have a list of profiles of interest, you can check the instances against profiles to see which it conforms to.
Paul: But you lose intent.
... Profile is merely providing constraints.
David: I thought profile was also
conveying intent.
... Please propose specific rewording suggestions for #1 and
#3.
Scott: Would help to see examples when discussing this, to help ground the discussion.
ADJOURNED
rssagent, draft minutes
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i/lloyd:/Scott: (voiced support for JSON-LD) Succeeded: s/Please respond to Participation survey// Succeeded: s/Topic: /TOPIC: /g Succeeded: s/Topic:// No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Default Present: DBooth, +1.978.794.aaaa, Tony, +1.604.250.aabb, pknapp, holger, +1.202.528.aacc, Ingeborg, +1.510.418.aadd, PeterHendler, Claude, +31.62.427.aaee, mscottm, Lloyd, +1.507.261.aaff, Guoqian, ericP, +1.801.949.aagg, rhausam Present: Claude_Nanjo David_Booth Eric_P Guoqian_Jiang Holger_Stenzhorn Ingeborg Lloyd_McKenzie mscottm Peter_Hendler Paul_Knapp Rob_Hausam Tony_Mallia Found Date: 30 Dec 2014 Guessing minutes URL: http://www.w3.org/2014/12/30-hcls-minutes.html People with action items: ingeborg kerstin[End of scribe.perl diagnostic output]