[Haskell-cafe] A Query Language for Haskell Terms

[Pasqualino 'Titto' Assini]

On Wednesday 27 June 2007 09:32:16 Alex Jacobson wrote:
> Titto,
>
> Have you looked at HAppS.DBMS.IxSet?  Right now it provides a generic
> way to query indexed sets.
>
> If you want to take a shot at making the queries serializable, I don't
> think it would be that difficult (but I have not tried so YMMV).

Hi Alex, thanks for remininding me about that. It is a very nice back-end and 
as you say, it should not be too hard to design a SQL-like query language  on 
top of it. 


I am still wondering, however, what meta-model is more appropriate to 
represent the info hold in a Web app.

Unfortunately there seem to be at least 3 different ones (without considering 
mixed approaches like F-Logic):
 

1) Graph

This is really the native Haskell way of representing information: the model 
is defined using classes or data types and types are connected by direct 
uni-directional links.

So for example the Sale/Item model (from the HAppS DBMS Examples) might be 
written like:

data Item = Item {stock::Int,description::String,price::Cents}  
            deriving (Ord,Eq,Read,Show)

data Sale = Sale {date::CalendarTime
			     ,soldItem::Item                 -- NOTE: uni-directional link to Item
                             ,qty::Int
                             ,salePrice::Cents} 
            deriving (Ord,Eq,Read,Show)

or in more abstract form using classes:

class Item i where
         description :: i -> String
         price :: i -> Cents

class Sale s where
         soldItem :: Item i => s -> i

This is also very much the Web-way: information is a graph of resource linked 
via uni-directional links.

Information is queried by path traversal (REST-style):

Assuming that the root "/" represents the collection of all sales then:

HTTP GET /elemAt[2345]/soldItem/description.json 

might return the JSON representation of the description of the item sold as 
part of sale 2345.


2) Relational

Information is represented as tables, that can be joined up via keys, as 
implemented  in HAppS DBMS or in any relational database.

The model becomes:

data Item = Item {itemId::Id  -- NOTE: primary key 
                             ,stock::Int,description::String,price::Cents} 
            deriving (Ord,Eq,Read,Show)

data Sale = Sale {date::CalendarTime,
                              soldItemId::Id     -- NOTE: foreign key 
                              ,qty::Int,salePrice::Cents} 
            deriving (Ord,Eq,Read,Show)

Plus the appropriate indexes definitions.

Information can be queried via a SQL-like language.


3) Logic

This is the "Semantic Web" way: information is broken down into assertions, 
that in their simplest form are just triples: subject predicate object, the 
model then becomes something like:

Item hasDescription String
Item hasPrice Cents
Sale hasItem Item

It can be populated piecemeal with assertions like:

item0 hasDescription "indesit cooker 34BA"
item0 hasPrice 3.5
Sale0 hasSoldItem item0

It can be queried using a logic-oriented query language (e.g SPARQL):
sale2345 hasItem ?item
?item hasDescription ?description



Moving from Graph to Relational to Logic the meta-model becomes simpler and 
more flexible. The flip-side is that the model (and the queries) become more 
verbose.  It is not clear where is the sweet spot.
 

What people think?  


Best,

    titto