View on GitHub

PennTURBO Documentation

The Github Pages site for PennTURBO

The TURBO Ontology

Audience and goals

It isn’t necessary to know every term in the TURBO ontology in order to execute the Drivetrain application as-is. A deep understanding of the RDF and OWL2 languages isn’t required in that specific use case, either. However, users who wish to make modifications to the TURBO ontology or to the Drivetrain code should at least familiarize themselves with the Class Relations Diagrams, along with the concepts behind them, specifically:

The TURBO ontology is still being refined. The TURBO team welcomes suggestions for term additions or modifications.


The TURBO ontology is an OWL2 ontology that describes the classes and properties that can be used by the Drivetrain application.

TURBO imports many of its classes from the Ontology for Biobanking, the Ontology for Biomedical Investigations and other OBO Foundry ontologies. TURBO’s native classes and properties are, to a great extent, used to describe the shortcut expansion, referent tracking and conclusionating processes carried out by the Drivetrain application.

Term IDs vs labels

As is the case for most OBO foundry ontologies, class and property terms are represented with URIs that are not necessarily intended to have any mnemonic value. In this document, the terms will be mentioned by way of their textual labels. For terms that have multiple labels, one has been chosen as the preferred term within the scope of this document.

A table of all TURBO terms appears at the end of this section, with the term URIs, the locally preferred labels, and all alternative labels. All labels have been normalized by lowercasing, replacing underscores with whitespace, and removing all unnecessary/redundant whitespace.

Permitted relations vs observed relations

The TURBO ontology describes all classes and properties that may be used in a TURBO repository. Building upon that, the Drivetrain application contains checker methods that ensure no other terms are used, and that property terms are only used to link instances of classes that fall within a property’s range and domain, or subclasses thereof. However, not all of the TURBO terms are currently instantiated by Drivetrain, and there are certainly aren’t s-p-o triples representing all of the permissible subject class-property-object class permutations.

