|
|
| Line 17: |
Line 17: |
| | | | |
| | Meeting log: | | Meeting log: |
| − | https://www.w3.org/2016/09/06-hcls-minutes.html | + | https://www.w3.org/2016/08/30-hcls-minutes.html |
| − | | |
| − | == Additional Minutes from 5pm Call ==
| |
| − | <pre>
| |
| − | <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
| |
| − | </pre>
| |
