See also: IRC log
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20160920
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20161011
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20161101
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20161115
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20161122
http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20170103
Minutes Approved! 2 abstain, 7 for, 0 against
<ericP> ShEx CG formed before xmass
<ericP> https://www.w3.org/community/shex/
eric: shex community group formed
before christmas, 20 members, 5 implementations
... expect to ratify the RDF representation this week.
... Have implementation reports for 3 implementations. 800
validation tests, 400 syntax tests, and some structural
tests
... Have a tutorial but needs more lovin. Spec is in pretty
good shape, but if we ratify the RDF rep then it will need more
text to define the @context and describe the parsing for
recognizing the schema.
... People can now participate without being w3c members,
because it is a community group.
... shex is a schema language for RDF. It's main value is sound
semantics from people from University of Lille, and it has a
couple other representations that it can round-trip
through.
... purpose of other reps is to programmatically construct the
schema language, such as in FHIR RDF pages on github, that shex
is pretty printed, but can also be serialized by consuming a
structure def and emitting a json structure for equiv schema in
shex.
... Plan to do that and check it against the pretty printed
syntax.
harold: in talking about abstract
syntax trees, would be useful to create a FHIR logical model of
the shex syntax tree. that would open up possibilities, also
model-driven nicities about constructing classes. would allow
shape expressionsn without going through the formal
grammer.
... At the moment we emit strings.
... If we're in the business of building abstract syntaxes,
then we could ...
grahame: Never occurred to me
that you might want to do that.
... You might reverse engineer back to logical model then
forward engineer to what you want . . . almost.
harold: The JSON is very json-centric. I earlier worked on an XML abstract syntax, and put effort into making it easy for people who read xml.
<ericP> JSON Grammar for the JSON grammar
harold: How close do they have to match?
grahame: If I were eric, i'd be very interested in an abstract syntax.
ken: We've done a little bit of models for resources
harold: we'd want to back off to UML (except that UML doesn't work that well) and shex works better.
(Eric shows the grammar of shexj at https://github.com/shexSpec/shexTest/blob/master/doc/ShExJ.jsg )
eric: I think we could wedge most of that into FHIR
grahame: If I turned that into a FHIR logical model, I think you'd lose some expressivity around the grammar, but you'd get much more knowledge.
harold: This is the AST for the grammar.
grahame: someone will start
asking why shouldn't we produce JSGs for FHIR
... Is there a validator?
eric: Yes, one.
<ericP> JSG online validator
eric: here's an example of
validating an address
... It has recursive shapes, etc.
... Do we want to express shexj in FHIR?
grahame: We'll come back to both JSG and ... want to continue discussing logical model for shex?
harold: Wanted to get it on
people's thoughts.
... We have the BNF for the syntax, etc. I like having an API
for a model, and JSG does not have API generators, and I wanted
some tech that generates APIs.
dbooth: How best to follow up?
eric: let folks with skin in the
game think about it a little first.
... Grahame has the shex validation working?
grahame: Using Jose's validator, and it's giving slightly different answers from Eric's, but it's almost there.
harold: This is a diag report in
json, pulled from FHIR. It has a conclusion with a SNOMET CT
coding.
... If we look at it in RDF, we have the RDF equiv, where we've
added a fhir:concept assertion, because the URI for that snomed
concept is not mechanically creatable from the code and
system.
... Doing it in OWL reasoner is not the way to do it. It is
done in a preprocessing step instead.
... The challenge: can I take this record, with snomed ct, and
determine whether this pt has cancer?
... Start w a FHIR DiagnosticReport. Inserted owl:Ontology
assertion.
... Then created RDF semantics, OWL ont. Should be the OWL ont
generated by the FHIR build process, but I hand gen this
one.
... Used a subset of snomed ct, but FACT++ is too slow for the
whole of snomed.
... We used a tool to grab a subset of the OWL that we
need.
... Then we wrote the query as an OWL class def.
... Defined hasDiagnosis, using a property chain.
... But with semantics of fhir:concept, the snomed concept must
be an instance -- not a class.
... So I had write "fhir:concept [ a sct:553490112]" instead of
sct:553490112
... But bnodes cause grief. So we created a new URI for the
snomed concept: sct:SCT553490112 (instance) corresponding to
sct:553490112 (class).
grahame: what about defining fhir:concept as a subProperty of rdf:type?
eric: OWL doesn't treat rdf:type as a regular property. It doesn't have axioms about it.
harold: instances of classes exist in snomed ct, but there are an infinite number of classes of classes. snomed cannot name them all.
grahame: But it's strange for the
user to define those names.
... There's a conceptual misalignement between snomed and ont
rep.
... I say that a patient is assigned a med of this type.
harold: This issue is not
specific to snomed. It is about OWL.
... You have a class that represents tumors, and that's a set
of all instances of tumors.
... When we reason about class person, joe is a person -- an
instance.
... Here we're saying this diagnosis is an instance of tumor
class.
grahame: Have you looked at the
FHIR ont, at fhir.ttl?
... That holds all of the defs for the FHIR/RDF wire
format.
... fhir:concept is missing though.
harold: Can we define fhir:concept as a subPropertyOf rdf:type?
eric: No
harold: That's the one property that is special to OWL, and you can define a subPropertyOf it.
grahame: THis feels like a
terminiology problem. SHouldn't have to invent a name in the
fhir space.
... The instance data user should not have to bridge between
the instance and class of the terminology. That should be the
business of the terminology.
harold: But for post-coordinated expressions, we cannot define a URI for every one of them.
grahame: If you are precoordinating then the terminology could provide them, but if you are postcoordinating then you could use this trick.
harold: The only issue is that this belongs in the snomed namespace?
eric: people have glossed over this in the past
dbooth: Weird to say that two patients have the exact same disease instance.
grahame: No, it is saying they have the same diagnosis.
eric: The thing that's pointing
to me has a member of this class.
... snomed describes observations.
harold: no, it's anybody who
writes OWL DL. They'll have to create instances of their
classes.
... Need to engage Daniel, Steffan, Michael Wally
<scribe> ACTION: Harold to follow up on fhir:concept issue of instance vs class [recorded in http://www.w3.org/2017/01/17-hcls-minutes.html#action01]
<trackbot> Created ACTION-74 - Follow up on fhir:concept issue of instance vs class [on Harold Solbrig - due 2017-01-24].
harold: fhir:concept issue is
around OWL.
... We've been slipping other things into RDF also, such as
fhir:index.
harold: Should we create a linked
data profile? If I'm in XML and want to get to OWL I still need
a URI.
... Should we define a FHIR profile that adds these features,
such as fhir:concept, fhir:index?
eric: The main one is whether you can look at a reference and know its type.
grahame: In effect the RDF page
is a profile on the content -- these are the things you're
expected to do if you're using RDF.
... If you look at the things that are different in FHIR/RDF,
they have different purposes. Some are in the turtle as a
work-around for different serializations, and they appear in
the JSON-LD in order to produce the same triples. treeRoot
would otherwise be superfluous in JSON-LD.
... Then there's denormalizing the patient or ref type -- not
the same as an extension. If you added info about the ref
target, that would be unnatural in XML or JSON.
... We said that you might want to round-trip fhir:concept, but
we didn't add the fhir ext (yet) to do that.
harold: simple way would be to define fhir extensions
<scribe> ACTION: Grahame to create an extension for fhir:concept and fhir:link type [recorded in http://www.w3.org/2017/01/17-hcls-minutes.html#action02]
<trackbot> Error finding 'Grahame'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
grahame: FOAF has a document concept, and items can appear in a document. Should we use that instead of treeRoot?
harold: How would bundle relate to document?
grahame: Typically a bundle is a
document.
... a Document cannot contain a Document.
<scribe> ACTION: DBooth to put this on agenda for a future call [recorded in http://www.w3.org/2017/01/17-hcls-minutes.html#action03]
<trackbot> Error finding 'DBooth'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
dbooth: Please review and provide suggestions/comments.
harold: would still like to discuss fhir:index sometime.
ADJOURNED
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/index./index?/ Succeeded: s/document?/document./ No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Present: EricP Dale_Nelson Grahame_Grieve Vassil_Paytchev Brian_Pech Michael_van_der_Zel David_Booth Ken_Lord Sarah_Ryan Paul_Knapp Found Date: 17 Jan 2017 Guessing minutes URL: http://www.w3.org/2017/01/17-hcls-minutes.html People with action items: dbooth grahame harold[End of scribe.perl diagnostic output]