Possibly a dream ontology would link to more other ontologies, such as
upper level ontologies, but other than that I view it as more of a
stylistic difference: more oriented toward a human conceptualization
that is natural to express in RDF (i.e., reflecting RDF's natural style).
But one problem is that the whole notion of a dream ontology is very
subjective, and this means that it is apt to take a lot more work to
reach convergence on it. That is why I think it is important to
prioritize a mechanical ontology first, so that we can progress as
rapidly. If at some later point we wish -- and we are able -- to
converge on a dream ontology then that's great, and it could complement
the mechanical ontology for those who wish to use it. But I think it
would be a big mistake to try for that at the outset.
Again, the distinction between mechanical ontology and dream ontology is
qualitative, fuzzy and subjective: to the extent that we can make a
mechanical ontology that is human friendly and natural to RDF, that
would of course be ideal. I just want to guard against going down a
potential rat hole from the start. :)
David
On 12/08/2014 02:24 PM, Grahame Grieve wrote:
can you explain your dream ontology more? what sort of things does it do?
Grahame
On Tue, Dec 9, 2014 at 6:01 AM, David Booth <da...@dbooth.org
<mailto:da...@dbooth.org>> wrote:
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
******************************__******************************__***********************
Manage subscriptions - http://www.HL7.org/listservice
View archives - http://lists.HL7.org/read/?__forum=its
<http://lists.HL7.org/read/?forum=its>
Unsubscribe -
http://www.HL7.org/tools/__unsubscribe.cfm?email=grahame@__healthintersections.com.au&__list=its
<http://www.HL7.org/tools/unsubscribe.cfm?email=grah...@healthintersections.com.au&list=its>
Terms of use -
http://www.HL7.org/myhl7/__managelistservs.cfm?ref=nav#__listrules
<http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
--
-----
http://www.healthintersections.com.au /
grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au> / +61 411 867 065
***********************************************************************************
Manage your subscriptions <http://www.HL7.org/listservice> | View the
archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
<http://www.HL7.org/tools/unsubscribe.cfm?email=da...@dbooth.org&list=its>
| Terms of use
<http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
