Hi Lloyd,
On 12/08/2014 01:35 PM, Lloyd McKenzie wrote:
I think we need to define our objectives for the RDF representation.
Mine are as follows:
Great list! My comments . . .
1. It must be possible to round-trip from XML/JSON through RDF
representation
+1
* This includes retaining information about order of repeating elements
Is the order of repeating elements semantically significant in FHIR?
I.e., would it affect or use of the interpretation of the information?
If not, then why do you view this as important? (Playing devil's
advocate here, to elicit the rationale.)
* Needs to allow for extensions where-ever they can appear, including
simple types (date, boolean, etc.)
+1
2. We want to be able to represent instances as RDF
+1
and Profiles as OWL/RDFS
+0.9. I think the profiles MUST be represented in some form of RDF, but
whether it is done using OWL, RDFS or some combination of OWL, RDFS and
something else (SKOS?) I think should be a judgement call that is made
as we go along.
3. Syntax needs to be "safe" when dealing with modifier extensions
4. Syntax should support vocabulary bindings to code, Coding and
CodeableConcept - including dealing with extensible value sets and
multi-code system value sets
5. Syntax should enforce constraints that are representable in RDF (i.e.
schema constraints, regular expressions, etc.)
Can you explain what you mean by syntax in the above? For example, if
Turtle is used to serialize the RDF, what would the above points mean?
6. In the RDFS/OWL, should expose at least minimal annotation
information for display
+1
BTW, there's another distinction that Eric Prud'hommeaux used to
distinguish between different ontology styles or goals. I think he
referred to one style as a "mechanical" ontology, which might be fairly
directly derived from the FHIR spec and is oriented mainly toward ease
of round tripping between RDF and XML or JSON. The other style is a
"dream" ontology, which is friendlier and more natural for humans to
view and may take more work to converge upon. The two are not mutually
exclusive, of course, but in prioritizing our work effort I'm of the
opinion that we should FIRST go for the mechanical ontology, and once
we've got that sufficiently nailed down, we could try to figure out a
dream ontology, with the ability to automatically translate instance
data between the two.
Thanks,
David Booth