Modify the FHIR spec build process to produce RDF artifacts -- Who and how?

https://github.com/w3c/hcls-fhir-rdf/issues/7

tony: Will the build process produce the RDF artifact?

lloyd: Yes. A few changes needed: 1. reference implementations, Java, C#, swift, Delphi Pascal, need to be updated to produce and consume RDF
... That's the set of code that knows how to parse/serialize the FHIR XML, JSON and now RDF
... Those get referenced in the build process
... The build process generates Java code, C# code, Delphi code, etc.
... It takes the definitions of the resources and turns that into class representations in the different languages to parse/serialize XML and JSON. We need to add RDF to that list.
... The Java implementation is then used in the build process to convert examples from XML to JSON, and we'll use it to generate the examples in RDF.

dbooth: That's instance data that is being parsed and serialized by the reference implementations.

tony: How's the XML Schema built?

lloyd: Generated by other java code. Takes the internal object representation and puts out the schema.
... Two choices: Follow the same path as schema generation (Java) or use XSLT.

tony: ShEx?

lloyd: Reluctant, because of the number of people who can maintain ShEx

dbooth: Build process itself is written in Java?

lloyd: yes
... 1. need to update the reference impl. 2. Update the build process to generate the RDF examples 3. Modify the build tool's round trip tests 4. update the publication process, so that when you look at the list of examples you see the RDF alongside the XML and JSON 5. Generate the OWL for structure definitions for resources, datatypes and profiles, and expose that in the publication 6. Package the OWL into a zip file and make it accessible on the downloa

ds page. 7. Generate the OWL for the valuesets, which is different from what we've done before. No schemas for them, but we'll have OWL for them.

lloyd: Concept maps out of scope? We can bring that in release 2.
... If we want to expose ShEx definitions then we need to generate those for structure defs and valuesets, and expose that in the publications. Need to figure out whether ShEx is a ref impl or closer to schema.

ISSUE: Should ShEx be a reference implementation or a schema?

<trackbot> Created ISSUE-19 - Should shex be a reference implementation or a schema?. Please complete additional details at <http://www.w3.org/2014/HCLS/track/issues/19/edit>.

lloyd: There's code that generates: 1. resoruce pages. 2. resource examples page. 3. Datatypes page 4. Profile page
... That java code will have to be tweaked to show either a link to the OWL or RDF, depending.
... In addition, there's code that generates zip files, and we'll want to add a zip file with all the OWL.
... We'll also want to modify the zip file of examples to include RDF with the XML and JSON.
... There's also a static HTML page, downloads.html, and we'll need to edit that to add a link to the ontology.zip that we'll produce.

dbooth (to eric): Should ShEx be a reference implementation or a schema?

eric: more of a schema. But there is also ShEx as handy tools to parse XML to RDF.

<inserted> eric: There's XSLT that converts FHIR XML to FHIR RDF

lloyd: We provide code people might want to use. The differentiator is whether it is executable.
... We have links to those extra tools now, but the intent is that it will move to fhir.org along with other tools that others may contribute.
... Ref impl do parsing, serializing, validation, simple clients that know how to manage the HTTP server calls
... XSLT is not a full ref impl :)

eric: Hoping to use the ShEx and XSLT scripts to validate our definitions
... Could figure out later whether to include it as a ref impl

lloyd: My view is that we'll modify the code generators to produce Java, C# and Delphi to natively consume/produce RDF.
... But there may be other more esoteric languages that choose to implement only the XML and JSON, but use the XSLT transform for the RDF piece.

Our deliverables: http://wiki.hl7.org/index.php?title=RDF_for_Semantic_Interoperability#Deliverables_and_Editors

lloyd: Anyone who wants commit privileges to modify the build tool should email me and agree to the HL7 policies.

dbooth: has Michael Van Der Zel done that yet?

lloyd: He's an observer now.

dbooth: Michael signed up for deliverable #5 Modify the FHIR spec build process. I'll point him to this discussion and see what he is able to do.

