ITS RDF Concall Minutes 20160906

Return to: ITS Main Page > ITS RDF ConCall Agenda > ITS RDF Meeting Minutes > 2016

ITS RDF Teleconference - 06-Sep-2016

Present: Gopi, Rob_Hausam, James_Anderson, Harold_Solbrig, EricP, David_Booth, 5PM_Call: David Booth, EricP, Harold Solbrig, Grahame Grieve

Quorum met: No (No HL7 chair present)

Chair: David Booth

Scribe: David Booth

Meeting log: https://www.w3.org/2016/09/06-hcls-minutes.html

Additional Minutes from 5pm Call

<hsolbrig> https://github.com/w3c/hcls-fhir-rdf/issues/36
<dbooth> Topic: ShEx Validation of Referenced resource
<dbooth> https://www.w3.org/2016/09/06-hcls-minutes.html#item01
<dbooth> harold: ValueSet refs are not necessarily derefable.  No way to know if we have an illformed VS ref.
<dbooth> ... i was suggesting we might want to make a different predicate for VS references.
<hsolbrig> https://github.com/w3c/hcls-fhir-rdf/issues/36
<dbooth> grahame: ConceptMap is for mapping between concepts and terminologies.
<dbooth> ... Allowing StructureDef there was a legacy.
<dbooth> ... We have a lot of work to do in the model mapping space.
<dbooth> ... StructureDef in the source and target is broken.  And it wasn't always like this
<dbooth> ... I think that's an error.  It should only be an ValueSet.
<dbooth> ... It's pretty usefl to say the concepts defined in profiles are actually code systems.
<dbooth> ... Mapping related concetps to rxnorm, etc.
<dbooth> ... conceptmap.html allows you to use them in a terminology context.
<dbooth> ... We should get rid of StructureDefinitionn from sourceReference in the next ballot.
<dbooth> eric: Are there other instances of this problem elsewhere?
<dbooth> harold: THe problem is having a choice -- ValueSet or StructureDefinition.
<dbooth> grahame: we're going to discuss having snomed and loinc return data if you use the right mime type.
<dbooth> ... But valueset refs should resolve, except for implicit refs.  But they don't have to (broken links).
<dbooth> ... It's a deployment question of how you handle broken links.
<dbooth> ... But fhir:Observation.subject can be either a Patient, Group, Device or Location.  Does that cause the same problem?
<dbooth> harold: If the reference does not follow the URI pattern, then the only way to figure out what it is is by derefing the URI.
<dbooth> ... Will I as a consumer behave differently if it is a ref to a device vs a patient?
<dbooth> ... if so, I should know the intent of the creator even if the link is broken.
<dbooth> grahame: This has come up occasionally, but no consensus.  We allow non-RESTful URIs.
<dbooth> ... And some host conformance servers.  The spec is an instance of itself: it's possible to make a static web server be an instance of the spec.
<dbooth> ... The challenge is around  support.
<dbooth> harold: This is a great example: subject is either a Patient or a Device.  Might have a rule saying all Patients must be derefable but I don't care about devices.
<dbooth> ... But since i don't know which it is in advance, I have no way to know which it should be.
<dbooth> grahame: agreed.  You either have to say that everything is derefable . . . and most EHRs do that, but  not other systems.
<dbooth> ... In earlier drafts we had a type on the ref datatype.
<dbooth> ... We took it out later.  But about once a year someone asks for the type.
<dbooth> ... But if you have the URL then it is a performance claim, which may be wrong.  If you cannot retrieve it.
<dbooth> eric: What's the behavior of an ambitious validator there?
<dbooth> ... E.g. Ref to a Patient or Device. 
<dbooth> ... If it isn't one of those URL patterns, then I deref and find the type.
<dbooth> ... But if I get a URL that claims to be a differnet type, then that's failure.
<dbooth> ... If I have a URI that does not indicate the type, and I cannot deref it, then what?
<dbooth> grahame: I have an extensibility framework.  If I cannot retrieve the target, then I put out a warning.  If I get back the contents, I look at what conformance expectations are made about that resource, and validate those.
<dbooth> ... But a ref has conformance expectations.  In the case of Observation, the ref has rules on the target (patient | Device ... ) but in DAF the subject must be a ref to a profile DAF patient, which gives many more conformance requirements.
<dbooth> ... If you are doing RDF work, you'll likely be aggregating a datastore.
<dbooth> ... JSON/XML is about operation data exchange.  Excpectation is to integrate into a deployed framework.  But RDF will be added to a store (with provenance remembered), and it's a different perspective.
<dbooth> ... If it isn't retrievable then I cannot reason on it, and it comes back to what you are doing with your store.
<dbooth> harold: If I have a ref to a DSTU FHIR source, is the machinery in place to recognize that?
<dbooth> grahame: That's hard.  We've said nothing about whther you can or cannot.
<dbooth> ... We expect that the ref will be valid
<dbooth> harold: I assume that at some point we'd want to start putting versions in Accept headers or mime type, but I guess that's in the future.
<dbooth> grahame: Or differnet endpoint.
<dbooth> grahame: in the end it's the user's choice how to handle broken links.
<dbooth> harold: In the shex, we cannot put in the type predicate unless it always yields a type patient.  So we cannot say anything about what what it references: either patient or device or none of the above, which is a tautology
<dbooth> eric: what if the URL is for type Patient, but the type conflicts with the allowed types.
<dbooth> harold: But if we cannot count on the type being in the URL then we can only say it must look like a URI.
<dbooth> dbooth: But you cannot distinguish between a non-conforming URI (that matches the URL pattern by accident) and one that matches the pattern intentionally.
<dbooth> grahame: But you cannot know which is wrong if there is a conflict -- the resource or the reference.
<dbooth> harold: we'll have to decide whether to include URL derefing in the spec.
<dbooth> eric: But what kind of  behavior do we want?
* GrahameGrieve (~GrahameGrieve@public.cloak) has joined #hcls
<ericP> http://piratepad.net/ericP
<dbooth> grahame: proper way to decide if someting is a FHIR RESTful server is to see if it returns a FHIR conformance statement.
<dbooth> eric: If it claims conformance, then it must match the URL pattern
<dbooth> grahame: I would say that there are a set of conformance claims about the target, and check those.
<dbooth> ... For DAF, it isn't enough to ref a Patient, it must be a *DAF* patient.
<dbooth> ... Those are additional conformance claims.
<dbooth> Notes from piratepad: 
<dbooth> [[
<dbooth> What to do when validating a reference?
<dbooth> min: assume it's valid
<dbooth> parse: inspect the URL for type-compatibility -- RESTful server
<dbooth> query: look for type arcs in-graph
<dbooth> GET: fetch the doc and
<dbooth>   404/500:
<dbooth>   200+alien mime type
<dbooth>   200+known mime type + type mismatch with URL -- RESTful server
<dbooth>   200+known mime type + type mismatch with allowed type
<dbooth>   200+known mime type + valid type
<dbooth>     recursively validate (reference may entail non-core shape)
<dbooth>     depth is (probably) parameteric
<dbooth> RESTful -- test for conformance statement at /metadata
<dbooth> ]]
<dbooth> harold: notion of a conformance statement would be interesting to pursue in shex.
<dbooth> s/min:/ min:
<dbooth> s/parse:/ parse:/
<dbooth> s/GET:/ GET:/
<dbooth> ADJOURNED