Difference between revisions of "FHIR Ontology Requirements"
m |
|||
| Line 6: | Line 6: | ||
:: ''ANSWER''(LM): Yes. Or more specifically, it's allowed to be. Order of medications in a list, order of names, etc. is required to be retained and, depending on the definition of the element, can have meaning. As well, retaining order is essential to allow digital signature validation after round-tripping | :: ''ANSWER''(LM): Yes. Or more specifically, it's allowed to be. Order of medications in a list, order of names, etc. is required to be retained and, depending on the definition of the element, can have meaning. As well, retaining order is essential to allow digital signature validation after round-tripping | ||
* Needs to allow for extensions where-ever they can appear, including simple types (date, boolean, etc.) | * Needs to allow for extensions where-ever they can appear, including simple types (date, boolean, etc.) | ||
| + | |||
2. We want to be able to represent instances as RDF and Profiles as OWL/RDFS | 2. We want to be able to represent instances as RDF and Profiles as OWL/RDFS | ||
3. Syntax needs to be "safe" when dealing with modifier extensions | 3. Syntax needs to be "safe" when dealing with modifier extensions | ||
| + | : ''QUESTION: What is meant by "syntax"? RDF has several serializations. What syntax do you mean?'' | ||
4. Syntax should support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets | 4. Syntax should support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets | ||
| Line 17: | Line 19: | ||
7. It would help if all dataTypes (date, dateTime, value, etc.) are not expressed as string literal. Ultimately they should be expressed in a way to help reasoning engine for inference purposes (xsd). | 7. It would help if all dataTypes (date, dateTime, value, etc.) are not expressed as string literal. Ultimately they should be expressed in a way to help reasoning engine for inference purposes (xsd). | ||
| + | |||
| + | 8. Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation | ||
| + | |||
| + | 9. Enablement of OWL/RDFS inference – so we could identify use cases that cannot be easily done based on the XML/JSON representation | ||
| + | |||
| + | 10. A common OWL/RDFS representation for information model elements and medical terminology concepts. | ||
| + | |||
| + | 11. It must capture all of the standard semantics of FHIR XML and JSON data that are independent of the choice of serialization. (This is closely related to #1.) | ||
Revision as of 19:54, 11 December 2014
DRAFT
1. It must be possible to round-trip instance data from XML/JSON through RDF representation
- This includes retaining information about order of repeating elements
- QUESTION: Is the order of repeating elements semantically significant in FHIR? I.e., would it affect or use of the interpretation of the information?
- ANSWER(LM): Yes. Or more specifically, it's allowed to be. Order of medications in a list, order of names, etc. is required to be retained and, depending on the definition of the element, can have meaning. As well, retaining order is essential to allow digital signature validation after round-tripping
- Needs to allow for extensions where-ever they can appear, including simple types (date, boolean, etc.)
2. We want to be able to represent instances as RDF and Profiles as OWL/RDFS
3. Syntax needs to be "safe" when dealing with modifier extensions
- QUESTION: What is meant by "syntax"? RDF has several serializations. What syntax do you mean?
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.)
6. In the RDFS/OWL, should expose at least minimal annotation information for display
7. It would help if all dataTypes (date, dateTime, value, etc.) are not expressed as string literal. Ultimately they should be expressed in a way to help reasoning engine for inference purposes (xsd).
8. Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation
9. Enablement of OWL/RDFS inference – so we could identify use cases that cannot be easily done based on the XML/JSON representation
10. A common OWL/RDFS representation for information model elements and medical terminology concepts.
11. It must capture all of the standard semantics of FHIR XML and JSON data that are independent of the choice of serialization. (This is closely related to #1.)