<scribe> ACTION: David to transfer these notes about deliverables to the wiki [recorded in http://www.w3.org/2016/02/16-hcls-minutes.html#action01]

<trackbot> 'David' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dbooth, dderour, dhansen2, dnewman, dshotton).

Should we change fhir:index from origin 1 to origin 0?

https://github.com/w3c/hcls-fhir-rdf/issues/5

dbooth: I think we shoudl change to origin 0 to be consistent

eric: Propose we go with 0.

rob: Sounds compelling

tony: Easy to change in the OWL

Seems to be informal consensus to use origin 0

RESOLUTION: Informal consensus to change fhir:index from origin 1 to origin 0 (to be confirmed when we have official quorum with ITS chair)

Issues list

https://github.com/w3c/hcls-fhir-rdf/issues

https://www.w3.org/2014/HCLS/track/issues

What should be the media type for FHIR RDF in Turtle or other serializations?

https://github.com/w3c/hcls-fhir-rdf/issues/4

eric: What are XML and JSON media types?

lloyd: application/xml+fhir and application/json+fhir

eric: registered?

lloyd: that was assigned to ITS group. Not sure they've done anything yet

eric: There's an RFC about using foo+xml. That allows a doc to be rendered as XML if the browser doesn't know foo.

lloyd: Grahame knows the full history.

eric: I suspect the registration process will be the gating process. if you try to use "+" in a way that is different from sticking XML at the end, they'll balk.
... We have a Turtle media type and for RDF/XML
... Turtle is text/turtle
... It means that linefeed conversions are allowed.
... My guess is that you'll get pushback for application/xml+fhir and they'll push it back to application/fhir+xml
... And to follow that for turtle: text/fhir+turtle , but that would set a new precedence, because a lot of tools would not immediately recognize it as Turtle. Maybe this would be an opportunity to establish that as a precedent.

dbooth: Choice between trying to push the world forward to use text/fhir+turtle or go with the flow and use generic text/turtle.
... The recipient can look at the content to see what it is. That's part of the beauty of using URIs in RDF as unique identifiers.

tony: We have a clause in requirements about existing tools, so we should not require changes to tools.

lloyd: For turtle, i'm not sure we'll have an issue. If we want to be able to extract any of the other RDF syntaxes. If the data is serialized in JSON-LD it might cause confusion.

eric: The media type for JSON-LD is different from plain JSON.
... Need to also differentiate RDF/XML from FHIR XML.

JSON-LD has a specific media type: application/ld+json

dbooth: Less pain if we stick with text/Turtle

tony: We should require only Turtle.

eric: Another issue: Easier to represent things in Turtle than RDF/XML.

Agreed: We'll only address Turtle.

dbooth: Should we agree on text/turtle as media type?

lloyd: The question is whether anyone would have an endpoint that coudl serve both FHIR Turtle and other Turtle.

tony: Turtle file extension? Eric: .ttl

<scribe> ACTION: David to ask Grahame if he sees any problem in using text/turtle as media type [recorded in http://www.w3.org/2016/02/16-hcls-minutes.html#action02]

<trackbot> 'David' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dbooth, dderour, dhansen2, dnewman, dshotton).

ADJOURNED

RESOLUTION: Turtle will be the only RDF serialization we address for FHIR

5pm Call

geeking about headsets. Harold loves his Logitech H800.

eric: the only downside: the mic is on the right side, which makes it hard to eat with chopsticks if you're right handed.

Root element type should be stated explicitly

https://github.com/w3c/hcls-fhir-rdf/issues/8

lloyd: How does someone round tripping differentiate the profile declaration from the resource declaration?
... When round tripping back from RDF to JSON (for example), how do I know which type to put into the JSON resourceType property?

dbooth: Profile type is <http://PatientSafetyProfile/AllergyIntolerance>
... but resource type needs to be stated explicitly too, in a recognizable way.

