The Pragmatic Haskeller, Episode 4 – Recipe Puppy by Alfredo Di Napoli.
From the post:
Now we have our webapp that can read json from the outside world and store them inside MongoDB. But during my daily job what I usually need to do is to talk to some REST service and get, manipulate and store some arbitrary JSON. Fortunately for us, Haskell and its rich, high-quality libraries ecosystem makes the process a breeze.
Alfredo continues his series on building a basis web app in Haskell.
Promises a small DSL for describing recipes in the next espisode.
Which reminds me to ask, is anyone using a DSL to enable users to compose domain specific topic maps?
That is we say topic, scope, association, occurrence, etc. only because that is our vocabulary for topic maps.
No particular reason why everyone has to use those names in composing a topic map.
For a recipe topic map the user might see: recipe (topic), ingredient (topics), ordered instructions (occurrences), measurements, with associations being implied between the recipe and ingredients and between ingredients and measurements, along with role types, etc.
To a topic map processor, all of those terms are treated as topic map information items but renamed for presentation to end users.
If you select an ingredient, say fresh tomatoes in the salads category, it displays other recipes that also use fresh tomatoes.
How it does that need not trouble the author or the end user.
Yes?