Has provider leaf node

@prefix omop: <https://w3id.org/omop/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix owlready: <http://www.lesfleursdunormal.fr/static/_downloads/owlready_ontology.owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

omop:has_provider a owl:FunctionalProperty,
        owl:ObjectProperty ;
    rdfs:label "Has provider"^^xsd:string ;
    owlready:python_name "provider"^^xsd:string ;
    rdfs:comment """For Condition Occurrence: The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.
The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record."""@en,
        """For Device Exposure: The Provider associated with device record, e.g. the provider who wrote the prescription or the provider who implanted the device.
The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record."""@en,
        """For Drug Exposure: The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug.
The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the ordering vs administering physician on an EHR record."""@en,
        """For Measurement: The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result.
The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record."""@en,
        """For Note: The Provider who wrote the note.
The ETL may need to make a determination on which provider to put here."""@en,
        """For Observation: The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result.
The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record."""@en,
        """For Person: The Provider refers to the last known primary care provider (General Practitioner).
Put the provider_id from the PROVIDER table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here."""@en,
        """For Procedure Occurrence: The provider associated with the procedure record, e.g. the provider who performed the Procedure.
The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record."""@en,
        """For Survey Conduct: This is the Provider associated with the survey completion.
The ETL may need to make a choice as to which Provider to put here. This could either be the provider that ordered the survey or the provider who observed the completion of the survey."""@en,
        """For Visit Detail: There will only be one provider per  **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.
The additional providers associated to a Visit can be stored in this table where each VISIT_DETAIL record represents a different provider."""@en,
        """For Visit Occurrence: There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the visit_detail table."""@en ;
    rdfs:domain [ a owl:Class ;
            owl:unionOf ( omop:ProcedureOccurrence omop:BaseVisit omop:Person omop:ConditionOccurrence omop:Exposure omop:Measurement omop:Note omop:Observation omop:SurveyConduct ) ] ;
    rdfs:range omop:Provider ;
    omop:omop_cdm_name "condition_occurrence.provider_id#71 AS Provider"^^xsd:string,
        "device_exposure.provider_id#124 AS Provider"^^xsd:string,
        "drug_exposure.provider_id#93 AS Provider"^^xsd:string,
        "measurement.provider_id#142 AS Provider"^^xsd:string,
        "note.provider_id#189 AS Provider"^^xsd:string,
        "observation.provider_id#160 AS Provider"^^xsd:string,
        "person.provider_id#11 AS Provider"^^xsd:string,
        "procedure_occurrence.provider_id#108 AS Provider"^^xsd:string,
        "survey_conduct.provider_id#234 AS Provider"^^xsd:string,
        "visit_detail.provider_id#50 AS Provider"^^xsd:string,
        "visit_occurrence.provider_id#33 AS Provider"^^xsd:string .