See also: IRC log
http://wiki.hl7.org/index.php?title=File:FHIR_RDF_Sample_side_by_side_comparisons.pdf
Will be there: Harold, David
Will not be there: Tony
http://wiki.hl7.org/index.php?title=File:FHIR_RDF_Sample_side_by_side_comparisons.pdf
Tony: Diagram on line 134
... CodeableConcept has Codings, and a Coding has code.
... The blue lines say that ConceptBase is a superclass of
CodeableConcept, Coding and code.
... Since a ConceptBase has an object property to CodingBase,
which has an object property from Coding, therefore Coding and
code have a ConceptBase.coding relationship to CodingBase
.
<scribe> ACTION: Tony to update the ConceptBase etc diagram with annotations [recorded in http://www.w3.org/2015/12/01-hcls-minutes.html#action01]
<trackbot> Error finding 'Tony'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
<scribe> ACTION: DBooth to work with Tony on further refining the diagram [recorded in http://www.w3.org/2015/12/01-hcls-minutes.html#action02]
<trackbot> Created ACTION-39 - Work with tony on further refining the diagram [on David Booth - due 2015-12-08].
http://wiki.hl7.org/index.php?title=File:FHIR_RDF_Sample_side_by_side_comparisons.pdf
line 834
DBooth: Line 50 is inferred from
849, but I do not think this is a kind of inference that OWL
can do.
... I don't think line 850 should be required on the wire for
FHIR RDF: fhir:Reference.link <http://record/Patient/PeterPatient>
eric: the problem is that the value on line 849 is in quotes.
dbooth: Is that datatype sufficiently restricted that we can make that a URI instead of a string?
harold: Not all URIs will be
directly dereferenceable.
... The notion of the URI as a string is a useful abstraction,
because there may be additional machinery that turns the string
into a URI node.
dbooth: Two separate issues: 1. whether it is a string or a URI node in RDF; 2. whether that URI is dereferenceable in RDF.
eric: Third issue is how to
identify the appropriate node in the graph that you get
back.
... What comes back is a blank node -- not a named URI.
... Some people object to using the same URI for a named graph
and a distinguished URI within that graph.
tony: The file that is returned is not equivalent to the root object.
eric: My old XSLT turns bundles into atoms.
https://hl7-fhir.github.io/allergyintolerance.html
https://hl7-fhir.github.io/allergyintolerance-definitions.html#AllergyIntolerance.patient
https://hl7-fhir.github.io/references.html#Reference
https://hl7-fhir.github.io/references-definitions.html#Reference.reference
But the definition describes it as a URL.
[[ A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.
]]
dbooth: It seems like it would be useful to have line 849 be an RDF URI node (instead of string). Would there be harm in doing so?
Eric: Some zealots would object to using a URI node for the dereferenceable thing and the patient record.
dbooth: I do not see how we could derive a new (different) URI on line 850 from the URI on line 849, because the URI on line 849 is explicitly permitted to have fragIDs already.
eric: If the root node is a blank node, there are other things inside that are relative to it, which are identified by fragIDs. That implies that FHIR already made the decision for us, to use the same URI for the endpoint and the root node.
tony: When we drill into FHIR bundles, that may help us to sort this out.
ISSUE: Should fhir:Reference.reference->value be a string or an RDF URI node?
<trackbot> Created ISSUE-16 - Should fhir:reference.reference->value be a string or an rdf uri node?. Please complete additional details at <http://www.w3.org/2014/HCLS/track/issues/16/edit>.
ISSUE: Should the rdf:types be explicit on the wire or inferred?
<trackbot> Created ISSUE-17 - Should the rdf:types be explicit on the wire or inferred?. Please complete additional details at <http://www.w3.org/2014/HCLS/track/issues/17/edit>.
dbooth: I like having the rdf:types there, because they are convenient. If they are not there, then a reasoner must be run before manipulating the RDF.
eric: Propose making it optional, but make the XSLT generate it as a teaching aid.
harold: I think type will be required if we are dealing with extensions.
eric: When you get XML or JSON, the top says "I'm a patient".
tony: I cannot make it today
dbooth: Let's cancel it today.
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: s/whether you can/how to/ No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Present: David_Booth Eric_P Darrel_Woelk Harold_Solbrig Tony_Mallia Found Date: 01 Dec 2015 Guessing minutes URL: http://www.w3.org/2015/12/01-hcls-minutes.html People with action items: dbooth tony[End of scribe.perl diagnostic output]