tony: the root XML tag is the same as the type name.

lloyd: We may have fhir:AllergyIntolerance and fhir:AllergyIntoleranceAwesome (profile).
... The profile URI will appear more than one place (both in meta and as top resource type).
... Or we could could have an explicit statement statement saying which it is.
... We have discussed allowing non-HL7-defined resources. In the JSON world that might need to have a URI.
... But don't need to worry about that right now.

In XML:

<AllergyIntolerance xmlns=http://hl7.org/fhir >

In Turtle:

<http://record/AllergyIntolerance/1> a fhir:AllergyIntolerance .

<http://record/AllergyIntolerance/1> a fhir:AllergyIntoleranceAwesome .

<http://record/AllergyIntolerance/1> fhir:resourceType fhir:AllergyIntolerance .

lloyd: You always serialize to the resourceType -- not the profile.
... But the instance will also be valid against the profile.

eric: what if I'm serializing an AllergyIntoleranceAwesome that has an extension? Still serialized the same? Lloyd: Yes.

dbooth: I think fhir:resourceType value of fhir:AllergyIntolerance would be easier for RDF than having a literal value of "AllergyIntolerance", because it will match the rdf:type immediately.

eric: String values that different would be known to be disjoint by OWL though, whereas URIs would not.
... If I have a literal in my data, if I have good data there will be identifiers for "p53", whereas if I am looking for a string I can easily be confused. Whereas if it is a URI http://example/.../p53 then it is unique.

lloyd: my expectation is that in the declaration of the fhir:AllergyIntolerance type, it will say that all instances have a fhir:resourceType "AllergyIntolerance" .

harold: Agree with using a string: "AllergyIntolerance"

tony: "AllergyIntolerance"

lloyd: "AllergyIntolerance"

dbooth: fhir:AllergyIntolerance

eric: fhir:AllergyIntolerance

lloyd: The conversion to RDF might involve non-simple URI mappings.
... In conformance.html https://hl7-fhir.github.io/conformance.html searchParam shows up twice, and they are the same. It's the type of searchParam inside the resource, and in REST.
... So the type name is not necessarily the path name.

dbooth: I would think it would have two path names with the same meaning

lloyd: We could do that -- alias them. When we do code generation in the java or c# space, there will be only one class define.

dbooth: Could define them as being equivalent classes in OWL.

lloyd: If you're generating RDF, then it's not an issue, but if you're doing something else it might.

tony: What does an XML conformance resource get translated into?

lloyd: Conformance deals with the dynamic behavior of the system. Structure def is static.
... instances of conformance resources will get translated from FHIR XML to FHIR RDF.

eric: Use case for conformance?

lloyd: Every system that wants to claim FHIR conformance must have an instance that says what it does.
... It's also used to define general capabilities. If you're defining an implementation guide, it may say the capabilities.
... you can also reference them in RFPs, for example. Also used for dynamic configuration.

RESOLUTION: Add a data property fhir:resourceType with string value such as "AllergyIntolerance ", attached to the root instance element.

<scribe> Closed github issue #8: https://github.com/w3c/hcls-fhir-rdf/issues/8

ADJOURNED

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: i/We provide/eric: There's XSLT that converts FHIR XML to FHIR RDF
Succeeded: i/topic: Issues list/RESOLVED: Informal consensus to change fhir:index from origin 1 to origin 0 (to be confirmed when we have official quorum with ITS chair)
No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth

WARNING: Replacing previous Present list. (Old list: Rob_Hausam, Tony_Mallia, Thomas_Lukasik, Lloyd_McKenzie, Brian, Pech, Darrell_Woelk, EricP)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Rob_Hausam, Tony_Mallia, David_Booth, Lloyd_McKenzie, EricP

Present: Rob_Hausam Tony_Mallia David_Booth Lloyd_McKenzie EricP Thomas_Lukasik Brian Pech Darrell_Woelk
Found Date: 16 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/16-hcls-minutes.html
People with action items: david