Stream: ontology
Topic: turtle
Grahame Grieve (Mar 16 2016 at 02:00):
welcome. Notification to people that I have updated the turtle resources, but there is still one problem with them
Grahame Grieve (Mar 16 2016 at 02:00):
the names of the inner elements aren't right yet.
Grahame Grieve (Mar 16 2016 at 02:00):
maybe I can address this later tonight
Grahame Grieve (Mar 16 2016 at 11:37):
done. Here's a sample:
Grahame Grieve (Mar 16 2016 at 11:37):
<http://hl7.org/fhir/AllergyIntolerance/example> a fhir:AllergyIntolerance; a owl:Ontology; fhir:Resource.id [ fhir:value "example"];
Grahame Grieve (Mar 16 2016 at 11:37):
...
Grahame Grieve (Mar 16 2016 at 11:38):
fhir:AllergyIntolerance.reaction [
fhir:index 0;
fhir:AllergyIntolerance.reaction.substance [
fhir:CodeableConcept.coding [
fhir:index 0;
Grahame Grieve (Mar 16 2016 at 11:39):
This is what it should be - the element is a direct reference to a defined data element
Grahame Grieve (Mar 16 2016 at 11:39):
and the json-ld version
Grahame Grieve (Mar 16 2016 at 11:40):
"@context": "http://hl7.org/fhir/jsonld/AllergyIntolerance",
"resourceType": "AllergyIntolerance",
"Resource.id": {
"value": "example"
},
Grahame Grieve (Mar 16 2016 at 11:40):
"AllergyIntolerance.reaction": [
{
"AllergyIntolerance.reaction.substance": {
"CodeableConcept.coding": [
{
"Coding.system": {
"value": "http://www.nlm.nih.gov/research/umls/rxnorm"
},
Michael van der Zel (Mar 16 2016 at 12:20):
Why the "fhir:value"`in the turtle? It looks like it has no function.
fhir:Resource.id [ fhir:value "example"];
could just be
fhir:Resource.id "example";
Michael van der Zel (Mar 16 2016 at 17:43):
Ah. Sometimes the rdf:type is needed. E.g. for Observation.effective. You need the type dateTime or Period, but this is an exception. For most instances it is not needed.
Grahame Grieve (Mar 16 2016 at 20:39):
well, it's also where id and extensions go as well
Grahame Grieve (Mar 16 2016 at 20:40):
it's not used often, so in the normal json format, we split that into attribute : primitive and and _attribute : {} but this complicates general reasoning. The RDF model should follow the abstract model, not a serialisation optimization
Grahame Grieve (Mar 17 2016 at 01:44):
@Eric Prud'hommeaux - on the subject of extensions, I have an idea. Let's stick to turtle/rdf for now.
Grahame Grieve (Mar 17 2016 at 01:44):
here's an extension as I build them today
Grahame Grieve (Mar 17 2016 at 01:44):
fhir:DomainResource.extension [
fhir:index 0;
fhir:Extension.url [ fhir:value "http://example.org/StructureDefinition/trials" ];
fhir:Extension.value [
a fhir:code;
fhir:value "renal" ]
];
Grahame Grieve (Mar 17 2016 at 01:45):
but we could change that around. How about something like this:
Grahame Grieve (Mar 17 2016 at 01:46):
<http://example.org/StructureDefinition/trials> [
a fhir:Extension
fhir:index 0;
a fhir:code;
fhir:value "renal" ]
];
Grahame Grieve (Mar 17 2016 at 01:47):
of course, you'd prefix them. so
Grahame Grieve (Mar 17 2016 at 01:47):
prefix ext1 <http://example.org/StructureDefinition/> .
ext1:trials [
a fhir:Extension
fhir:index 0;
a fhir:code;
fhir:value "renal" ]
];
Lloyd McKenzie (Mar 17 2016 at 01:55):
I think I'm ok with that. That's sort of inline with how I'd originally envisioned it.
Grahame Grieve (Mar 17 2016 at 02:06):
the most interesting and potentially serious change is that it changes the meaning of the fhir:index property
Grahame Grieve (Mar 17 2016 at 02:07):
but I don't think it works at all in json-ld.
Lloyd McKenzie (Mar 17 2016 at 02:13):
It's true that the index would have to be interpreted across all extensions, though we could document that as convention
Grahame Grieve (Mar 17 2016 at 02:19):
but I don't know that you could do that very easily. And why would you do that?
Lloyd McKenzie (Mar 17 2016 at 02:38):
To retrain roundtripability - you'd want to retrain the order of the extensions among all extensions, not just within repetitions of the same one.
Lloyd McKenzie (Mar 17 2016 at 02:38):
Don't see why it would be challenging to do
Grahame Grieve (Mar 17 2016 at 02:41):
why do you need to retain order in all the extensions? we've said it's not relevant
Lloyd McKenzie (Mar 17 2016 at 04:16):
I'm thinking about signatures, though I guess if the canonicalization doesn't care, we don't have to care either
Grahame Grieve (Mar 17 2016 at 04:36):
it would break signatures yes
Michael van der Zel (Mar 17 2016 at 12:54):
I was working on roundtripping xml->turtle->xml and ran into the problem that I needed the "root" triple.
Michael van der Zel (Mar 17 2016 at 12:55):
Turtle translates into a set of triples. For now I determine the "root" triple by looking for the triple with a subject that is never used as object.
Michael van der Zel (Mar 17 2016 at 12:56):
I need the root triple for the resourceType. Does this make sense or am I on the wrong page?
David Booth (Mar 17 2016 at 13:20):
Michael, we decided to explicitly indicate the root using fhir:resourceType as described here: https://github.com/w3c/hcls-fhir-rdf/issues/8
Michael van der Zel (Mar 17 2016 at 13:26):
@David Booth Thanks. Is anyone updating the rdf page with all these decisions? https://hl7-fhir.github.io/rdf
Why use a string value for this and not just a URI?
David Booth (Mar 17 2016 at 14:44):
Grahame is currently maintaining https://hl7-fhir.github.io/rdf but the intent is that http://w3c.github.io/hcls-fhir-rdf/spec/rdf.html will replace it once the latter is far enough along.
David Booth (Mar 17 2016 at 14:46):
The reason it is a string value is that Lloyd thought it would be easier in round-tripping, and nobody else came up with a reason why a URI would be better. If you think of a use case where a URI would be better then let us know.
Michael van der Zel (Mar 17 2016 at 14:55):
Ok. I interpret fhir:resourceType as kind of a rdf:type which has a uri as object.
Grahame Grieve (Mar 17 2016 at 18:11):
David you said "the intent is that http://w3c.github.io/hcls-fhir-rdf/spec/rdf.html will replace it" - I absoutely disagree with this approach completely
Grahame Grieve (Mar 17 2016 at 18:11):
that's a very bad idea for version control reasons
Grahame Grieve (Mar 17 2016 at 18:12):
further, this: " we decided to explicitly indicate the root using fhir:resourceType " is a bad idea. Any time a resource is included - whether it is contained or not, it will have a fhir:resourceType
Grahame Grieve (Mar 17 2016 at 18:13):
at present, the only reliable indicator for what Michael is looking for is the presence of an owl:Ontology assertion
David Booth (Mar 21 2016 at 19:05):
Grahame, I'll put these questions on the agenda for re-discussion. Forhttps://hl7-fhir.github.io/rdf , what mechanism would you suggest for updating it to the group's current thinking?
Grahame Grieve (Mar 21 2016 at 20:08):
well, we can edit it. I'm assuming that we will. It's just an html page, so anyone who can edit the html can edit it
David Booth (Mar 21 2016 at 20:34):
It's a question of how easy it is to make those edits. We wanted to be able to edit on github collaboratively.
Lloyd McKenzie (Mar 21 2016 at 20:47):
Anyone with commit privileges can edit and xhtml merges pretty easily.
Grahame Grieve (Mar 21 2016 at 20:51):
it's not as smooth as editing on github. no.
Grahame Grieve (Mar 21 2016 at 20:51):
but it's the right place for the content to live long term, else it creates version tension.
Grahame Grieve (Mar 21 2016 at 20:52):
and it's a wrong value proposition to make things harder for the implemeters because it's easier for the editors
Grahame Grieve (Mar 29 2016 at 23:05):
hah. going through the RDF page, I have some questions
Grahame Grieve (Mar 29 2016 at 23:05):
the section in the RDF page on default values.... do we want default values represented explicitly in the RDF?
Josh Mandel (Mar 30 2016 at 03:39):
Yes!
Josh Mandel (Mar 30 2016 at 03:39):
Open-world assumption plays poorly with defaults.
Grahame Grieve (Mar 30 2016 at 03:54):
well, in the rdf sense, the value is not present in the instance, so it falls back to the value provided in the definitions
Grahame Grieve (Mar 30 2016 at 03:54):
is that workable, or must the instance provide the value?
Josh Mandel (Mar 30 2016 at 04:24):
Most people working with RDF use the "open world assumption", where the absence of a statement doesn't mean anything. This clearly is a poor fit for the notion of defaults. And it would be very strange, in my opinion, for FHIR not to design for OWA.
Josh Mandel (Mar 30 2016 at 04:24):
It's not illegal or invalid or anything, but it would be very surprising in the RDF community.
Josh Mandel (Mar 30 2016 at 04:25):
Let's see if others agree with me though!
Josh Mandel (Mar 30 2016 at 04:25):
@Eric Prud'hommeaux ?
Grahame Grieve (Mar 30 2016 at 04:26):
i didn't dispute that. I merely asked whether taking the default value out of the type definitions because it's not in the instance content was a reasonable approach, or whether it must be repeated explicitly in the instance data
Josh Mandel (Mar 30 2016 at 04:27):
How would you "take it out of the type definitions"?
Grahame Grieve (Mar 30 2016 at 04:27):
on the other hand, not supporting defaults would be... very surprising... to must communities
Grahame Grieve (Mar 30 2016 at 04:29):
well, let's assume that Observation.status had a default value (it doesn't, but it'll do for me):
ResA a fhir:Observation
fhir:Observation a fhir:Resource [
fhir:Observation.status a rdfs:property [
rdfs:default "final"
]
]
Grahame Grieve (Mar 30 2016 at 04:29):
something like that, anyway
Josh Mandel (Mar 30 2016 at 04:29):
Right, and then ?
Josh Mandel (Mar 30 2016 at 04:29):
The normal way to join instance data with definitions in RDF is through a "reasoner".
Josh Mandel (Mar 30 2016 at 04:30):
The reasoner takes what's known about the data, and derives conclusions from the definitions/ontology.
Grahame Grieve (Mar 30 2016 at 04:30):
because resA is a fhir:observation, and because fhir:observation has a property Observation.status, and because Observation.status is a property with a default value, then the default value will apply to resA since it doesn't specify an alternative value
Josh Mandel (Mar 30 2016 at 04:30):
But the absence of data isn't something "known", so it can't drive reasoning.
Josh Mandel (Mar 30 2016 at 04:31):
since it doesn't specify an alternative value
this the part we can't detect under an open-world assumption
Grahame Grieve (Mar 30 2016 at 04:32):
ok. so the instance has to render the defaults. interesting challenge...
Josh Mandel (Mar 30 2016 at 04:32):
That's my position. But would be good to hear from @David Booth , @Eric Prud'hommeaux, and others.
Grahame Grieve (Mar 30 2016 at 04:34):
this applies to json-ld, too, as far as I can see.
Grahame Grieve (Mar 30 2016 at 04:39):
sparql (for example) is not bound to open world reasoning though. We could also treat this as a post-processing problem to prepare the content for an open world reasoner, rather than inherently required in the RDF
Eric Prud'hommeaux (Mar 30 2016 at 05:05):
There are two issues around defaults and OWA:
1 "Erasure" says that if you "conclude" something looking at a portion of the data, you shouldn't conclude something contrary when looking at more data. DL-query (probably the most direct to query what OWL "knows") is sensitive to that and won't give an answer that will be contradicted by further information (note that further information can create an inconsistent system).
2 Inferred defaults will be different depending on the level of inference which is usually a no-no in RDF.
{:Foo my:defaultP1Value 7 . <X> a :Foo.} implies { <X> :p1 7 . }
{:Foo my:defaultP1Value 7 . <X> a :Foo; :p1 8.} does not imply { <X> :p1 7 . }
but with some RDFS, we will get different values if we don't support RDFS or if we do:
{x:defaultP1Value rdfs:subPropertyOf my:defaultValue . :Foo x:defaultP1Value 7 . <X> a :Foo.} implies { <X> :p1 7 . }
only if you understand rdfs:subPropertyOf
{ x:p1 rdfs:subPropertyOf :p1 . :Foo my:defaultP1Value 7 . <X> a :Foo; x:p1 8.} does not imply { <X> :p1 7 . }
unless you don't understand rdfs:subPropertyOf
Eric Prud'hommeaux (Mar 30 2016 at 05:06):
(oof, what a hairball)
Eric Prud'hommeaux (Mar 30 2016 at 05:08):
Anyways, all of that said, i'm not particularly opposed to defaults.
You can put guards around issue 2 (don't subProperty either properties that have defaults nor the expression of a default).
For issue 1, it's sort of a cost of doing business in an efficient world.
Grahame Grieve (Mar 30 2016 at 05:46):
I think that's called a dollar each wayt
Josh Mandel (Mar 30 2016 at 14:53):
Do we know anyone in this community who actually wants to do reasoning Based on fhir data and rdf? It would be good too hear from such people :-)
Eric Prud'hommeaux (Mar 30 2016 at 14:54):
fair point. i got some good bites at my amia talk; i'll ping them.
Eric Prud'hommeaux (Mar 30 2016 at 14:54):
Tony is certainly focused on reasoning.
Eric Prud'hommeaux (Mar 30 2016 at 14:57):
I should squeeze claude nanjo for use cases
Eric Prud'hommeaux (Mar 30 2016 at 14:58):
or someone else can. i haven't talked to him in ages.
David Booth (Mar 30 2016 at 15:00):
Gopikrishnan Chandrasekharan (Gopi) wants to do clinical decision support with FHIR RDF. He joined the weekly Yosemite teleconferences the last two weeks. He's based in London, doing a PhD in medical informatics. Formerly a dentist. I'm trying to connect him with Claude.
Eric Prud'hommeaux (Mar 30 2016 at 15:59):
as far as i can tell, claude's todo pile eclipses everything he wants to do, but worth a shot
Lloyd McKenzie (Mar 30 2016 at 23:25):
My leaning on defaults is to say they are *not* populated in instances because it's too hard to retain a consistent round-trip. The only way I could be comfortable including them is if the canonicalization process for signatures involved stripping out default values.
Lloyd McKenzie (Mar 30 2016 at 23:25):
The alternative is to require applying a standard SPARQL update that sets defaults before reasoning.
Grahame Grieve (Mar 30 2016 at 23:38):
why do we care about signatures?
Lloyd McKenzie (Mar 31 2016 at 00:14):
Because data may come in as JSON or XML with a signature, get turned into RDF and stored as triples and regurgitated as XML or JSON. The signature needs to be retained.
Lloyd McKenzie (Mar 31 2016 at 00:14):
That's what round-tripping means - which has been one of our base requirements from the start.
Grahame Grieve (Mar 31 2016 at 00:14):
I think you're asking for too much. personally. If you want to validate the signature, keep the original.
Grahame Grieve (Mar 31 2016 at 00:14):
I think rdf is a different thing....
Lloyd McKenzie (Mar 31 2016 at 00:15):
RDF is supposed to be a syntax like any other. If it's not as reliable as XML and JSON, that'll be a reason for servers to not support it.
Lloyd McKenzie (Mar 31 2016 at 00:16):
And, with the exception of defaults, there should be no issue round-tripping so far.
Grahame Grieve (Mar 31 2016 at 00:16):
you do like your absolutes. It's a matter of perspective which is more reliable or not ;-)
Lloyd McKenzie (Mar 31 2016 at 00:16):
I do indeed like absolutes :)
Zoran Milosevic (Mar 31 2016 at 00:17):
What is use case for round-tripping? Sorry, coming later to this :-(
Lloyd McKenzie (Mar 31 2016 at 00:20):
If data comes in as XML and you convert it to RDF for storage, a client might ask for it back out in XML again. And the signature should be valid. Same if they send RDF in and you store as XML. (Or for that matter store in a relational format.)
Grahame Grieve (Mar 31 2016 at 00:21):
how much are you prepared to pay for that absolute right? how much is it worth? I do think it's a corner case, where as dealing with default values is not a corner case
Lloyd McKenzie (Mar 31 2016 at 00:21):
One of our base tests for XML and JSON is that you can round trip from one to the other and back again and have a canonically identical instance. If RDF is to be treated as "equal" to those two, then roundtripping would be expected there too. And aside from the defaulting issue, it's achievable.
Grahame Grieve (Mar 31 2016 at 00:21):
... just a small aside...
Lloyd McKenzie (Mar 31 2016 at 00:21):
Default values are necessary for reasoning. But pre-processing is going to be needed for reasoning anyhow.
Grahame Grieve (Mar 31 2016 at 00:21):
though we could mark defaults that are being undefaulted so you can have your round-trip magic
Lloyd McKenzie (Mar 31 2016 at 00:21):
You're going to want to pre-process to assert concept ids too.
Grahame Grieve (Mar 31 2016 at 00:22):
they don't affect round-trip-ability
Lloyd McKenzie (Mar 31 2016 at 00:22):
Yes, that's an alternative. But it imposes quite a bit on the conversion process. The question is where that complexity should lie.
Zoran Milosevic (Mar 31 2016 at 00:22):
Well, nice to have indeed, but am asking is this 80/20 rule?
Grahame Grieve (Mar 31 2016 at 00:23):
adding fhir:default fhir:just-because-lloyd when you add them is hardly an imposition
Lloyd McKenzie (Mar 31 2016 at 00:23):
Oh, agree concept ids don't impact roundtripability. My point is that if you have to pre-process anyhow, asserting defaults as part of that step is reasonable.
Grahame Grieve (Mar 31 2016 at 00:23):
80/20 generally doesn't apply at the infrastructure level
Grahame Grieve (Mar 31 2016 at 00:23):
it's about requirements.
Lloyd McKenzie (Mar 31 2016 at 00:23):
80/20 isn't relevant here. Because if we break round-tripability, it's broken for everyone, period. The 80% rule applies to inclusion of elements that could be handled by extensions.
Zoran Milosevic (Mar 31 2016 at 00:24):
Ok - got it; thanks
Grahame Grieve (Mar 31 2016 at 00:24):
it's not broken for everyone, period. puleease... and if pre-processing breaks it anyway.... it's not really pre-processing....
Lloyd McKenzie (Mar 31 2016 at 00:34):
If round-tripping can't be relied upon, then it's broken. Even if it happens to work on an arbitrary server, you can't count on it working. And I don't understand what you mean about pre-processing not being pre-processing.
Grahame Grieve (Mar 31 2016 at 00:35):
if pre-processing breaks the round-trippability, then it becomes really hard to decide when to do it. In fact, you only do it as late as you can because you don't want to break things. Voila, it turns into nearly-post-processing
Grahame Grieve (Mar 31 2016 at 00:36):
easier to say that the processing step includes injection of defaults, labelled with a tag so that reasoners and round-trippers know which were introduced in the pre-processing step
Grahame Grieve (Mar 31 2016 at 00:36):
and let's servers do as much pre-processing as they can
Grahame Grieve (Mar 31 2016 at 00:37):
cause you don't want them to be forced not to
Lloyd McKenzie (Mar 31 2016 at 01:02):
Post-processing would mean that you'd run it before you did analysis. It wouldn't be done on the data before persisting it - at least not without adding a flag to allow it to be removed
David Booth (Mar 31 2016 at 15:04):
@Josh Mandel and others, I'm actually okay with not serializing the default values in the RDF, because as Eric and Lloyd pointed out, there will need to be a post-processing step anyway to "enhance" the RDF before it is used for significant analysis (to work around non-monotonic things like modifier extensions). But to simplify round tripping, I think we'll want to keep a clean and simple separation between the basic round-tripping vocabulary and the enhancements, perhaps by putting them in a different namespace. Thoughts?
David Booth (Mar 31 2016 at 15:14):
Actually a different namespace might be confusing. (Nightmares of rdf: versus rdfs: come to mind.) But somehow we'll need to distinguish between them.
Josh Mandel (Mar 31 2016 at 17:03):
OK --- glad to hear that there's something like consensus about the need for post-processing! And certainly leaving defaults "as in JSON" will make round-tripping easier.
Tony Mallia (Mar 31 2016 at 18:43):
Finally found on zulip all the conversation I was missing.
Tony Mallia (Mar 31 2016 at 18:50):
I am using a reasoner to complete the navigation. So when I have a reference from a resource e.g. AllergyIntolerance to a Patient then I construct an inverse object property that points from the Patient to the Allergy Intolerance. When I load the Allergy Intolerance and Patient instance RDF, the reasoner infers the inverse property which allows me to navigate over the graph of the patient record. I am also using the reasoned to infer the type from a terminology (particularly SNOMED) given the system and code properties inside a coding.
Grahame Grieve (Mar 31 2016 at 19:39):
the reverse reference - do you keep track fo the context of the reference, or just that there is one?
Grahame Grieve (Apr 07 2016 at 20:05):
@Eric Prud'hommeaux - have you looked at the ShEx template thing for me yet? can we work on this over the next few days?
Tony Mallia (Apr 08 2016 at 19:34):
There is a Property chain AllergyIntolerance.patient.link which chains AllergyIntolerance.patient with Reference.link. Patient.allergy is the inverse of AllergyIntolerance.patient.link so it is context and knows to get back to the allergy and not some other resource.
Tony Mallia (Apr 08 2016 at 19:49):
(deleted)
Grahame Grieve (Apr 09 2016 at 21:46):
but does it say where in the allergy? or just identify the resource as a whole?
Tony Mallia (Apr 12 2016 at 13:48):
It points to the Allergy as a whole since it is the named individual. I suppose we could reverse back to the Reference if it were named but so far References are blank nodes.
Grahame Grieve (Apr 12 2016 at 19:10):
ok thanks. I think that it makes sense to point to the source resource as a whole
Eric Prud'hommeaux (Apr 16 2016 at 12:08):
if "context of the reference" means "subject of the referring property" then yes; any inferred inverse property will simply swap the subject and object, e.g.
axiom: { fam:hasChild owl:inverseProperty fam:hasParent . }
data: { ex:Sue fam:hasParent ex:Mary . }
implication: { ex:Mary fam:hasChild ex:Sue . }
Michael van der Zel (Apr 20 2016 at 08:44):
@Grahame Grieve Will there be some "mini" RDF Connecthaton? Or will we just discuss in the ITS Tue Q2 session?
Grahame Grieve (Apr 20 2016 at 11:58):
we sort of planned to have a virtual validation connectathon - that by the end of the week in montreal, we're able to validate all the generated turtle resources using the ShEx that Harold and I are generating
Michael van der Zel (Apr 20 2016 at 12:41):
It would be great to also test my generated turtle. I know for sure I have some differences with yours. I will make the slides to summarize the differences and the reasons.
Stephen Royce (May 09 2016 at 07:07):
Hmmm ... so I thought it was about time I got back into the RDF space and so I tried to upload the latest turtle file into Protege. I got 3474 errors mostly looking like this:
Stephen Royce (May 09 2016 at 07:07):
Level: ERROR
Time: 1462777334440
Message: Entity not properly recognized, missing triples in input?
Stephen Royce (May 09 2016 at 07:07):
Any ideas?
Grahame Grieve (May 09 2016 at 08:28):
which file?
Stephen Royce (May 09 2016 at 22:19):
fhir.ttl
Renato Iannella (May 13 2016 at 02:34):
The turtle ontology currently at: https://hl7-fhir.github.io/fhir.ttl
generates significant numbers of errors using Protege V5.0.0 (Build RC1)
When you look at the source, starting at around line 49,317 up to line 54,062, there are a hundreds of ex:birthplace individuals.
So it looks like there is a “hiccup” in the auto-generation of the turtle file?
Renato Iannella (May 13 2016 at 07:55):
Just found the "bug" that generates the errors in Protege (and TopBraid).
Throughout the turtle file, the following is used:
"1^^xs:nonNegativeInteger”
when it should be:
"1"^^xsd:nonNegativeInteger
Renato Iannella (May 13 2016 at 07:56):
This also occurs in the RIM turtle file
Grahame Grieve (May 13 2016 at 08:16):
fixed. will take some time for the update to build
Grahame Grieve (May 13 2016 at 08:16):
thansk
Grahame Grieve (May 13 2016 at 08:17):
of course there are many other issues to deal with there
Eric Prud'hommeaux (May 13 2016 at 08:17):
renato, is the xs prefix declared?
Eric Prud'hommeaux (May 13 2016 at 08:18):
there's some incentive to use xs over xsd. xs is the datatypes and xsd is the structure defintions
Grahame Grieve (May 13 2016 at 08:20):
yes xs: is declared. I didn't even notice that bit - I'm still using xs
Eric Prud'hommeaux (May 13 2016 at 08:20):
(to the extend that "xs" is a mnemonic for "XML Schema" and "xsd" is a mnemonic for "XML Schema Datatypes (i.e. XS part two))
Grahame Grieve (May 13 2016 at 08:20):
which would argue that xsd is correct, since these are references into part 2
Eric Prud'hommeaux (May 13 2016 at 08:21):
yeah, fair point.
Eric Prud'hommeaux (May 13 2016 at 08:22):
though the fact that we have to work around hard-coded prefixes in their implementations really irks me.
Grahame Grieve (May 13 2016 at 08:22):
I think you should regard it as an inevitable consequence of the goofy syntax in this case - implementers find it hard to think about in a structured format
Eric Prud'hommeaux (May 13 2016 at 08:24):
they already have to deal with arbitrary prefixes for everything else or they wouldn't get off the ground
Eric Prud'hommeaux (May 13 2016 at 08:25):
so why such a different codepath for xsd?
Grahame Grieve (May 13 2016 at 08:25):
right. because ^^:xs: looks like some goofy literal.
Eric Prud'hommeaux (May 13 2016 at 08:27):
it's only the diff between PREFIX xs: <...> <s> <p> "..."^^xs:float and PREFIX xsd: <...> <s> <p> "..."^^xsd:float
Eric Prud'hommeaux (May 13 2016 at 08:27):
but actually, you're writing everything in turtle, so you can just use a bareword for integers
Eric Prud'hommeaux (May 13 2016 at 08:28):
that's a well-trod path for protege
Grahame Grieve (May 13 2016 at 08:28):
I don't know what you mean there?
Eric Prud'hommeaux (May 13 2016 at 08:29):
instead of writing some triple:
<s> <p> "1"^^xsd:nonNegativeInteger .
you can just write
<s> <p> 1 .
Eric Prud'hommeaux (May 13 2016 at 08:30):
and reading back, i see the issue was probably not about xs vs. xsd, but instead where the ""s were
Grahame Grieve (May 13 2016 at 09:37):
@Eric Prud'hommeaux Looking through the ttl tests, I found this:
[ <http://a.example/p> <http://a.example/o> ] <http://a.example/p2> <http://a.example/o2> .
Grahame Grieve (May 13 2016 at 09:37):
I had no idea that was allowed. Should we use this form for anonymous resources - that is, ones that have no assigned identity?
Eric Prud'hommeaux (May 13 2016 at 09:39):
there's no semantic diff between
[ <http://a.example/p> <http://a.example/o> ; <http://a.example/p2> <http://a.example/o2> ] .
and
[ <http://a.example/p> <http://a.example/o> ] <http://a.example/p2> <http://a.example/o2> .
and
[] <http://a.example/p> <http://a.example/o> ; <http://a.example/p2> <http://a.example/o2> .
but I find the 1st the clearest and easiest to exploit in bracket-balancing editors
Grahame Grieve (May 13 2016 at 09:40):
but we haven't used any of these for unidentified resources. should we?
Grahame Grieve (May 13 2016 at 09:41):
eg. we haven't said to start with a bnode
Eric Prud'hommeaux (May 13 2016 at 09:41):
unidentified objects in resources, yes, but i don't know how many examples of anon resources we've done in the text.
Eric Prud'hommeaux (May 13 2016 at 09:42):
the xslt that josh, harold and i worked on gives you
[] a fhir:foo ...
if you don't supply it with a docURL parameter
Grahame Grieve (May 13 2016 at 09:43):
well, ok, we better write that up then
Eric Prud'hommeaux (May 13 2016 at 09:45):
agreed. and for syntax, i'd say that { [ all the statements ] . } is nicest for consumers and { [] all the statements . } is easiest to generate. the mix of the two is rarely helpful.
Grahame Grieve (May 13 2016 at 09:47):
(deleted)
Grahame Grieve (May 13 2016 at 09:47):
(deleted)
Grahame Grieve (May 13 2016 at 09:47):
(deleted)
Renato Iannella (May 13 2016 at 12:04):
There is a specific namespace URI for XML datatypes (part 2): https://www.w3.org/TR/xmlschema11-2/#namespaces
But http://www.w3.org/2001/XMLSchema also applies to built-in datatypes.
Which is recommended: https://www.w3.org/TR/swbp-xsch-datatypes/
Renato Iannella (May 13 2016 at 12:05):
Yes @Eric Prud'hommeaux the issue was just the double-quotes (not the namespace prefix)
Grahame Grieve (May 13 2016 at 12:06):
From Renato's reference:
@prefix xsd: <http://www.example.org/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
Grahame Grieve (May 13 2016 at 12:06):
I'm not sure much clarity that brings around the xsd prefix ;-)
Renato Iannella (May 13 2016 at 12:07):
I think that first xsd prefix is a mistake!
Grahame Grieve (May 13 2016 at 12:07):
I think it might be, yes
Harold Solbrig (May 13 2016 at 16:06):
I've got a couple more minor things to cover in the ShEx, but we're proposing a few tweaks in tht ttl as well
Grahame Grieve (May 13 2016 at 16:26):
I think I should get back to testing the ShEx validation as well. I'll try and close the loop on this stuff next week.
Harold Solbrig (May 14 2016 at 15:21):
Good. Will have everything ready to go by then...
Harold Solbrig (May 19 2016 at 17:30):
@Grahame Grieve -- proposed changes to the RDF:
@prefix sct: <http://snomed.info/id/> . <-- instead of .../sct/. This matches the IHTSDO URI spec
uri references in angle brackets rather than quotes:
Coding.system [ fhir:value <http://hl7.org/fhir/observation-category> ];
References:
fhir:link <uri> rather than fhir:reference "uri".
No "Reference" suffix on predicate (subjectReference --> subject)
Add a type arc
example:
fhir:Observation.subject [
a fhir:PatientReference;
fhir:link <http://hl7.org/fhir/Patient/example>;
fhir:Reference.reference [ fhir:value "Patient/example" ]
];
concept codes:
Remove fhir:concept entries directly underneath CodedConcept -- only put them on the coding entries.
fhir:Observation.code [
fhir:concept loinc:29463-7; <-- Remove
fhir:concept loinc:3141-9; <-- Remove
fhir:concept sct:27113001; <-- Remove
fhir:CodeableConcept.coding [
fhir:index 0;
fhir:concept loinc:29463-7; <-- Keep
We've still got an issue with xs: data types in the validator, but should get it resolved today.
Harold Solbrig (May 19 2016 at 17:35):
(be happy to give it a shot if you don't mind me messing with your code...)
Grahame Grieve (May 19 2016 at 20:06):
@Harold Solbrig who proposes these changes? They differ from previous committee dispositions.
Grahame Grieve (May 19 2016 at 20:07):
I made the snomed change.
Grahame Grieve (May 19 2016 at 20:08):
with regard to the URIs, what we decided in Montreal is that we would only use URIs for fhir:reference and fhir:concept, and any fields that are have a type URI would be "" literals.
Grahame Grieve (May 19 2016 at 20:09):
why rename fhir:reference to fhir:link?
Grahame Grieve (May 19 2016 at 20:09):
I don't know what this "No "Reference" suffix on predicate (subjectReference --> subject)" means
Grahame Grieve (May 19 2016 at 20:09):
nor what this is: a fhir:PatientReference;
Grahame Grieve (May 19 2016 at 20:11):
as for removing fhir:concept from CodeableConcept - Lloyd assured the committee with utter certainty that reasoners would be completely unable to reason with fhir:concept on the CodeableConcept, and the committee agreed with that
Harold Solbrig (May 19 2016 at 20:11):
fhir:reference to fhir:link was a decision in a meeting a couple of weeks back. Some how the other decision on uri's didn't get forwarded ...
Grahame Grieve (May 19 2016 at 20:12):
you were in the room..
Harold Solbrig (May 19 2016 at 20:13):
You sure? In any case, fhir subject type Reference --> fhir:subject @<PatientReference> instead of fhir:subjecReference @<PatientReference>
Harold Solbrig (May 19 2016 at 20:14):
wrt. concept in CodeableConcept -- it is still there.
Grahame Grieve (May 19 2016 at 20:14):
I don't understand the reference bit
Grahame Grieve (May 19 2016 at 20:15):
I can easily remove fhir:concept from CodeableConcept. I'll do that now, but Lloyd will flip.
Harold Solbrig (May 19 2016 at 20:17):
fhir:Observation.subjectReference [
fhir:reference <http://hl7.org/fhir/Patient/example>;
fhir:Reference.reference [ fhir:value "Patient/example" ]
]; --> should read "fhir:Observation.subject ["
Harold Solbrig (May 19 2016 at 20:17):
"Lloyd assured the committee with utter certainty that reasoners would be completely unable to reason with fhir:concept..."
Harold Solbrig (May 19 2016 at 20:18):
Did you mean "without"?
Rob Hausam (May 19 2016 at 20:18):
Did you mean something different than "Lloyd assured the committee with utter certainty that reasoners would be completely unable to reason with fhir:concept on the CodeableConcept, and the committee agreed with that"? - because, if I'm reading it correctly, that sounds like a good reason to remove fhir:concept from CodeableConcept
Grahame Grieve (May 19 2016 at 20:18):
I did mean without, yes.
Rob Hausam (May 19 2016 at 20:18):
ok
Harold Solbrig (May 19 2016 at 20:18):
Gotcha
Harold Solbrig (May 19 2016 at 20:18):
Ok - will fix the ShEx accordingly.
Grahame Grieve (May 19 2016 at 20:18):
I've figured out the subjectReference thing. Clear bug in my code
Harold Solbrig (May 19 2016 at 20:19):
Will type "uri" to xsd:string rather than IRI.
Grahame Grieve (May 19 2016 at 20:19):
ok
Rob Hausam (May 19 2016 at 20:21):
I'm not sure it's true that "reasoners would be completely unable to reason with fhir:concept on the CodeableConcept" - particulary if we use a bridging ontology
Harold Solbrig (May 19 2016 at 20:22):
I'm happy to leave them in. I just thought there were there in error.
Grahame Grieve (May 19 2016 at 20:23):
it sounded like a stupid claim to me. If reasoners are actually supposed to be able to reason, as their name suggests, then reasoners should be able to reason some thing as simple as elevating the level of fhir:concept by one. But @Lloyd McKenzie was sure that it was impossible
Grahame Grieve (May 19 2016 at 20:23):
not in error. very deliberate. I'd rather not have them
Harold Solbrig (May 19 2016 at 20:24):
Not a battle worth fighting, imo.
Grahame Grieve (May 19 2016 at 20:24):
so you confirm that the committee wants fhir:link not fhir:reference?
Rob Hausam (May 19 2016 at 20:24):
I'm with you on that, Grahame - we should do some testing
David Booth (May 19 2016 at 20:25):
grahame, from the 4/26 minutes: "AGREED: Change fhir:reference to fhir:link to avoid confusion."
David Booth (May 19 2016 at 20:27):
https://www.w3.org/2016/04/26-hcls-minutes.html#item07
Grahame Grieve (May 19 2016 at 20:31):
ok thanks. done
David Booth (May 19 2016 at 20:32):
grahame and harold, from harold's list above, which items still need to be resolved?
Harold Solbrig (May 19 2016 at 20:32):
One other topic -- lower priority, but we'd like to add an RDF url to the primitive type code extension. Doing way to much translation from XML to be reasonable.
Harold Solbrig (May 19 2016 at 20:33):
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-rdf-type", ...
Grahame Grieve (May 19 2016 at 20:34):
I don't know what you mean, Harold. what 'primitive type code extension'?
Grahame Grieve (May 19 2016 at 20:36):
@David Booth - I think they're all resolved but I predict that the fhir:concept thing will come back to life
Harold Solbrig (May 19 2016 at 20:37):
If you look at, say, dateTime you will find a "_code" entry with a JSON mapping and a XML mapping.
Harold Solbrig (May 19 2016 at 20:38):
Not sure I completely understand the xml entries -- example: "xs:string+" and "anyURI" (without xs), but we're using them to generate the ShEx.
Grahame Grieve (May 19 2016 at 20:39):
umm? I don't see a _code anywhere?
Grahame Grieve (May 19 2016 at 20:40):
are you referring to the http://hl7.org/fhir/StructureDefinition/structuredefinition-xml-type extension?
Harold Solbrig (May 19 2016 at 20:40):
id.profile.json:
Harold Solbrig (May 19 2016 at 20:40):
"type": [
{
"fhir_comments": [
"Note: primitive values do not have an assigned type\r\n e.g. this is compiler magic\r\n XML and JSON types provided by extension"
],
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-regex",
"valueString": "[A-Za-z0-9\\-\\.]{1,64}"
}
],
"_code": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-json-type",
"valueString": "string"
},
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-xml-type",
"valueString": "xs:string+"
}
]
}
}
Harold Solbrig (May 19 2016 at 20:40):
Yes.
Grahame Grieve (May 19 2016 at 20:41):
they should be proper xs: types. I'll investigate.
Harold Solbrig (May 19 2016 at 20:41):
Would like to add structuredefinition-rdf-type
Grahame Grieve (May 19 2016 at 20:41):
but what would we put there for RDF?
Harold Solbrig (May 19 2016 at 20:43):
xs:string for uri, xs:date OR xs:time OR ... for dateTime
Get rid of this code snippet:
// TODO: Remove the next three lines when id.profile, etc gets fixed
xt = xt.replace("+", "");
if(!xt.contains("xs:"))
xt = "xs:" + xt;
return tmplt(PRIMITIVE_ELEMENT_TEMPLATE).add("typ",
xt.replaceAll(",\\s*", " OR ").replaceAll("xs:", "xsd:").replaceAll("xsd:anyURI", "xsd:string").replace("xsd:token", "xsd:string")).render();
Harold Solbrig (May 19 2016 at 20:43):
Which I anticipate will continue to grow.
Harold Solbrig (May 19 2016 at 20:44):
the xs/xsd is irrelvant, obviously, but I'm expecting more regex to be introduced.
Grahame Grieve (May 19 2016 at 21:20):
with regard to the +, the + signifies that the regex contains additional information to the schema type. because in some cases, there's a regex but the schema type represents that inherently.
Grahame Grieve (May 19 2016 at 21:21):
If I remove the + - which I should, then when you are generating the ShEx, you will not know which regexes are restating in built XSD constraints, and which are extra
Grahame Grieve (May 19 2016 at 21:21):
I don't think this matters for you
Grahame Grieve (May 19 2016 at 21:21):
next commit, I am standardising on xsd: for the data types, not xs:
Grahame Grieve (May 19 2016 at 21:21):
including in the structure definitions
Grahame Grieve (May 19 2016 at 21:23):
ok. I am going to generate an RDF extension. It will contain exactly what is in the XML extension, except I will replace anyURI with string.
Harold Solbrig (May 19 2016 at 21:34):
Thanks!
Grahame Grieve (May 19 2016 at 21:56):
ok comitteed
Lloyd McKenzie (May 22 2016 at 15:29):
Lloyd never said that fhir:concept should appear in instances. In fact, I don't want it in instances. My concern was about the ability to *infer* the concept at different levels - sometimes the concept should appear at the CodeableConcept level, sometimes at the Coding level and sometimes at the code level, depending on the data type - and I was concerned that wasn't going to work - which is why I proposed treating all code representations as if they were constraints on CodeableConcept. However, Tony's tests have subsequently suggested this should work. The key thing that matters for me is that the Concept is inferred to be at the attribute level regardless of which data type was used. I.e. If you have a CodeableConcept on Observation.code with 3 codings, the concepts associated with those codings needs to be asserted at the Observation.code level not (or at least not only) at the Observation.code.coding level.
Grahame Grieve (May 22 2016 at 16:17):
very confusing response, Lloyd. if you don't want it in instances, then none of this matters. but I think you do.
Grahame Grieve (May 22 2016 at 16:19):
and the key thing that matters to you is what the question is about. We're proposing that it be asserted on the Coding, not the CodeableConcept, since that's where the concept is actually established
Grahame Grieve (May 22 2016 at 16:20):
at least, that's what the committee decided. So the onus is on you to explain why the most simple of reasoning steps can't be done
Lloyd McKenzie (May 22 2016 at 17:45):
I don't want it in the instances. It can't be depended on because it can't be inferred from the XML or JSON without external knowledge of the terminology. I.e. It can't be dependably populated when round-tripping. If it's going to be present, it should be from pre-processing the instance before analysis.
Lloyd McKenzie (May 22 2016 at 17:45):
The concept absolutely *must* exist at the CodeableConcept level - because that's the semantic.
Lloyd McKenzie (May 22 2016 at 17:46):
Multiple codings are alternative representations of the same concept
Lloyd McKenzie (May 22 2016 at 17:46):
It's the Observation.code or the Procedure.code that the concepts apply to.
Lloyd McKenzie (May 22 2016 at 17:46):
And all of them (from all translations) apply simultaneously.
Lloyd McKenzie (May 22 2016 at 17:47):
If you have two codings on a CodeableConcept that represent concepts that are mutually exclusive, then that's a coding error.
Grahame Grieve (May 23 2016 at 01:20):
anyway, I believe that the generated turtle examples and the generated turtle templates are all now correct.
Grahame Grieve (May 23 2016 at 01:21):
it's time to review them, for anyone who's interested. The validator will validate turtle examples too now.
Grahame Grieve (May 23 2016 at 01:21):
I'm now going to work on updating rdf.html to say what I think it should say.
Michael van der Zel (May 23 2016 at 13:51):
Will there be a RDF track on the FHIR DevDays in november?
Zoran Milosevic (Jun 04 2016 at 00:33):
Excellent point @Josh Mandel ; would be great to see good use cases for the use of RDF representation of FHIR for reasoning purpose; do we have use cases already stated somewhere?
Grahame Grieve (Jun 05 2016 at 12:15):
what comment is this about?
Zoran Milosevic (Jun 05 2016 at 12:52):
Oops ...was a quite old comment of Josh asking 'Do we know anyone in this community who actually wants to do reasoning Based on fhir data and rdf? It would be good too hear from such people :-)' ... sorry ... hope it was answered by now
Grahame Grieve (Jun 05 2016 at 13:09):
we do know people, though I don't know whether there's any formal collection of their requirements
Michael van der Zel (Jun 10 2016 at 17:41):
How do I know a server supports turtle? I expected to find that here: http://hl7-fhir.github.io/http.html
Grahame Grieve (Jun 10 2016 at 20:13):
Conformance.format
Michael van der Zel (Jun 12 2016 at 11:11):
Got it, but Conformance.format doesnot mention turtle.
Grahame Grieve (Jun 12 2016 at 21:33):
right. do you want to create a task to change that
Michael van der Zel (Jun 13 2016 at 10:37):
Yep
Last updated: Apr 12 2022 at 19:14 UTC