Having said that, SPARQL queries ( can be written to transform all of the instance-to-instance triples that actually do appear in a TURBO repository into class-to-class prototypes, which can then be visualized with something like GraphDB’s built-in graph visualizer (see below), GraphViz ( or igraph ( The following examples are based on data about 5000 real PennBiobank patients and the encounters they participated in.

Triples, Classes and Instances

Fundamentally, RDF is used to make triples, or semantic statements with subjects, predicates and objects, each of which is considered a resource and is represented with a Universal Resource Identifier (URI.) For example, the TURBO ontology knows that adipose tissue is something that exists in reality. That term is imported from the Uber Anatomy Ontology, and goes by the URI

OWL2 ontologies can be serialized to text files in a number of formats, several of which also function as serializations of the RDF Resource Description Format. A representative RDF triple from the TURBO ontology could be written out in the “n-triples” style as follows:

<> <> "adipose tissue" .

Here, the triple’s subject is the URI, the predicate is, and the object is the literal value “adipose tissue”. (While literals are legal as subjects in RDF, they are generally not used that way in OWL2 ontologies. Literals can never be used as predicates.)

RDF triples can be used to communicate what classes and properties are modeled in an ontology like TURBO, and the ways in which instances of those classes can be related by the properties. That’s a matter of defining terminology. The bulk of the work specifically done by Drivetrain is not defining terminology, but rather making specific assertions about things in reality, each of which is an instance of some TURBO class.

The following TURBO instance-to-instance triples are written in RDF’s terser Turtle syntax. One characteristic of Turtle syntax is the use of a prefix notation for URIs, in which obo:UBERON_0001013 is identical with These instance-to-instance triples also follow Drivetrain’s practice of referring to individual things in reality with URLs that end in a Universally Unique Identifier, or UUID. Finally, this example introduces another class: Homo sapiens, or, and another property:, or is_part_of.

In conclusion, these triples say that some particular adipose tissue instance is part of some particular Homo sapiens instance.

prefix obo: <> .
prefix turbo: <> .

turbo:3aa16df5-d0a5-427c-af0d-c9e053b1e21d a obo:UBERON_0001013 .
turbo:68c2f7d9-a393-4022-af63-d5a3e94b902d a obo:NCBITaxon_9606 .
turbo:3aa16df5-d0a5-427c-af0d-c9e053b1e21d obo:BFO_0000050 turbo:68c2f7d9-a393-4022-af63-d5a3e94b902d .

Collections of RDF triples are stored in databases called RDF triplestores. Drivetrain uses the RDF4J library to communicate with a triplestore containing the TURBO triples. OntoText GraphDB satisfies the requirement of a RDF4J triplestore that supports OWL2 reasoning. It also provides several nice visualization tools and an IDE-like environment for composing SPARQL queries of the triples. Some other OWL2-reasoning RDF4J compliant triplestore could be theoretically be substituted.

Technically speaking, one GraphDB installation can contain multiple repositories that are for the most part segregated. The same is true for most other RDF4J triplestores. One collection of TURBO triple takes exactly one repository. Later in this document, the use of named graphs ( for the segregations of conclusions will be discussed. TURBO repositories contain multiple named graphs. SAPRQL queries can be scoped only one or more enumerated named graphs, but their default behavior is to consider all named graphs in a repository.

Class Relations Diagrams: The Concept

The key to understanding the upcoming Class Relations Diagrams is that they generalize instance to instance relations (like turbo:3aa16df5-d0a5-427c-af0d-c9e053b1e21d is a part of turbo:68c2f7d9-a393-4022-af63-d5a3e94b902d) into prototypes that say things like “there are some adipose tissue instances that are parts of some instances of Homo sapiens. The TURBO ontology may not specifically say that. In fact, the main points it currently makes about adipose tissue and Homo sapiens are

prefix obo: <> .

obo:UBERON_0001013 rdfs:subClassOf obo:UBERON_0000479
obo:NCBITaxon_9606 rdfs:subClassOf obo:NCBITaxon_9605

Which says that adipose tissue is a subclass of obo:UBERON_0000479 (“tissue”, in a general sense) and that the class Homo sapiens is a subclass of obo:UBERON_0000479 (the genus “Homo”).

Starting at this point in the documentation, Class Relation Diagrams will be interspersed with text, in order to further illustrate the terms used in the TURBO ontology, along with the supporting technologies.

class relations diagram legend

Example: All relations involving healthcare encounter

There are instances of class biobank consenter that participate in instances of class healthcare encounter ( from the Ontology for General Medical Science), which is in turn a subclass of process. The following illustration takes class health care encounter as its hub. Classes with at least one instance having a relationship with at least one instance of healthcare encounter (like biobank consenter) are considered satellites in this diagram. In summary, the diagram shows the hub, all of the observed relations between instances of the hub and instances of the satellites, and all relationships between instances of the various satellites.

healthcare encounter relations

These diagrams depict a cumulative generalization of what has been stated about instances of the hub class. The presence of the various satellite classes and properties in the diagram does not mean that every instance of healthcare encounter will have all of the depicted relations with instances of all of the depicted satellite classes. For example, there could be some healthcare encounter with no length measurement assay or mass measurement assay as its parts. Conversely, this diagram doesn’t mean that a healthcare encounter instance can’t have two or more mass measurement assays as its parts Finally, it should be noted that the relations that a satellite can participate in are not shown exhaustively. If satellite X has a relationship with an instance of class Y, but no instances of the hub has an y relation with any instances of class Y, class Y will not appear in the diagram. In order to see this relationship between satellite class X and the class Y, find the diagram in which class X appears as the hub. Likewise, the relationships between satellites may not actually contribute to the understanding of the hub. This is especially true when rdf:Statements appear as satellites.

TURBO’s use of rdf:Statements for making triples about triples

TURBO uses instances of class rdf:Statement for reification of triples about triples, for example when provenance or supporting data is required. (See This is a possible source of confusion, as it is not unusual to see RDF triples themselves referred to as “statements”. The complete usage of a rdf:Statement instance would include at least three triples in which it would appear in the 1st (subject)position, in addition to a triple in which it was asserted that the instance was, in fact, of class rdf:Statement. The predicates for these triples would be

For example, Drivetrain makes conclusions about the qualities and values of things, based on rules and available data. It might be necessary to say, in a qualified way, that some person’s biological sex is male. Drivetrain will not put a direct triple to that effect in the repository’s default graph, because the conclusion could change if new data became available in the future or if a user of the TURBO system wished to re-run Drivetrain with custom rules for their own particular needs.

The diagram below shows that there are rdf:Statements that take an instance of class biological sex as their subject and the class male as their object. The automated diagram generator doesn’t yet clarify that biological sex is really being invoked as a class, which is different from the way the Class Relation Diagrams represent instance to instance relations as generalizations about classes. Additionally, the diagram generator doesn’t yet show the predicate in this statements, which happens to be rdf:type


The diagram in which statement appears as the hub does show all of the instantiated statement predicates, although which statements, predicated and objects go together is not formally shown. A forced manual layout of the diagram has been used to hint that statements taking a class as their object are likely to use rdf:type as their predicate.


As mentioned above, when a rdf:Statement is a satellite, its relations with other satellites may or may not be illustrative with respect to the hub. The next diagram shows that a statement can take female gender identity datum (the hub in this case) as the supporting data. Statements of this type are the same as those in the biological sex diagram above: statements that assert the type of some biological sex, which is the quality of some person known to the Biobank, can take a subclass of gender identity datum, possibly self-reported by that person, as supporting evidence.


string appears as a satellite in this diagram because instances of gender identity datum, or any of its subclasses, take a string (like “M” or “F” or even “0” or “1”, etc.) as their literal value.

Since string and statement both appear as satellites of female gender identity datum, any relationship between any instance of either is depicted in the diagram. The fact that there are statement s with strings as their comments or objects probably doesn’t’ provide any further understanding of class female gender identity datum. Those relations are included out of consistency and as a consequence of a high-throughput automated diagram generator.

Relationships with literal values

As mentioned above, RDF allows relationships between instances and data literals (in addition to instance-to-instance relations). In some of the Class Relations Diagrams, there are circles that represent particular types of literals that are allowed as the object of particular properties, such as string or boolean.

For example, there are health care encounter instances that have mass measurement assays as parts. A mass measurement assays can have a mass measurement datum as output, which can in turn be linked to scalar value specification, which have a specified value. The scalar value specification is a thing with a URI, while the actual value is a literal. The scalar value specification can also have a relationship with a unit.




When exploring a TURBO repository with GraphDB’s graph visualizer, note that literal values are not represented as circular nodes in the visualization. Rather, one must click on an instance’s circle and then click on the *i* in the upper right for information about literal values. Here we see that class Acetaminophen 500 MG Oral Tablet [Tylenol] ( has a RXNORM value ( of “209459”

view literal values in GraphDB

Shortcut Relations

Shortcut relations are an important part of the overall TURBO workflow. They are defined as Datatype properties in the TURBO ontology, specifically subProperties of instantiationHybridShortcut. Structurally, they link an instance of some class to a literal value (as was seen in the previous section). However, they are not shown in any of the Relations Diagrams, as they are replaced with other properties and instances of implicit classes during Drivetrain’s expansion phase.

The TURBO ontology contains brief rdf:comments about the shortcut properties, but all of the logic for expanding them is implemented within the Drivetrain application code. The TURBO ontology also contains a small number of chained object properties like has birth, which are fully defined within the ontology itself and should not be confused with TURBO Shortcut Properties. For example, has birth is defined in the OWL2 language as 'participates in' o inverse (starts). Taking into consideration this property’s domain and range, it says that some Homo sapiens participates in some process that is started by some temporal boundary.

Prototypical Referent Tracking Relations

The replaced with IUI relationship from retired placeholder for health care encounter to health care encounter indicates that health care encounter instances are subject to referent tracking. The larger size of the retired placeholder for health care encounter node, relative to the size of the referent tracked health care encounter node, illustrates the typical referent tracking outcome: many references that are naively asserted to point to unique instances are in reality unique but not singular. In other words, a referent tracked health care encounter instance will frequently be the object of replaced with IUI relationships from multiple retired placeholder for health care encounter instances.

Referent tracked instances also have a referent tracked? relationship with a boolean value, which is always true. At the end of the referent tracking process, the presence of any health care encounter instances (or any other referent-trackable instances) lacking a referent tracked? true relation is considered an error state. The referent tracked? relationship, along with a few related relationships, is omitted from the Class Relations diagrams due to visual clutter. Another example of a hidden relationship is that all referent tracked instances have an obsolescence reason specification, which always takes an instance of class placeholder removed as its object (at least at this point in time.) Note that all of these relations are of the owl:AnnotationProperty type, not the previously discussed object properties between instances or the datatype properties between and instance and a data literal. TURBO implements referent tracking with owl:AnnotationProperties as they make statements about terms, not about the portions of reality that those terms point to. These referent tracking relations, including those that are hidden in the Class Relations Diagrams, apply to several other trackable classes and are shown in the diagram below.

Also note that the “Trackable entity” in the diagram below is not an individual class. It refers to any of the classes that are subject to referent tracking.

[referent tracking prototype](/Turbo-Documentation/images/prototypical_referent_tracking_diagram.png)

pre-reftracking uri text: a hook into provenance diagnostics

Anyone running the Drivetrain application on their own will notice that, upon completion, there won’t be any instances with URIs whose string values are equivalent to the pre-reftracking uri text values. These values are of diagnostic use to the TURBO development team, as the repository can be explored or dumped in intermediate states over the course of running the application (specifically when running in Presentation Driver mode). They also serve to illustrate the combined effects of shortcut expansion and referent tracking. The shortcut triples instantiated from a tabular datasource can contain repetitive and contradictory information, and could say something like this (informally)

"study participant 1" "has birth date" "2010-11-22"
"study participant 1" "has birth date" "2011-10-22"
"study participant 1" "has birth date" "2010-11-22"

During expansion, a distinct instance of class study participant with biobank donation will be created for each row in that set of triples, each with its own URI. If, during referent tracking, it is found that the three instances share a common signature of data items (like patient identifiers), they will be remodeled as three instances of retired placeholder for 'biobank study participant' and one single referent tracked instance of study participant with biobank donation, all of which will be assigned new URIs.

In addition to this, three instances each of the classes date of birth and temporal boundary will also be created during shortcut expansion, again with new URIs, as the whole point of the shortcuts is to spare clinical informaticians from having to create models that say (informally)

Human beings have births.  
The births are temporal boundaries.  
Dates of birth have date values 
    and are about the temporal boundaries that mark the start of people's lives.

If what initially appeared to be three different study participants is re-modeled as a single study participant during referent tracking, then the date of birth and ‘temporal boundary` instances will each be remodeled into one instance of each class, with still more new URIs.

All of these various URIs are accounted for with pre-reftracking uri text, among other properties. Without them, it would be difficult or impossible to reconstruct provenance.

Additional prototypes: Shortcut Expansion and Conclusionation

Like the pre-reftracking uri text property on referent tracked entities, a pre-expansion uri text property will be present on the entities that are instantiated by Karma and therefore appear as the subjects of shortcut relations. There is, however, no corresponding “expanded?” Boolean property. Conversely, any entity that has been conclusionated will have a conclusionated property, with a value of true, but will not have anything like a “pre-conclusionation uri text” value. Conclusionated instances may have other literal properties to capture the most frequently observed value, a mean value, or so on.

class conclusionated? referent tracked?
adipose tissue   TRUE
biobank consenter   TRUE
biobank consenter CRID   TRUE
biobank consenter registry denoter   TRUE
biobank consenter symbol   TRUE
biobank encounter   TRUE
biobank encounter CRID   TRUE
biobank encounter registry denoter   TRUE
biobank encounter start   TRUE
biobank encounter start date   TRUE
biobank encounter symbol   TRUE
biological sex   TRUE
body mass index TRUE  
date of birth TRUE  
female TRUE  
health care encounter   TRUE
health care encounter CRID   TRUE
health care encounter registry denoter   TRUE
health care encounter start   TRUE
health care encounter start date   TRUE
health care encounter symbol   TRUE
height   TRUE
male TRUE  
start of neonate stage   TRUE
weight   TRUE

TURBO Class Relations Diagrams, in alphabetical order

//: # (right now, clicking redirects to the image alone, but it may not look zoomed in. Therefore removed “Click to expand.”)

There are a few classes that don’t have their own diagram, as it would only show one other class and a subClassOf relationship. Every instantiated class does appear in at least one other diagram, as well as the listing at the end of this document.

action specification aka

adipose tissue aka

biobank consenter aka

biobank consenter CRID aka

The linked in data set with property can be used to describe any structural relationship between two data values found in any type of input data (CSV, XML, JSON, etc.). Following that, the intention is that some method in Drivetrain would deduce some portion of reality based on this structural relationship. For example, when a study participant identifier value and an encounter identifier value appear in the same row of a join table, it could be deduced that the denoted participant participated in the denoted encounter.

Deductions like that could theoretically be implemented as OWL axioms, but in practice they are currently hard-coded into the Drivetrain application logic.

biobank consenter identifier registry aka

biobank consenter registry denoter aka

biobank consenter symbol aka

biobank encounter aka

biobank encounter CRID aka

biobank encounter identifier registry aka

biobank encounter registry denoter aka

biobank encounter start aka

biobank encounter start date aka

biobank encounter symbol aka

biological sex aka

body mass index aka

This diagram should not be misinterpreted to mean that the supporting data for a rdf:Statement about body mass index instance BMI1 is necessarily itself. Rather, there are rdf:Statements about body mass index instances which take, as their supporting data, some body mass index instance. In the current implementation, a body mass index which is the output of a healthcare encounter is frequently the supporting data for a statement about a body mass index that is associated with a biobank encounter

Furthermore, when a conclusionation process generates rdf:Statements, direct triples with the same semantics are also generated. The direct triples, as well as the rdf:Statement instances, are generated in a named graph to isolate them from ground truths and data instantiated out of tabular inputs.

A health care encounter start can serve as the time stamp for a BMI that is conclusionated to be related to a biobank encounter. This relationship documents the time at which a measured (on conclusionated) BMI measurement holds true. One could argue that this is a slight departure from OBI usage, in which has time stamp typically describes the time at which a measurement was recorded, like the height of a plant is serially recorded at multiple times.

boolean aka

centimeter aka

centrally registered identifier aka

centrally registered identifier symbol aka

Class aka

conclusionating aka

Conclusionation processes can have multiple nested sub-parts. This is represented in the Class Relations Diagram with has_part/part_of loops.

Instances of record of missing knowledge are used to communicate one possible outcome of conclusionating, for example, a study participant’s BMI at the time of a biobank encounter. If the conclusionator was unable to identify a trustworthy BMI numerical value at the date of the biobank encounter, a record of missing knowledge is generated. Otherwise, an instance of rdf:Statement is generated

The illustrated conclusionating 'has specified output' 'record of missing knowledge' and any potential 'record of missing knowledge' about 'biobank encounter' relationships are among a handful of non-canonical relationships illustrated in this document. They are not meant to say that every conclusionating process has a record of missing knowledge as output, or that a TURBO repository is wrong or incomplete if the 'record of missing knowledge' about 'biobank encounter' relationship doesn’t appear.

data set aka

The 'data set' subClassOf 'data item' relationship is asserted in The Information Artifact Ontology, the ontology in which those two terms are originally defined within the OBO foundry.

Data sets have strings as their titles. This relationship has been omitted for the sake of the visual layout.

date aka

date of birth aka

diagnosis aka

Actually, diagnosis instances don’t mention instances of class disease. That relationship is manually added to the class-to-class transformation of the instance-to-instance data in the TURBO ontology.

This is motivated by the ontology and RDF data sets that TURBO has chosen for modeling diagnosis codes and diseases:

Those datasets represent each disease or diagnosis as a subclass of a more general disease or diagnosis class, up to very general statements like neoplastic disease ( is a subclass of disease (

The data that TURBO uses as input has not, as of this point, actually mentioned the URIs of diseases or diagnoses. Rather, they include textual values like ICD-10:I21.02, which is a cross reference to class ST elevation (STEMI) myocardial infarction involving left anterior descending coronary artery in MONDO. In other words, liking form these diagnosis code strings to the URI for a disease requires adding a source of knowledge about disease classes, such as the above mentioned Monarch Disease Ontology (MONDO), to the TURBO repository, followed by running conditional SPARQL insert triples to build the links.

The TURBO team takes a conservative approach to modelling the ICD codes that can appear as the output of a healthcare encounter. Specifically, the intention is to avoid asserting that a study participant suffered from any particular disease solely because a particular code was recorded. Updates to the ontology may use language like “icd code assignment” and/or “billing/diagnosis code”.

The benefit of linking diagnosis code data to a hierarchy of diseases is the ability to make broad queries, enabled by OWL2 reasoning. Some study participant may have participated in a healthcare encounter in which the code ICD-10:I21.02 (“ST elevation (STEMI) myocardial infarction involving left anterior descending coronary artery”) was recorded. Given the appropriate triple patterns, this study participant could be discovered with a query that mentions, “myocardial infarction” in general.

diagnosis code registry denoter aka

international classification of diseases, ninth revision ( and international classification of diseases, tenth revision ( are defined by the TURBO ontology as individuals from class international classification of diseases (, not classes themselves. That should be distinguished from individuals who are instantiated, based on input data, within the TURBO repository.

Those are currently the only individual of that class in the TURBO ontology There is no reason that other registries of diagnosis and/or billing codes couldn’t be added to the TURBO ontology.

diagnosis code symbol aka

diagnosis CRID aka

disease aka

drug prescription aka

drug product aka

female gender identity datum aka

float aka

has date value aka

has specified value aka

has time stamp aka

has type aka

health care encounter aka

health care encounter CRID aka

health care encounter identifier registry aka

health care encounter registry denoter aka

health care encounter start aka

health care encounter start date aka

health care encounter symbol aka

height aka

International Classification of Diseases, Ninth Revision aka

International Classification of Diseases, Tenth Revision aka

kilogram aka

length measurement assay aka

length measurement datum aka

male gender identity datum aka

mass measurement assay aka

mass measurement datum aka

participant under investigation role aka

PDS EMPI biobank consenter identifier registry aka

PDS PK_Encounter_ID health care encounter identifier registry aka

plan aka

plan specification aka

PMBB ENCOUNTER_PACK_ID biobank encounter identifier registry aka

prescription CRID aka

prescription CRID symbol aka

R2R instantiation aka

real aka

retired placeholder for adipose tissue aka

retired placeholder for biobank consenter aka

retired placeholder for biobank consenter CRID aka

retired placeholder for biobank consenter registry denoter aka

retired placeholder for biobank consenter symbol aka

retired placeholder for biobank encounter aka

retired placeholder for biobank encounter CRID aka

retired placeholder for biobank encounter registry denoter aka

retired placeholder for biobank encounter start aka

retired placeholder for biobank encounter start date aka

retired placeholder for biobank encounter symbol aka

retired placeholder for biological sex aka

retired placeholder for health care encounter aka

retired placeholder for health care encounter CRID aka

retired placeholder for health care encounter registry denoter aka

retired placeholder for health care encounter start aka

retired placeholder for health care encounter start date aka

retired placeholder for health care encounter symbol aka

retired placeholder for height quality aka

retired placeholder for process boundary aka

retired placeholder for weight quality aka

scalar value specification aka

start of neonate stage aka

Statement aka

This diagram is non-canonical in that it aggregates all of the classes that serve as the subject or object of all rdf:Statement instances in the TURBO repository, along with all utilized predicate properties. Information about which subjects, predicates and objects go together can be found in other diagrams in this section.

string aka

Data sets have strings as their titles. This relationship has been omitted for the sake of the visual layout.

URI aka

weight aka

URIs and all labels of terms instantiated in the current TURBO semantic repository

Clicking terms from ontologies from OBO and the EBI will navigate to a page with their definitions. No web-based term-resolver has been configured for the TURBO native terms yet, so clicking them will lead to an error page.

term labels type action specification class adipose tissue class assay class biobank consenter class biobank consenter CRID class biobank consenter identifier registry class biobank consenter registry denoter class biobank consenter symbol class biobank encounter class biobank encounter CRID class biobank encounter identifier registry class biobank encounter registry denoter class biobank encounter start class biobank encounter start date class biobank encounter symbol class biological sex class body mass index class centimeter class centrally registered identifier class centrally registered identifier registry class centrally registered identifier symbol class conclusionating class data item class data set class data transformation class date of birth class diagnosis class diagnosis code registry denoter class diagnosis code symbol class diagnosis CRID class directive information content entity; directive information entity class disease class drug prescription; prescription de médicaments class drug product class female class female gender identity datum class gender identity datum class has date value class has specified value class has time stamp class health care encounter class health care encounter CRID class health care encounter identifier registry class health care encounter registry denoter class health care encounter start class health care encounter start date class health care encounter symbol class health care prescription; prescription de santé class height class Homo sapiens class information content entity class International Classification of Diseases, Ninth Revision class International Classification of Diseases, Tenth Revision class kilogram class length measurement assay class length measurement datum class life cycle temporal boundary class male class male gender identity datum class mass measurement assay class mass measurement datum class mass unit class measurement datum class measurement unit label class organismal quality class participant under investigation role class PDS EMPI biobank consenter identifier registry class PDS PK_Encounter_ID health care encounter identifier registry class physical quality class placeholder removed class plan class plan specification class planned process class PMBB ENCOUNTER_PACK_ID biobank encounter identifier registry class prescription CRID class prescription CRID symbol class process class process boundary class process start time measurement class quality class R2R instantiation class realizable entity class record of missing knowledge class retired placeholder class retired placeholder for adipose tissue class retired placeholder for biobank consenter class retired placeholder for biobank consenter CRID class retired placeholder for biobank consenter registry denoter class retired placeholder for biobank consenter symbol class retired placeholder for biobank encounter class retired placeholder for biobank encounter CRID class retired placeholder for biobank encounter registry denoter class retired placeholder for biobank encounter start class retired placeholder for biobank encounter start date class retired placeholder for biobank encounter symbol class retired placeholder for biological sex class retired placeholder for health care encounter class retired placeholder for health care encounter CRID class retired placeholder for health care encounter registry denoter class retired placeholder for health care encounter start class retired placeholder for health care encounter start date class retired placeholder for health care encounter symbol class retired placeholder for height quality class retired placeholder for process boundary class retired placeholder for weight quality class role class scalar measurement datum class scalar value specification class size class start of neonate stage class time measurement datum class tissue class value specification class weight class conclusionated? property concretizes property denotes property has birth property has date value property has literal value property has measurement unit label property has output property has part property has quality property has role property has specified numeric value property has specified value property has textual value property has time stamp property has value specification property has_specified_input property has_specified_output property is about; is_about property is part of; part of property is quality measurement of property is_specified_output_of property is_supported_by_data property linked in dataset with property mentions property obsolescence reason specification property output of property participates in property pre-expansion URI text property pre-reftracking URI text property realized in property realizes property referent tracked? property replaced with IUI property starts property Title property