Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: pat browne <Patrick.Browne <at> comp.dit.ie>
Subject: Re: Merging modules
Newsgroups: gmane.comp.lang.haskell.cafe
Date: Friday 16th October 2009 11:56:30 UTC (over 7 years ago)
> 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


[email protected] wrote:
> On Fri, Oct 16, 2009 at 11:42:22AM +0100, pat browne wrote:
>> To: [email protected]
>> 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
> [email protected]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
 
CD: 3ms