- From: Lloyd McKenzie <lloyd@lmckenzie.com>
- Date: Tue, 9 Dec 2014 07:36:03 -0700
- To: Grahame Grieve <grahame@healthintersections.com.au>
- Cc: David Booth <david@dbooth.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>, "its@lists.hl7.org" <its@lists.hl7.org>
- Message-ID: <CAJ860J+g_UGyU630C4qxDDWiRpFryjf4FLbhQN42VDBmd7xMYg@mail.gmail.com>
Yes. On the profile side, I'm certainly expecting that we'll be looking at adding extensions to profile that allow manifesting relationships between and abstractions of resources and properties, for a start. -------------------------------------- Lloyd McKenzie +1-780-993-9501 Note: Unless explicitly stated otherwise, the opinions and positions expressed in this e-mail do not necessarily reflect those of my clients nor those of the organizations with whom I hold governance positions. On Tue, Dec 9, 2014 at 3:13 AM, Grahame Grieve < grahame@healthintersections.com.au> wrote: > Another option is to add additional information to the definitions so that > you can generate the RDF you want. > > Grahame > > On Tuesday, December 9, 2014, Lloyd McKenzie <lloyd@lmckenzie.com> wrote: > >> I think that any ontology we create will have to be produceable in an >> automated fashion from the FHIR artifacts. Any introduction of >> hand-editing would be unacceptable from a maintainability and consistency >> perspective. So we're looking at mechanical, no matter what. The question >> is what the mechanical outputs would be. >> >> -------------------------------------- >> Lloyd McKenzie >> >> +1-780-993-9501 >> >> >> >> Note: Unless explicitly stated otherwise, the opinions and positions >> expressed in this e-mail do not necessarily reflect those of my clients nor >> those of the organizations with whom I hold governance positions. >> >> On Mon, Dec 8, 2014 at 1:51 PM, David Booth <david@dbooth.org> wrote: >> >>> 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 <david@dbooth.org >>>> <mailto:david@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=grahame@ >>>> 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 / >>>> grahame@healthintersections.com.au >>>> <mailto:grahame@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=david@ >>>> dbooth.org&list=its> >>>> | Terms of use >>>> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules> >>>> >>>> >> >> *********************************************************************************** >> 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=grahame@healthintersections.com.au&list=its> >> | Terms of use >> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules> >> > > > -- > ----- > http://www.healthintersections.com.au / grahame@healthintersections.com.au > / +61 411 867 065 >
Received on Tuesday, 9 December 2014 14:36:54 UTC