See also: IRC log
<ericP> http://w3c.github.io/hcls-fhir-rdf/spec/rdf#rdf-data-for-codeable-concept-instance
eric: suggest recording RDF syntax decisions using ShEx
http://w3c.github.io/hcls-fhir-rdf/spec/rdf#rdf-data-for-codeable-concept-instance
like that
that's an example of how it would be written
eric: advantages: it is testable and specifies general case, not just one example
tony: We should have an example also, not only shex
dbooth: agreed
(eric walks us through the example at http://w3c.github.io/hcls-fhir-rdf/spec/rdf#rdf-data-for-codeable-concept-instance )
<ericP> <codingShape> {
<ericP> a [fhir:CodingBase]?,
<ericP> fhir:CodingBase.code @<extensibleLiteral>?,
<ericP> fhir:CodingBase.system @<extensibleLiteral>?,
<ericP> fhir:CodingBase.display @<extensibleLiteral>?
<ericP> }
<ericP> <extensibleLiteral> { fhir:value LITERAL }
harold: fhir:codeBase should be
fhir:code
... if extensibleLiteral is extended, how do I say what type it
is?
eric: We don't do a type code for the extension
<ericP> fhir:CodingBase.code [ my:someExtension [ fhir:value "another turtle" ] ; fhir:value "90614001" ] ;
dbooth: it will only have the extension URI?
eric: yes
dbooth: my:someExtension needs to have some marking from the standard FHIR namespace to be recognizable for round tripping
harold: what came of version and userSelected attributes?
eric: Haven't looked at them.
harold: They're mandating a version when using SNOMED-CT
eric: people using SNOMED are expected to keep track of versinos
harold: no, it says "note that
the following systems SHOULD have the version specified . . .
"
... And userSelected has an intent that says it was the one
that the user actually put in.
... "if a userSelected exists, it is *the* code preferred"
which implies that cardinality is max 1
http://w3c.github.io/hcls-fhir-rdf/spec/rdf#rdf-data-for-codeable-concept-instance
eric: Should we use a generic
extensibleLiteral, or specific kinds, or should it be
specifically typed?
... My preferences is generic because it's simpler, and we can
infer their type from context.
dbooth: so the choice is in the ShEx schema for something like fhir:CodingBase.code, should it have a specific name for each type or be generic?
example:
<codingShape> {
a [fhir:CodingBase]?,
fhir: CodingBase.code
@<codingBaseCodeExtensibleLiteral>?,
... CodingBase.system
@<codingBaseSystemExtensibleLiteral>?,
... CodingBase.display
@<codingBaseDisplayExtensibleLiteral>?
}
harold: We would have to do that for every variable in the system!
<Sajjad> Generic Approach: <codingShape> { a [fhir:CodingBase]?, fhir:CodingBase.code @<extensibleLiteral>?, fhir:CodingBase.system @<extensibleLiteral>?, fhir:CodingBase.display @<extensibleLiteral>? }
RESOLUTION: We will use the generic extensibleLiteral construct in ShEx unless/until we discover it does not work
RESOLUTION: We will write our RDF syntax decisions both as examples and in ShEx
Related to https://github.com/w3c/hcls-fhir-rdf/issues/18
https://hl7-fhir.github.io/allergyintolerance-example.ttl.html
tony: In that example, it has a
fhir:Resource.id (with a value of "example") then the RDF
resource root node needs to be a URI
... I tried that example in protege and it loads fine, but you
cannot reference it from elsewhere.
... There are two options: 1. Instead of _:example you make it
a URI; or 2. a prefixed URI .
eric: When this is in use, a
system could easily serve things that say <> (relative
URI), so it would be easy to not have to figure out a full URI
for that document.
... RDF only has blank nodes or absolute URIs. But
serializations can have relative URIs, in which case the base
URI does not need to be included in the document because the
Turtle parser will fill it in.
... In common usage, most FHIR engines won't need any base URI
embedded.
tony: Relative URI would mean that the identity of the resource changes from place to place.
harold: agree
dbooth: Concerned about round tripping. Grahame very clearly said that the resource will not always have an identity: https://lists.w3.org/Archives/Public/public-semweb-lifesci/2016Mar/0010.html
tony: if the resource root is a blank node then you cannot have closure when graphs are loaded into protege
eric: i think you mean unification
tony: I mean the loading logic.
<Sajjad> The blank node identifiers are only limited in scope to a serialization of a particular RDF graph. So, as long as the whole RDF serialization is 'one' RDF graph, we should be ok with a blank-node
eric: If you have an identifier
in two graphs, and they both talk about a patient . . . if you
have an identifier then you want to name the patient by that
ID, and the ID is repeated: the resource root and the ID
property of that resource root.
... Or we could reference the root node indirectly through its
ID property.
tony: but each resource is a different graph
eric: We need an absolute identifier somewhere -- not necessarily the resource root, but it requires chained properties.
<Sajjad> two blank-nodes in two different RDF grahs are actually two different entities (even though both have same properties and objects). One can still work around it, by establisting a owl:sameAs between the two blank-nodes
tony: In some cases FHIR defines
a URI for the resource root node, and in other cases it is
anonymous -- a blank node.
... In the case where FHIR defines a URI for the resource, the
question is, what should the RDF rresource root node be
called?
https://hl7-fhir.github.io/allergyintolerance-example.ttl.html
dbooth: is that the one that you
loaded into protege?
... Did it start with '_:example a fhir:AllergyIntolerance;' ?
Tony: yes.
tony: It loaded properly, but i
could not reference it from another graph because it is a blank
node.
... If it has a fhir:Resource.id then it should instead be a
URI, so that it can be referenced from elsewhere
dbooth: when trying to reference it from elsewhere, what are you trying to do?
tony: I want to make a FHIR reference to it.
dbooth: so you want to do something like this? fhir:Reference.reference [ fhir:value "Practitioner/example" ]
tony: actually it's a fhir:Reference.link
https://hl7-fhir.github.io/patient-example-a.ttl.html
<Sajjad> Just FYI: one can use e:tuple builtin, using the EYE engine, to obtain a so called 'named entity' as a unique skolem-funtion drives the blank-node
<Sajjad> e:tuple a rdf:Property, e:Builtin; rdfs:comment "built-in skolem function generator typically used with a subject that will get bound to a unique blank node which is a function of the object tuple"; rdfs:domain rdfs:Resource; rdfs:range rdf:List.
sajjad: Two blank nodes in different graphs are different, but you can reference between them if you use skolem URIs
dbooth: We need a concise example showing the exact problem.
ADJOURNED
github: http://w3c.github.io/hcls-fhir-rdf/spec/
https://github.com/w3c/hcls-fhir-rdf
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) No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Present: David_Booth EricP Rob_Hausam Sajjad_Hussain Thomas_Lukasik Harold_Solbrig Tony_Mallia Found Date: 15 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/15-hcls-minutes.html People with action items:[End of scribe.perl diagnostic output]