Probably best moved to the Ontolog Forum, if this thread continues.
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Simon Spero
Sent: Tuesday, March 10, 2015 1:32 PM
To: Ontology Summit 2010 discussion
Subject: Re: [ontology-summit] FW: Proposed RDF FHIR syntax feedback
There are also named individuals that can appear in the T-Box - SH_O_IN(D).
There can also be anonymous individuals as annotation values. (This triggered a horrible bug in the OWLAPI when used with punning.)
On Mar 10, 2015 12:43 PM, "Obrst, Leo J." <lobrst@xxxxxxxxx> wrote:
FYI. Pat Hayes referring to Ontology Summit 2007.
-----Original Message-----
From: Pat Hayes [mailto:phayes@xxxxxxx]
Sent: Sunday, March 08, 2015 2:31 PM
To: Anthony Mallia
Cc: David Booth; public-semweb-lifesci@xxxxxx; HL7 ITS
Subject: Re: Proposed RDF FHIR syntax feedback
Comments in-line:
On Mar 8, 2015, at 9:00 AM, Anthony Mallia <amallia@xxxxxxxxxxxxx> wrote:
> David,
>
> I believe that this is an important aspect to distinguish between the type or TBox and the instance or ABox. A simple justification is that they come from different authorities (and end points) - HL7 or an EHR system.
If there is any other reason to distinguish them, please list as many of them as you can. If this is the only reason, I would strongly suggest that it is not a sufficient reason for introducing this rigid distinction into the foundation. It would be better
to provide a mechanism to allow the kind of originating authority to be specified explicitly. The question to ask is, what utility in actual processing will arise from having this distinction rigidly enforced? The problems it (artificially) introduces is that
it makes most OWL2 ontologies unclassifiable, since many of them contain both class and instance data: in fact, OWL2 punning makes this very distinction rather hard to detect, since a class in OWL 2 may itself be an instance; and it forces users to make a
needless classification decision which may give rise to errors and difficulties in processing.
> However I would strongly recommend that we DO NOT REDEFINE Ontology from its definition in the W3C specs - this will cause major confusion.
>
> Here is the extract from OWL2:
> "OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents."
That defines an OWL2 ontology. If you are planning to use other representation languages, I would suggest adopting a wider definition of the bare concept of 'ontology'. By the way, this topic - how to define 'ontology' - was discussed in depth for a year in
the Ontolog forum. I recommend reading
http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2007_Communique and the surrounding discussions before coming to a decision.
> So I am recommending two subtypes of Ontology :
> INSTANCE ONTOLOGY (INSTANCE for short) contains Individuals, their Property assertions and their data values but may refer to contents of MODEL(s)
I think you mean it contains individual *names*, right?
When you say 'may refer to', what distinction are you making between 'refer to' and 'contain'? Do you mean it will not contain the *definitions* of the classes, etc.? But there is no concept of 'definition' in the RDF/OWL world.
> MODEL ONTOLOGY (MODEL for short) contains Classes, ObjectProperties, DataProperties and Datatypes
And what will you do with something which contains large amounts of instance data, described using a mixture of vocabulary from a number of other ontologies and a small number of class and property definitions local to it? Because this is, if anything, the
normal situation in Web-based ontology work.
>
> INSTANCE and MODEL are disjoint
Which, if enforced, is going to create errors and blocks to processing for no functional reason. Why do this? It is a bad design decision to introduce distinctions that have no utility other than to be enforced and generate error messages. If this is a genuine
type distinction, then you should be able to say what reasons there are for a processor to know what type an ontology is. How will an INSTANCE be processed differently from a MODEL?
> but there can be Ontologies (neither of these subtypes) which combine them through merge or import and would be used for reasoning.
> It should not be necessary to separate these two by MIME type - they will be handled quite differently e.g. import statements will know exactly what they are trying to do.
importing is completely transparent to this distinction. Both of them (and any hybrids) will be imported in the same way using the same mechanisms. This is part of the RDF/OWL design.
Pat Hayes
>
> Thanks for bring up the topic - I don't believe that this renaming contradicts your intentions and I think it is important to get these concept semantics nailed down early.
>
> Regards,
>
>
> Tony Mallia
> EDMOND SCIENTIFIC COMPANY (ESC)
>
>
>
> -----Original Message-----
> From: David Booth [mailto:david@xxxxxxxxxx]
> Sent: Saturday, March 07, 2015 8:29 PM
> To: public-semweb-lifesci@xxxxxx
> Cc: HL7 ITS; w3c semweb HCLS
> Subject: Re: Proposed RDF FHIR syntax feedback
>
> There are a few things going on here that I think are causing some confusion. One is discussion of RDF serializations (syntax). Another is discussion of ontologies (i.e., data models or TBox) versus instance data (i.e., ABox, or data that is expressed in
terms of those data
> models or ontologies). A third is discussion of dereferenceable FHIR
> URIs. I'll try to help untangle them, but first I'd like to suggest some simple terminology to help reduce confusion in these discussions.
>
> ONTOLOGY: I suggest we use the word "ontology" when we are talking about the definitions of classes and properties, relationships between them or restrictions on their use, such as cardinality.
>
> INSTANCE DATA: Similarly, I suggest we use the term "instance data" when we are talking about data that is represented *using* those classes and
> properties. An example would be specific patient data (such as an
> observation) that is transmitted in a FHIR payload.
>
> I think this "ontology" versus "instance data" dichotomy will help clarify our discussions. HOWEVER, there are several circumstances that cause this distinction to be blurred:
>
> - RDF itself makes no distinction between ontologies and instance data (TBox and ABox) -- it's all just sets of assertions to RDF. "Triples
> all the way down." :)
>
> - RDF file formats are *not* a reliable indicator of whether a file contains an ontology, instance data or a combination of both. A .rdf file (RDF/XML) can hold OWL ontology definitions, as can a .ttl (Turtle) file or any other standard RDF serialization.
To add even more confusion, if you're using a tool like Protege, the tool might store everything in .owl files, regardless of whether the data is acting as
> ontologies or as instance data. The .owl extension does *not*
> necessarily mean the file contains an ontology (as defined above).
>
> - Terms from OWL and RDFS vocabularies can be freely intermingled in an RDF document -- and they typically are, especially when that document acts as an ontology.
>
> - FHIR profile definitions can be transmitted in a FHIR payload just as patient data can be transmitted. In that sense a FHIR profile can act like instance data, but in its use -- defining extensions and constraining the content of other FHIR resources
-- it acts more like an ontology.
>
> For FHIR, we need to define both a FHIR *ontology* -- a set of classes and properties -- and bi-directional mappings that will convert FHIR
> *instance* *data* from FHIR XML or FHIR JSON to FHIR RDF and vice versa.
>
> Because RDF is independent of serialization, file formats and serializations are largely irrelevant to our FHIR RDF/ontology effort:
> we'll be producing a FHIR ontology, using standard RDF, RDFS and OWL vocabularies, and it can be serialized to any standard RDF format. For this reason, I don't think we should spend much time worrying about what RDF serialization to use for the FHIR ontology.
It's pretty much irrelevant.
>
> However, for FHIR RDF *mappings*, for convenience we may choose to define those mappings in terms of specific FHIR XML, FHIR JSON and/or FHIR RDF serializations. For example, the Shape Expressions (ShEx) approach that Eric Prud'hommeaux demonstrated transforms
FHIR *XML* to *Turtle*. And in the JSON-LD approach that I'm investigating, the mapping from JSON-LD to RDF will simply be the standard RDF interpretation of the JSON-LD: no additional mapping definition will be required.
>
> In summary: (a) RDF serializations can hold a mixture of RDF, RDFS and/or OWL -- and they often do; and (b) the serialization format is independent of whether the document contains an ontology or instance data or both.
>
> David Booth
>
------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile (preferred)
phayes@xxxxxxx http://www.ihmc.us/users/phayes
_________________________________________________________________
Msg Archives:
http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files:
http://ontolog.cim3.net/file/work/OntologySummit2015/
Community Wiki:
http://ontolog-02.cim3.net/wiki/OntologySummit2015
Community Portal: http://ontolog-02.cim3.net/wiki/
|
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2015/
Community Wiki: http://ontolog-02.cim3.net/wiki/OntologySummit2015
Community Portal: http://ontolog-02.cim3.net/wiki/ (01)
|