Stream: ontology
Topic: ShEx
Grahame Grieve (Apr 12 2016 at 22:02):
@Eric Prud'hommeaux , I'm going to use shexcala for shex validation. It's my only choice. Do you think that will be ok?
Grahame Grieve (Apr 13 2016 at 21:12):
hmm. the documentation is pretty sparse....
Grahame Grieve (Apr 14 2016 at 06:01):
the build has updated to generate ShEx for everything. See the current build - look for 'alternate definitions" on each resource page. or else you can get the full ShEx from the downloads page
Grahame Grieve (Apr 14 2016 at 06:01):
the ShEx is not right; Harold is working on getting it right.
Grahame Grieve (Apr 14 2016 at 06:02):
Once he's done doing that, I'll inject hyperlinks in the appropriate places
Michael van der Zel (Apr 14 2016 at 09:17):
Cool! I miss a couple of predicates, like fhir:index, fhir:nodeRole, fhir:reference. How will those end up in the ShEx?
Grahame Grieve (Apr 14 2016 at 09:27):
Those are some of the things we haven't done yet. @Eric Prud'hommeaux may want to comment about fhir:index - how would we define that? it's a property of the use of the thing, not the thing itself
Josh Mandel (Apr 14 2016 at 11:43):
The only pattern I know to avoid gunking up the list entries is to wrap them in "slots", and put the "index" property on the slot. Like http://smiy.sourceforge.net/olo/spec/orderedlistontology.html (Note that, like their examples, I wouldn't bother with "next" links between slots!)
Josh Mandel (Apr 14 2016 at 11:45):
Lists appear often enough in FHIR that I doubt this pattern is worth polluting our instance data, though.
Josh Mandel (Apr 14 2016 at 11:50):
Could SHex provide a notion of online shape unions or some such, so we could say something :related @<IssueShape & ListItem>* , where ListItem would just be a shape that required one ":index xsd:int" property? @Eric Prud'hommeaux
Grahame Grieve (Apr 14 2016 at 12:05):
mixins.... that'd be a cool solution for that problem. Might have other stings in the tail... mixins usually do....
Eric Prud'hommeaux (Apr 14 2016 at 12:36):
/me finally found his way here...
Eric Prud'hommeaux (Apr 14 2016 at 12:37):
in order:
@Grahame Grieve re shexscala, sure, will invite labra to this chat as soon as i figure out how to do that
Grahame Grieve (Apr 14 2016 at 12:38):
just send him to chat.fhir.org
Eric Prud'hommeaux (Apr 14 2016 at 12:40):
iI expect we'll have to sprinkle fhir:index into every place it can appear because we don't have a notion of a meta shape which controls the generation of shapes. Sprinkling is kind of a pain but very explicit.
Grahame Grieve (Apr 14 2016 at 12:40):
the trouble with sprinkling is that you define it in the type, but it can only be used when the type is used in a list
Grahame Grieve (Apr 14 2016 at 12:40):
and that's not explicit
Eric Prud'hommeaux (Apr 14 2016 at 12:41):
ditto fhir:nodeRole, though that won't show up in as many places 'cause we only have one role (so far) and it appears at the root of any resource
Grahame Grieve (Apr 14 2016 at 12:41):
yes that's a simple case
Eric Prud'hommeaux (Apr 14 2016 at 12:42):
the sprinkling effectively takes the place of saying that something is an array of X, right?
Grahame Grieve (Apr 14 2016 at 12:43):
uh? say, Coding. It appears in some places as code : Coding 0..1, and others as code : Coding 0..*. So in the second place, it must contain a fhir:index, and the the first, it cannot
Grahame Grieve (Apr 14 2016 at 12:44):
I think you are saying, you just define fhir:index as an optional property everywhere, and ShEx can't validate that it's being used properly
Eric Prud'hommeaux (Apr 14 2016 at 12:49):
let's invent a resource with both: Justification.code and Justification.actions
Eric Prud'hommeaux (Apr 14 2016 at 12:52):
<JustificationSh> {
fhir:Justification.code @<codeSh>,
fhir:Justification.actions @<codeListEntrySh>* }
<codeSh> { fhir:value LITERAL, ...I forget... }
<codeListEntrySh> { fhir:index xsd:integer, fhir:value LITERAL, ...I forget... }
Eric Prud'hommeaux (Apr 14 2016 at 12:52):
the latter is a bit annoying, but you can use the &<shape> inclusion to simplify it:
<codeListEntrySh> { fhir:index xsd:integer, &<codeSh> }
Grahame Grieve (Apr 14 2016 at 12:53):
so that's pretty much what Josh proposed then?
Eric Prud'hommeaux (Apr 14 2016 at 12:54):
so ultimately, we end up creating a <X ListEntrySh> { fhir:index xsd:integer , &<X> } for every listable.
Eric Prud'hommeaux (Apr 14 2016 at 12:55):
close, though maybe his idea is better. reflecting...
Eric Prud'hommeaux (Apr 14 2016 at 12:57):
yeah, I think Josh's proposal is closer to this:
<JustificationSh> {
fhir:Justification.code @<codeSh>,
fhir:Justification.actions { fhir:index xsd:integer, @<codeSh> } }
Eric Prud'hommeaux (Apr 14 2016 at 12:57):
which seems like a better idea
Grahame Grieve (Apr 14 2016 at 12:58):
<JustificationSh> {
fhir:Justification.code @<codeSh>,
fhir:Justification.actions { fhir:index [int], @<codeSh> } }
Grahame Grieve (Apr 14 2016 at 12:58):
? how to do the int bit?
Eric Prud'hommeaux (Apr 14 2016 at 12:59):
just fixed my example to do just that
Grahame Grieve (Apr 14 2016 at 13:00):
k thx. Haorld will go with your last unless we hear otherwise
Harold Solbrig (Apr 14 2016 at 13:01):
Gotta say, I wonder what the value is of making this aspect explicit in ShEx. index is list ordering, correct?
Grahame Grieve (Apr 14 2016 at 13:02):
well, because it's required in the RDF.
Grahame Grieve (Apr 14 2016 at 13:02):
ShEx is just describbing the RDF.....
Harold Solbrig (Apr 14 2016 at 13:02):
We could step out of shex and say that the list is ordered on the index key when going into ShEx
Eric Prud'hommeaux (Apr 14 2016 at 13:03):
the list/singleton dichotomy always sucks in RDF (or any graph language)
Harold Solbrig (Apr 14 2016 at 13:03):
ShEx is definitely describing a subset of the RDF, but the question is it intended to be open or closed.
Grahame Grieve (Apr 14 2016 at 13:03):
ir should validate as much as possible
Harold Solbrig (Apr 14 2016 at 13:03):
But we have enough prior knowledge to know what is list and what is singleton
Grahame Grieve (Apr 14 2016 at 13:04):
so? a ShEx evaluator doesn't
Eric Prud'hommeaux (Apr 14 2016 at 13:04):
when validating, should it reject a singleton with a fhir:index property?
Grahame Grieve (Apr 14 2016 at 13:04):
one that can only be a singleton yes
Grahame Grieve (Apr 14 2016 at 13:05):
profiles make this complicated
Harold Solbrig (Apr 14 2016 at 13:05):
I would push back on the "as much as possible" -- if RDF were my primary format, it would be really painful to inject indices into lists. I would expect translation tools to add them in ...
Harold Solbrig (Apr 14 2016 at 13:05):
I would argue we should say "as much as is sensible" (or practical or some such thing)
Grahame Grieve (Apr 14 2016 at 13:05):
how would they know what the right order is?
Harold Solbrig (Apr 14 2016 at 13:06):
The notion that all formats have to carry the foibles of any format leads to a lot of pain.
Harold Solbrig (Apr 14 2016 at 13:06):
(That said, I'm happy to do as instructed on the ShEx itself -- merely injecting an opinion past my pay grade)
Grahame Grieve (Apr 14 2016 at 13:07):
i don't think thats what's going on here at all
Harold Solbrig (Apr 14 2016 at 13:07):
RDF lists are ordered
Grahame Grieve (Apr 14 2016 at 13:07):
order within a list is significant
Grahame Grieve (Apr 14 2016 at 13:07):
we chose to use fhir:index not RDF lists
Harold Solbrig (Apr 14 2016 at 13:07):
The question becomes, what do we do with ([fhir:index 2] [fhir:index 1])?
Harold Solbrig (Apr 14 2016 at 13:08):
Ok
Grahame Grieve (Apr 14 2016 at 13:08):
so ShEx should say so
Harold Solbrig (Apr 14 2016 at 13:08):
So we need to make it clear that, despite the fact that RDF lists are ordered, we are to treat them as unordered for the purposes of FHIR?
Grahame Grieve (Apr 14 2016 at 13:09):
I'll defer to Eric or David on that
Harold Solbrig (Apr 14 2016 at 13:09):
(fine by me, just want to make sure that this is what we want...)
Harold Solbrig (Apr 14 2016 at 13:10):
@Eric Prud'hommeaux -- Can ShEx enforce ordering on a list?
Eric Prud'hommeaux (Apr 14 2016 at 13:31):
no, but i think that will come with the key feature we wanted to add
Eric Prud'hommeaux (Apr 14 2016 at 13:34):
key or unique (the naming dilema is part of the obstacle) comes up in lots of places, from the obvious one of making sure that all of the Foo shapes have a unique combination of list of properties (e.g. only one AddressShape for any combo of street number and street name) to making sure that something has only one skos:prefLabel for any given language tag
Eric Prud'hommeaux (Apr 14 2016 at 13:35):
this doesn't make sure that the indexes are contiguous and start with 0, but it does make sure that at least there are no duplicates
Michael van der Zel (Apr 15 2016 at 09:58):
Yes.
Michael van der Zel (Apr 15 2016 at 10:27):
@Grahame Grieve or @Harold Solbrig Maybe you already said this, but why is Element.id there multiple times? And why is Observation.value missing?
Grahame Grieve (Apr 15 2016 at 10:28):
because I just threw something in there so that it would generate something. Harold is working on it making it generate correctly
Michael van der Zel (Apr 15 2016 at 13:09):
Got it. Great start.
Harold Solbrig (Apr 15 2016 at 14:25):
I'll have something more useful in a little later today...
Grahame Grieve (Apr 18 2016 at 23:28):
ok Harold, here we go, questions about the ShEx:
Grahame Grieve (Apr 18 2016 at 23:28):
fhir:AllergyIntolerance.recorder ( @<PractitionerReference> OR @<PatientReference> )?,
Grahame Grieve (Apr 18 2016 at 23:29):
how are PractitionerReference and PatientReference different?
Grahame Grieve (Apr 18 2016 at 23:30):
actually, the content model for them is wrong anyway. I'll change it, and you can review
Michael van der Zel (Apr 19 2016 at 09:15):
Question. Is the order of the triples important? I would say not. But does ShEx check this?
Grahame Grieve (Apr 19 2016 at 09:17):
I think order doesn't matter.
Michael van der Zel (Apr 19 2016 at 09:21):
There is difference between PractitionerReference and PatientReference.. The first References a Practitioner and the second Patient. So the datatype is the same "Reference" but there is a restriction on what they reference.
Michael van der Zel (Apr 19 2016 at 09:28):
And.. I thought it was recorderReference in rdf?
Grahame Grieve (Apr 19 2016 at 10:42):
But it doesn't make any difference to the the type. The URL is opaque. It does make a difference to the fhir:reference though. How do you use shed to limit the properties of that? I think it's exactly the same... So an inline combo of reference and the referenced thing
Grahame Grieve (Apr 19 2016 at 21:14):
no RDF call today? the sticking point for me right now is how to validate an turtle file against a ShEx file from java code - the wiki for the scala code says there's an example, but it's not actually a link
Lloyd McKenzie (Apr 19 2016 at 22:23):
Not enough people could make it.
Eric Prud'hommeaux (Apr 22 2016 at 15:20):
order doesn't matter. ShEx provides an ordered traversal of an unordered graph
Stephen Royce (May 09 2016 at 07:15):
Just curious: why did you choose ShEx over SHACL?
Grahame Grieve (May 09 2016 at 08:29):
on the say of @Eric Prud'hommeaux
Eric Prud'hommeaux (May 09 2016 at 11:32):
once SHACL gets a bit more stable in its syntax, we can convert back and forth
Stephen Royce (May 09 2016 at 22:18):
:)
Renato Iannella (May 19 2016 at 02:42):
What is the planned scope for ShEx (or SHACL) for FHIR? (ie: what aspects of the RDF Representation of FHIR will it address)
Last updated: Apr 12 2022 at 19:14 UTC
