See also: IRC log
https://hl7-fhir.github.io/allergyintolerance-example.ttl.html
Tony: _:example needs to be a named individual, because you cannot form reference to it.
eric: Could use inverse functional properties, but that's a pain and we would not be taking advantage of URIs.
lloyd: We can do that some of the times, but there are circumstances when resources will not have identifiers. When you do a POST it has no identity. The server gives you back a URI for it.
<scribe> ACTION: Tony to try loading grahame's AllergyIntoloerance example (with _:example bnode root) in protege [recorded in http://www.w3.org/2016/03/01-hcls-minutes.html#action01]
<trackbot> Error finding 'Tony'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
eric: should use the same root node in RDF as is used in FHIR XML or JSON
lloyd: in
fhir:AllergyIntolerance.substance grahame has added ' a
sct:227493005;', but that's not always going to be on the
wire.
... grahame added it on some of the properties, but not all of
them.
tony: the type code gets applied to AllergyIntolerance (type becomes Confirmed)
lloyd: sct:227493005 is a
property of the AllergyIntolerance -- not a type of it.
... Otherwise if there were both previousStatus and a different
(current) status, they both of those types would be applied to
AllergyIntolerance
... Concept cannot exist independent of code
... And VS is a set of codes that imply concepts.
tony: present and previous status, when applied to the concept structures, the concepts are distinct.
eric: elevating the type to the
subject of the property does not work (e.g., currentlyConfirmed
vs currentlySuspected).
... But we could say that there's a set of properties, the
concepts of which we can apply directly to the subjects.
... Do you want to say that this house is a member of the class
RedHouses or do you want to say that it has an attribute of
red?
lloyd: The concept appears at two
levels -- coding and codeableCOncept.
... We started from everything being turned into a
codeableConcept. What grahame has said is that concepts appear
at both levels, but I think that will cause us grief, but we'll
see.
... The binding ont from snomed to FHIR, it needs to know where
to apply it.
tony: Yes, you really need to know the object property
lloyd: Can we come up with the ont that will enable that inference, that substance is an sct:227493005 and the coding is an sct:227493005 ?
tony: The big thing is the disjoint declarations that we had. We'll have to take those out, because now we'll have codes that are also concepts.
dbooth: The snomed types that grahame has added, such as ' a sct:227493005;', will not always be there, so we cannot count on it for round tripping. It is misleading to have them there.
lloyd: Instances will not
necessarily have these present, but if present they should be
round tripped in the JSON or XML.
... In many cases they will not be there. But now they're
present in order to test something, but should also appear
everywhere.
... Once we have completed our tests they can be dropped.
rob: How do deal with multiple codings?
lloyd: multiple concept assertions
harold: re everything having coding, at the moment we do not have a concept identifier for food. Is there a proposal for getting that in?
lloyd: What is the concept code for food? We need one, but don't have one yet.
harold: Where is the equivalent
of fhir:food (corresponding to snomed code)?
... How does the target of the category rdf:type fhir:food get
there?
lloyd: The transform happens based on ont knowledge, fixed value from a VS, implies food concept.
harold: Then why not for substance?
lloyd: For substance we don't
have a fixed binding.
... Substance could draw from 20 other code systems.
... Also because it is not a fixed binding, it needs to draw
from both.
... Right now we're asserting the concept for substance, but we
need to (temporarily for testing) for status, criticality, etc.
just like for substance.
let's get specific: https://docs.google.com/document/d/1XfktjntceKY4zDTmklkQTWuFbWC3tSY39Xh72Rl64hg/edit
changing fhir:AllergyIntolerance.status to:
[[
fhir: AllergyIntolerance.status [
a fhir:CodeSystem\/AllergyIntoleranceStatus\#confirmed ;
fhir: value "confirmed"
];
]]
We'll do one :)
lloyd:
fhir:AllergyIntolerance.recorder is declared as a
fhir:Reference . Doesn't need to be declared.
... What about having the fhir:REference.reference include an
actual URI of the thing that is referenced?
dbooth: Can it always have a URI?
lloyd: sort of.
dbooth: what about when you're POSTing and you have an internal reference?
lloyd: then it's relative to the server to which you're posting.
eric: An XML FHIR app will see a ref to Practitioner/example and take its own base URL and resolve that ref as ../Practitioner/example?
lloyd: Yes
... it would prepend the base URL and go from there.
... The tricky piece is that these are not true relative URLs.
there's some magic, but if you adhere to the magic it
works.
eric: Can we emulate that magic on the RDF side?
dbooth: Will there *always* be a URI available?
lloyd: Will there always be a URI? yes. Will it alwasy be available to the translation process? IDK. It would require that knowledge to be injected into the conversion process.
eric: Any XML tool traversing the ref would need the URI?
lloyd: Yes. If you're doing a
POST, and the recipient checks, it would look for
baseUri/Patient/example to see if that exists.
... The client is aware that the patient exists on the same
server where the allergyIntolerance is being posted.
eric: So if we say that the translation process has the same burden, then we can do that, because JSON and XML will need to do that anyway?
lloyd: The info will be available
to the systems, but not necessarily to the module doing the
translation. You may need to pass that info in through several
layers.
... From an ont perspective not having the link produces not
useful data.
... Without an expilcit ref to the patient, then finding the
meds prescribed to the patient will be much more awkward for
RDF types to write.
eric: You would have logic into
the SPARQL: the logic of URI resolution.
... If I say waht are all the med orders for this patient, it
would have to figure out the ways to write down the ref to that
patient.
lloyd: Instead of querying for meds for patient xyz, you have to query for a patient with a property with a string "xyz" OR . . . the various other ways of identifying the patient.
dbooth: Instead of using a URI for the patient, you would use one or more property paths?
lloyd: yes.
... the fhir:value of fhir:Reference.reference could be
"Patient/example" or "http://example.org/fhir/Patient/example"
eric: Equivalence between http: and https: ?
lloyd: It was discussed, but
don't know where it is document.
... Yes, they refer to the same object.
... But if you put a non-default port number on then it is
different.
dbooth: Will there always be a URI
lloyd: There will always be a base, but not in the document.
dbooth: If you're doing a POST, and you have not posted, you dont' know the base?
lloyd: if it's in memory and you
haven't decided where to send it, then yes.
... The base URI does not exist inside the instance, but
resources frequently know what their base is.
... My inclination is to allow the URI to be optionally
included in the instance.
lloyd: Base URI will never appear
inside the doc.
... But if the doc lives on a server, then the server exposing
that doc is aware of that base URI.
dbooth: And could sometimes include the URI in the doc?
lloyd: Could calculate absolute
URIs for embedding in the doc.
... My preference is to say that this is permitted but not
required.
... So transforms to RDF, XML or JSON could use an extension to
keep that info if it's available.
dbooth: Trying to zero in on what we can ALWAYS count on.
lloyd: Cannot always count on an absolute URI in the doc.
dbooth: We need to figure out how to deal with that in RDF, because RDF uses *only* absolute URIs.
lloyd: Could use a post-processing step that would take the base URI to generate absolute URIs from properties.
dbooth: That sounds like it pushes us toward not requiring URIs in the RDF document.
eric: I haven't given up yet. I
hope we can have the baseUri available.
... I also want to try leveraging Turtle's relative URIs.
lloyd: But for servers that don't care about RDF that use ref implementations might not want to be bothered to pass in the baseUri.
lloyd: In RDF, should things like dates be expressed as strings in turtle or not?
eric: Turtle literals are written
as "foo"^^theType
... So things like fhir:datetype can just be written that
way.
dbooth: Could write "2012-06"^^fhir:datetime
lloyd: JSON people would not know or care if the date is xsd:date or xsd:datetime
eric: when using the JSON, you
have to parse as all three and see which worked?
... I would prefer that the translator tries to parse the value
all three ways, and then tag it with the type that worked.
dbooth: Query would either have to use: (a) a regex vs a datatype for all three types; and (b) cast all three to use them together.
ISSUE: How to represent fhir:datetime values? Three different types? Plain xsd:strings?
<trackbot> Created ISSUE-20 - How to represent fhir:datetime values? three different types? plain xsd:strings?. Please complete additional details at <http://www.w3.org/2014/HCLS/track/issues/20/edit>.
ADJOURNED
<ericP> qualifiedBy
[[
# fhir:dateTime is union of xs:dateTime, xs:date, xs:gYearMonth, xs:gYear
#
#########################################################
# If FHIR RDF literals are tagged with separate FHIR dateTime datatypes,
# filters would look like this:
FILTER ( datatype(?lastOccurence) = xsd:gYear )
FILTER ( datatype(?lastOccurence) = xsd:gYearMonth )
FILTER ( datatype(?lastOccurence) = xsd:date )
FILTER ( datatype(?lastOccurence) = xsd:dateTime )
#########################################################
# If FHIR RDF literals are xsd:strings ,
# filters would look like this:
FILTER regex(?lastOccurence,
"^[0-9]{4}$") # YYYY
FILTER regex(?lastOccurence,
"^[0-9]{4}\-[0-9]{2}$") # YYYY-MM
FILTER regex(?lastOccurence,
"^[0-9]{4}\-[0-9]{2}\-[0-9]{2}$") # YYYY-MM-DD
FILTER regex(?lastOccurence,
"^[0-9]{4}\-[0-9]{2}\-[0-9]{2}T") # YYYY-MM-DDThh:mm:ss
#########################################################
# In both cases, the value would have to be converted in order
# to compare it to another FHIR dateTime value:
FILTER ( f:toDateTime(?lastOccurence) < ?someDateTime )
]]
eric: But xpath knows how to do datetime type conversions.
dbooth: Okay, so here's my updated comparison:
[[
# fhir:dateTime is union of xs:dateTime, xs:date, xs:gYearMonth, xs:gYear
#
#########################################################
# If FHIR RDF literals are tagged with separate FHIR dateTime datatypes,
# filters would look like this:
FILTER ( datatype(?lastOccurence) = xsd:gYear )
FILTER ( datatype(?lastOccurence) = xsd:gYearMonth )
FILTER ( datatype(?lastOccurence) = xsd:date )
FILTER ( datatype(?lastOccurence) = xsd:dateTime )
# XPath knows how to convert between the different datetime
# representations
# https://www.w3.org/TR/xpath-functions/#casting-from-primitive-to-primitive
# so comparison can be done without an explicit conversion:
FILTER ( ?lastOccurence < ?someDateTime )
#########################################################
# If FHIR RDF literals are xsd:strings ,
# filters would look like this:
FILTER regex(?lastOccurence,
"^[0-9]{4}$") # YYYY
FILTER regex(?lastOccurence,
"^[0-9]{4}\-[0-9]{2}$") # YYYY-MM
FILTER regex(?lastOccurence,
"^[0-9]{4}\-[0-9]{2}\-[0-9]{2}$") # YYYY-MM-DD
FILTER regex(?lastOccurence,
"^[0-9]{4}\-[0-9]{2}\-[0-9]{2}T") # YYYY-MM-DDThh:mm:ss
# To compare it to another FHIR dateTime value:
FILTER ( f:toDateTime(?lastOccurence) < ?someDateTime )
]]
eric: Many more queries will be done than translations
ADJOURNED AGAIN :)
<ericP> ericP: many more queris written than translators implemented
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/foo/food/ Succeeded: s/datetype/datetime/ Succeeded: s/datetype/datetime/ No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Present: David_Booth EricP Harold_Solbrig Lloyd_McKenzie Rob_Hausam Sajjad_Hussain Tony_Mallia Thomas_Lukasik Agenda: http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda#DRAFT_Agenda_for_San_Antonio_Face-to-Face_Meetings Found Date: 01 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/01-hcls-minutes.html People with action items: tony[End of scribe.perl diagnostic output]