Stream: ontology
Topic: indicating the root element
David Booth (Mar 23 2016 at 02:58):
On today's call we re-visited fhir:resourceType and discussed how we could indicate the root node:
https://www.w3.org/2016/03/22-hcls-minutes.html#item03
Grahame Grieve (Mar 23 2016 at 02:59):
I had hoped to join the call, but was otherwise detained.
Grahame Grieve (Mar 23 2016 at 02:59):
that doesn't seem conclusive...?
Grahame Grieve (Mar 23 2016 at 03:37):
but I did miss the difference between resourceType and rdf:type. I agree that there's no need for resourceType in turtle - which is why it's not a good name - I agree with fhir:root or fhir:entryPoint or something. the real semantics of the entry point are about focus/focal, so maybe that's what it should be?
Michael van der Zel (Mar 23 2016 at 08:20):
We have resource definitions that have a root, but we also have instances that have a root. Is that actually the same thing?
Grahame Grieve (Mar 23 2016 at 08:22):
not the same thing
Michael van der Zel (Mar 23 2016 at 08:23):
So is fhir:root for the definition or the instance?
Grahame Grieve (Mar 23 2016 at 08:23):
well, actually, it depends what you are asking. Which definition? you know that there's 2 different definitions, right?
Grahame Grieve (Mar 23 2016 at 08:23):
are you asking about fhir.ttl?
Michael van der Zel (Mar 23 2016 at 08:24):
I am working on the instance data, so at the present not fhir.ttl.
Grahame Grieve (Mar 23 2016 at 08:24):
so what definition are you referring to then?
Michael van der Zel (Mar 23 2016 at 08:26):
I assume there will be ttl for
1. the fhir core stuff
2. for resource definitions
3. ttl for actual data.
So there is a definition e.g. Observation and an instance e.g. Bloodpressure for patient xyz.
Michael van der Zel (Mar 23 2016 at 08:28):
I was wondering if we need a different way to express the root node for 1+2 and 3.
Grahame Grieve (Mar 23 2016 at 08:29):
I'm shipping 1+2 together in fhir.ttl, but I'm not defining a single entry for that. it's just a collection of statements
Michael van der Zel (Mar 23 2016 at 08:29):
But then you cannot do round trips for 1+2 to xml/json right?
Grahame Grieve (Mar 23 2016 at 08:29):
the actual data references the relevant spot in the definitions
Grahame Grieve (Mar 23 2016 at 08:30):
I'm not sure what you mean about round trips - you can round trip #3. #1 and #2 aren't round-trippable. It's a lossy transform to RDF
Grahame Grieve (Mar 23 2016 at 08:30):
but there's no need to round trip 1+2
Michael van der Zel (Mar 23 2016 at 08:30):
I can only round trip #3 if I know what the entry piont is.
Grahame Grieve (Mar 23 2016 at 08:30):
though are you aware of the near/far form dichotomy
Michael van der Zel (Mar 23 2016 at 08:30):
Ok. I get 1+2, it is just an observation.
Michael van der Zel (Mar 23 2016 at 08:31):
What is "dichotomy" ?
Grahame Grieve (Mar 23 2016 at 08:31):
but you don't need to know an entry point in #1 or #2 to round trip #3. in fact you don't need to know them at all to round trip from RDF and back. What you need to know about thme will be stated explicitly
Grahame Grieve (Mar 23 2016 at 08:31):
dichotomy = choice of one or the other. sorry
Michael van der Zel (Mar 23 2016 at 08:32):
N.P.
Grahame Grieve (Mar 23 2016 at 08:32):
there's a few things you need to know about 1+2 to do #3, but we'll just say what they are explicitly in the documentation, so you don't need to look in #1 + #2 unless you want to reason
Michael van der Zel (Mar 23 2016 at 08:32):
So we only need to know the entrypoint for #3. That is clear.
Grahame Grieve (Mar 23 2016 at 08:33):
btw, #1 + #2 includes #1a - the RIM as an ontology
Michael van der Zel (Mar 23 2016 at 08:33):
:-)
Grahame Grieve (Mar 23 2016 at 08:34):
and kowing the entry point - we've agreed, pretty much, that it's going to be a special property that you look for. (see discussion above and in David's link). All we need to agree on is an arbitrary URL with a useful name. I'm preferring 'focal-point' or something, but waiting to see what David says
Michael van der Zel (Mar 23 2016 at 08:35):
Yes.
Grahame Grieve (Mar 23 2016 at 08:35):
k. gotta go. hopefully we can nail this down in the next 12 hours
Michael van der Zel (Mar 23 2016 at 08:35):
One more question. It is like fhir:index, right? We only need that because xml and json need it.
Michael van der Zel (Mar 23 2016 at 08:35):
ttyl
Grahame Grieve (Mar 23 2016 at 08:35):
no we need taht period. because the lists always have a stated order, and it's often meaningful
Grahame Grieve (Mar 23 2016 at 08:35):
and that's the only way to know what it is in RDF
Michael van der Zel (Mar 23 2016 at 08:36):
But rdf has ordered lists.
Michael van der Zel (Mar 23 2016 at 08:37):
https://www.w3.org/TR/rdf-schema/#ch_collectionvocab
Michael van der Zel (Mar 23 2016 at 08:38):
or in turtle: https://www.w3.org/TR/turtle/#object-lists
David Booth (Mar 23 2016 at 15:06):
Michael, RDF's order lists are woefully inconvenient to work with. We explored various options https://goo.gl/DKcm0U and decided that fhir:index seemed like the best option.
David Booth (Mar 23 2016 at 15:15):
Grahame, that's correct that the discussion yesterday https://www.w3.org/2016/03/22-hcls-minutes.html#item03 was not conclusive. We agreed that we should not use fhir:resourceType to indicate the root node, because that serves a different purpose in JSON and would be too confusing. We agreed that we should use rdf:type to indicate the type of the resource, but a *separate* property to indicate the root node. But we did not yet agree on the property to use to indicate the root node. The two proposals were ':myAllergyIntolerance fhir:rootNode true' or ':myAllergyIntolerance a fhir:RootNode'. We did not feel like we had enough people on the call to make the choice.
Michael van der Zel (Mar 23 2016 at 17:05):
fwiw I would vote for the property fhir:rootNode true
Grahame Grieve (Mar 23 2016 at 19:09):
in what sense is it a 'root node'? To me, the definition is 'this concept is that one that is our focus in this concept' - e.g. it's the one we are sending you in response to your question for information about the patient. Always, these things are just windows into a wider graph of information about the world. You could do a series of queries and graduallly build up information about the context of inteest (say a patient) by aggregating the response you get into a single RDF graph. Whether something is the focus or not is about the exchange, not a property that has any meaning in the aggregated graph
David Booth (Mar 23 2016 at 19:16):
Grahame, it is a 'root node' in the sense that if you round trip it to/from FHIR JSON or FHIR XML, it should appear as the root element of those serializations. Its purpose is to enable round tripping.
Grahame Grieve (Mar 23 2016 at 19:17):
whatever we call it, you'd either need to strip it or ignore it in the aggregation, yes?
David Booth (Mar 23 2016 at 19:17):
What do you mean by 'the aggregation'?
Grahame Grieve (Mar 23 2016 at 19:18):
if I'm doing a series of queries and adding all the responses together into a single RDF graph
David Booth (Mar 23 2016 at 19:19):
Right, then you would just ignore it for RDF processing. It's completely normal in RDF to ignore things that you don't care about.
Grahame Grieve (Mar 23 2016 at 19:23):
so should be a 'type' - I don't think so; it's not an inherent property of the object, it's a piece of information about how it is used
Grahame Grieve (Mar 23 2016 at 19:23):
so ':myAllergyIntolerance fhir:rootNode true' is right, and ':myAllergyIntolerance a fhir:RootNode' is not
David Booth (Mar 23 2016 at 19:25):
I somewhat prefer the ':myAllergyIntolerance a fhir:RootNode' style, because it's briefer, but I don't have strong feelings either way. At the end of the day they're very similar.
Grahame Grieve (Mar 23 2016 at 19:28):
so should we not "a use owl:Ontology"? It's not clear to me whether we should allow it, require it, or ban it?
Grahame Grieve (Mar 23 2016 at 19:28):
and if you want brief:
"fhir:root true"
David Booth (Mar 23 2016 at 19:29):
AFAICT Tony's the only one who's been wanting it, and only because he's married to protege. :)
Grahame Grieve (Mar 23 2016 at 19:30):
so that means not to require it. But leaves open ban vs allow. Does adding additional ontological mark up matter? is there a conformance issue around it?
David Booth (Mar 23 2016 at 19:30):
But I think we're convincing him that putting owl:Ontology on RDF *instance* data is quite a peculiar thing to do. Eric sent him an example yesterday of how to make protege work without it, and if Tony gets that to work then I think we can drop it.
David Booth (Mar 23 2016 at 19:32):
we should not ban it, but we also should not make any special efforts to round-trip it.
Grahame Grieve (Mar 23 2016 at 19:32):
ok. well, I just committed fhir:root true to the build.
David Booth (Mar 23 2016 at 19:32):
:)
Grahame Grieve (Mar 23 2016 at 19:33):
but there's still some differences between the turtle I am generating and @Eric Prud'hommeaux is generating. I haven't seen Michael's turtle.
Grahame Grieve (Mar 23 2016 at 19:33):
what difference should we work on next?
David Booth (Mar 23 2016 at 19:33):
we should treat owl:Ontology the same as any other extra assertions that someone may include in their RDF: they're free to merge in any other triples they want in RDF, but they cannot expect those triples to be automagically serialized to FHIR JSON or XML.
David Booth (Mar 23 2016 at 19:34):
what are the other differences you're still seeing?
Grahame Grieve (Mar 23 2016 at 19:34):
k that makes sense. we should write that up
Grahame Grieve (Mar 23 2016 at 19:36):
other differences - Eric is sometimes including the type on non-resource elements. it is not necessary. Is that allowed, required, prohibited?
Grahame Grieve (Mar 23 2016 at 19:37):
Eric has this: fhir:MedicationOrder.dateWritten "2000-11-21T15:00:00"^^xsd:dateTime ;
I never generate the ^^xsd: bit. Why would we?
David Booth (Mar 23 2016 at 19:37):
Allowed, and won't be round-tripped.
Grahame Grieve (Mar 23 2016 at 19:38):
other differences,. I think Eric has just not adjusted after our dsicussion
David Booth (Mar 23 2016 at 19:46):
Regarding ^^xsd:dateTime, we discussed this a bit, but I don't think we came to resolution. Looking for minutes ...
David Booth (Mar 23 2016 at 19:55):
https://www.w3.org/2016/03/01-hcls-minutes.html#item06 Eric wants to use ^^xsd:dateTime , but there is some subtlety to that, and I'm not entirely comfortable with it. The problem is that the FHIR type is a union of 4 types, and xsd:dateTime is only one of those possibilities. This means that a FHIR XML/JSON --> FHIR RDF translator would be burdened with attempting to parse the data as each one of those possibilities, and select the most detailed one that succeeds. The benefit of this is that SPARQL queries are easier, because we are using standard types. (The FHIR union is not a standard type to the RDF world.)
Grahame Grieve (Mar 23 2016 at 19:58):
so this is a specific date issue, then.
David Booth (Mar 23 2016 at 19:58):
On further consideration, I think Eric's argument is pretty good, even though it does place that burden on the translator. But better there than on all of the query authors.
David Booth (Mar 23 2016 at 19:58):
yes, unless FHIR has other union types, this is a date issue only.
Grahame Grieve (Mar 23 2016 at 19:59):
so you would have to use xsd:date or xsd:yearMonth etc depending on the instance?
David Booth (Mar 23 2016 at 19:59):
exactly
Grahame Grieve (Mar 23 2016 at 19:59):
does RDF really not have a type that has flexible precision with regard to date? I find that hard to believe
David Booth (Mar 23 2016 at 20:00):
RDF just uses the XSD types
Grahame Grieve (Mar 23 2016 at 20:00):
stinking XSD. It's my biggest problem - their hard ass approach to dates. Doesn't match the real world at all
David Booth (Mar 23 2016 at 20:00):
But SPARQL does provide coercions between those types, which is why the SPARQL queries are easier using the standard XSD types.
Grahame Grieve (Mar 23 2016 at 20:01):
so If I was doing a sparql query against this, and my target elements had variable types, how does that work?
David Booth (Mar 23 2016 at 20:23):
I'm not finding the dateTime coercion rules, so now I'm not sure whether it is a standard part of SPARQL or XSD or merely commonly implemented. I think Eric may know.
Grahame Grieve (Mar 23 2016 at 20:26):
@Eric Prud'hommeaux - please clarify
Michael van der Zel (Mar 24 2016 at 10:09):
@Grahame Grieve Ok. I will put up some examples and let you know were they are.
Michael van der Zel (Mar 25 2016 at 19:47):
@Grahame Grieve here I will put my examples: https://app.box.com/s/pvuzghem0nswwq5hrnn1x4m44abjv6h9 There is one there now. It needs some work.
1. The name of the datatype is not right. 2. There is something different with the array. 3. Don't know why, but the used rdf api sorts the properties.
Michael van der Zel (Mar 31 2016 at 07:22):
@Grahame Grieve I updated my example on the link above.
I miss "fhir:root" property in your examples: https://hl7-fhir.github.io/observation-example-bloodpressure.ttl.html, but see fhir:nodeRole fhir:treeRoot;
Grahame Grieve (Mar 31 2016 at 07:50):
yes we changed that overnight! just as you catch up. you're behind again! - but we're frozen now
Michael van der Zel (Mar 31 2016 at 18:03):
Excelent. I think there is a typo on the rdf page:
1.17.3.1.3 fhir:index "[value]"^^xs:type should be: fhir:*value* "[value]"^^xs:type
Last updated: Apr 12 2022 at 19:14 UTC
