
This is all pretty basic stuff. Not sure any of it is very helpful. (Why do you want to spread an ontology over several Haskell modules?)
-matthias
Yes it is very helpful, I have limited time to study Haskell. The reason for spreading the information over modules is to simulate actual ontologies and the mappings to other ontologies. My next step is, as you suggested, to use type classes. My overall thesis is the study of current algebraic specification and programming techniques. Thanks, Pat mf-hcafe-15c311f0c@etc-network.de wrote:
On Fri, Oct 16, 2009 at 11:42:22AM +0100, pat browne wrote:
To: haskell-cafe@haskell.org From: pat browne
Date: Fri, 16 Oct 2009 11:42:22 +0100 Subject: [Haskell-cafe] Merging modules Hi, I want to establish the strengths and weakness of the Haskell module system for the ontology merging task (I know it was not designed for this!). I wish to make a new module (MERGEDONTOLOGY) from three input modules one of which is common to the other two. The desired merge should contain the following data types: Woman FinancialBank HumanBeing RiverBank Which are all identifiable without any qualifying module names.
Below is the detailed requirement and my first attempt at this task in Haskell. I would be grateful for any information on how to merge these modules giving a set of unique unqualified types (i.e. without reference to their originating modules).
Regards, Pat
======================== Informal Specification ========================
The diagram and text below explain the requirement
MERGEDONTOLOGY { Woman, RiverBank, FinancialBank, HumanBeing} /\ /\ / \ / \ / \ / \ / \ / \
ONTOLOGY1 ONTOLOGY2 {Woman, Bank, Person} {Woman, Bank, Human} /\ /\ \ / \ / \ / \ / \ / \ / \ / {Woman , Person} COMMMON
This example includes both synonyms and homonyms. 1)The Woman sort (or data type) should be the same in all modules, there is only one Woman sort and it is named as such in each module. Hence there should be only one MERGEDONTOLOGY.Woman.
2)There is only one sort MERGEDONTOLOGY.HumanBeing, but there are 3 synonyms for it called ONTOLOGY2.Human, ONTOLOGY1.Person, and COMMON.Person. The last sentence considers ONTOLOGY1.Person and COMMON.Person as synonyms; they have different qualifiers but the intention is that they represnt the same thing. Hence should be mapped to same MERGEDONTOLOGY.HumanBeing. To do this (in Maude) COMMON.Person was renamed to ONTOLOGY2.Human which in turn was renamed to MERGEDONTOLOGY.HumanBeing.
3)The homonyms are ONTOLOGY1.Bank and ONTOLOGY2.Bank should become distinct sorts MERGEDONTOLOGY.RiverBank and MERGEDONTOLOGY.FinancialBank in the final ontology at the top of the diagram.
================================================ My first attemt at merging using Haskell modules ================================================= module COMMON where data Woman = WomanC data Person = PersonC
module ONTOLOGY1 where import COMMON data Bank = BankC
module ONTOLOGY2 where import COMMON data Bank = BankC
module MERGEDONTOLOGY where import ONTOLOGY1 import ONTOLOGY2
If I use qualified names all the constructors are interpreted correctly MERGEDONTOLOGY> :t COMMON.WomanC COMMON.WomanC :: COMMON.Woman MERGEDONTOLOGY> :t COMMON.PersonC COMMON.PersonC :: COMMON.Person MERGEDONTOLOGY> :t ONTOLOGY2.BankC ONTOLOGY2.BankC :: ONTOLOGY2.Bank MERGEDONTOLOGY> :t ONTOLOGY1.BankC ONTOLOGY1.BankC :: ONTOLOGY1.Bank MERGEDONTOLOGY> :t COMMON.Woman
However, I wish that these types and constructors be fully defined in the context of the MERGEDONTOLOGY. I have tried type synonyms and newtypes. type RiverBank = ONTOLOGY1.Bank type FinancialBank = ONTOLOGY2.Bank newtype RiverBank = BankC Int I have not explored import modes or qualified imports.
The way you import ONTOLOGY* and COMMON without "qualified", you can use any name that you import without qualifier, as long as the name is unique over all imported modules.
Where names would conflict, you can list the names to be imported explicitly, and omit the names that cause conflicts:
import ONTOLOGY1 (Woman (..), Person (..))
or list the names to be omitted:
import ONTOLOGY1 hiding (Bank (..))
In your example, you want both banks (from both ontologies), and name them differently. If this is a common thing in your application, perhaps you want to use type classes instead of plain data types, or one of the other many extensions to Hindley-Milner. Or you stick with module qualifiers wherever ambiguity error messages require it. May be the safest and most convenient way.
This is all pretty basic stuff. Not sure any of it is very helpful. (Why do you want to spread an ontology over several Haskell modules?)
-matthias _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe