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