To: | "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx> |
---|---|
From: | Piotr Nowara <piotrnowara@xxxxxxxxx> |
Date: | Fri, 16 Nov 2012 10:57:45 +0100 |
Message-id: | <CAGWzwsb+zuDECL1saVmZS7CjNENZWQEr3NJHXzOij0oCWXPjKw@xxxxxxxxxxxxxx> |
Duane, as you have noticed the transformation is based on processing the strings with a set of regular expressions - in this case OWL axioms are being transformed into text form (Manchester Syntax) by OWL-API. I have decided to use text processing because I wanted my software to be also capable of processing definitions from sources other than OWL files.
The hard coded part you mentioned contains the base structure of a SQL query with placeholders for mappings provided by the user in a configuration file - for example {TABLE_NAME} is a placeholder for a name of a database table corresponding to a given type of fact defined in the ontology to be substituted during the transformation. The data can be spread across many tables, e.g. one can specify that "Medical procedure" should be mapped to TABLE_A and "Medical diagnosis" to TABLE_B.
It is also possible to configure mappings for different participants, e.g. relations ”occurs for the same patient between 3 and 5 days before” and “occurs for the same healthcare provider between 3 and 5 days before” can be configure to be produce additional relation-specific SQL conditions like “TABLE_A.PATIENT_ID = TABLE_B.PATIENT_ID”, “TABLE_A.PROVIDER_ID = TABLE_B.PROVIDER_ID”. An configuration file looks like this:
#DomainPropertyMapping-[OWL property name]=table name, column name,[optional parameter for using “LIKE” operator instead default “=”] DomainPropertyMapping-medical_procedure_ICD9_code=CODE,ICD9,H
DomainPropertyMapping-indicated_ICD10_code=CODE,ICD10 DomainPropertyMapping-issued_drug_ATC_code=ATCCODE,DRUGS DomainPropertyMapping-issued_drug_EAN_code=EANCODE,DRUGS #DomainPropertyMapping-[OWL class name]=table name
DomainClassMapping-Drug_issuance=DRUGS DomainClassMapping-Medical_procedure=ICD9 DomainClassMapping-Diagnosis_indication=ICD10 #Specifies the database column to use for date comparisons DateColumn=DATA
#AdditionalCondition-[OWL property name]=column name AdditionalCondition-healthcare_provider=PROVIDER_ID AdditionalCondition-patient=PATIENT_ID #Specifies SQL dialect
SQLType=DB2 In short a deployment scenario looks like this: 1. Creating or choosing a domain ontology 2. Configuring mappings and preparing configuration file.
3. Installing Protégé plugin. Best regards, Piotr Nowara 2012/11/16 Duane Nickull <duane@xxxxxxxxxxxxxxxxxxxxxxx> Peter: _________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx Shared Files: http://ontolog.cim3.net/file/ Community Wiki: http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01) |
Previous by Date: | [ontolog-forum] Free & Open Licenses discussion [was - Re: Ontology-driven software for querying facts in temporal context], Peter Yim |
---|---|
Next by Date: | Re: [ontolog-forum] Webby objects, doug foxvog |
Previous by Thread: | Re: [ontolog-forum] Ontology-driven software for querying facts in temporal context, Duane Nickull |
Next by Thread: | [ontolog-forum] what's appropriate [was - Re: Ontology-driven software for querying facts in temporal context], Peter Yim |
Indexes: | [Date] [Thread] [Top] [All Lists] |