Hi Tony,
I don't think I'm following. There should be no need for
custodian-specific ontologies. The sender never needs to identify a
profile in the instance. Some senders may choose to specify a profile in
the instance (or even 20 different profiles in the instance), but the
sender isn't requi
On 12/21/2014 09:04 PM, Timothy W. Cook wrote:
On Sun, Dec 21, 2014 at 8:08 PM, David Booth mailto:da...@dbooth.org>> wrote:
But FYI, the reason Cecil presented his ontology was to allow us to
compare and contrast the various approaches that different
individuals have taken toward de
On Sun, Dec 21, 2014 at 8:08 PM, David Booth wrote:
>
> But FYI, the reason Cecil presented his ontology was to allow us to
> compare and contrast the various approaches that different individuals have
> taken toward developing a FHIR ontology. (Others were presented
> previously.) The joint HL
Hi Kingsley,
Good idea.
But FYI, the reason Cecil presented his ontology was to allow us to
compare and contrast the various approaches that different individuals
have taken toward developing a FHIR ontology. (Others were presented
previously.) The joint HL7-W3C group on RDF for Semantic In
On 12/19/14 3:27 PM, David Booth wrote:
FYI, I have uploaded the FHIR ontology that Cecil Lynch discussed on
Tuesday's call. It is available both in Turtle and RDF/XML, for those
who would like to examine it in more detail or play with it:
http://tinyurl.com/fhir-cecil-lynch-ttl
http://ti
Hi Lloyd,
It will be worth more discussion on the ontology structures.
At the profile instance level (the FHIR RDF message) the ontologies are
probably associated with the custodian of the record – they assigned the
identities (unique within their ontology). When you query and aggregate FHIR
R
Hi Tony,
Every profile instance will be its own ontology and will import the "base"
ontology it's built on top of. All instances will be bound to the base
resource profile, but I think we should be cautious about importing
referenced profiles.
In FHIR you don't need to reference a profile in ord
Lloyd,
Each Profile ( or group of profiles) would be in its own ontology which might
import the raw FHIR type ontology and restrict/extend it. This means that when
we bind from the instance to the type, the type is in the named profile
ontology (unambiguous).
All importing in my approach is done
Hi Peter,
Yes, we'll definitely want to model the FHIR instance expression in such a
way that it closes the world (or at least allow for a closed world form) in
a similar manner to what I did for v3.
--
Lloyd McKenzie
+1-780-993-9501
Note: Unless explicitly
Hi Vipul,
Yes, we'll be creating two different forms. Instances will be expressed in
RDF - and round-trippable between the JSON and XML syntaxes. At that
level, all you'll have is data - no "knowledge". Profiles we will also
convert to RDFS/OWL/something which will reflect things such as constr
Hi Matthias,
You're touching on an important point that I think we have not yet
articulated well enough.
No *single* ontology will meet all of the diverse use cases that occur
in healthcare and biomedical applications. That's obvious at one level,
but less obvious -- though still true -- ev
Peter,
The experiments with the separation of the Ontologies SNOMED, FHIR (Profile)
and FHIR instance support the argument not to combine since you can make
references across Ontologies without putting them into one.
The OWL Import statement works very well so when you are selecting a SNOMED
co
12 matches
Mail list logo
