search

Anniepoo / weblog

Web Framework for SWI-Prolog
GNU Lesser General Public License v3.0
41 stars 7 forks source link

Wouter's Generics #6

Closed Anniepoo closed 11 years ago

Anniepoo commented 11 years ago

Can we pick these up? https://github.com/wouterbeek/PrologGenericsCollection/tree/master/DCG

(ps, you can indeed include a subproject - wouter does it to include above in several of his other projects, I assume I can do so as well)

wouterbeek commented 11 years ago

Hi Anne,

I started using DCGs 1 or 2 weeks ago after I read your DCG tutortial :-) The folder that you point to is still a very rudimentary version of what I hope will at some point in the future be a generic DCG library for use in real-world applications at some point.

I am currently converting several legacy datasets (relational databases, excel sheets, plain text files) from the humanities domain to a Semantic Web format. An important part of this process is to convert the literal "198X" to the interval 1980^^gYear --- 1989^^gYear and the literal "vol.2, no. 3" to :pushishedIn :bnode1, :bnode1: :issueOf :bnode2, :bnode2 :volumeOf :'JournalOfLiteraryStudies'. This is where DCGs come in! It is impractical to parse these literals with REs, since the structure can be quite complex and DCGs allow you to build the grammar in a more modular way.

My plan is to update the DCG modules over the next couple of weeks while I work on these multiple conversion. The idea is that the DCG rules that are shared by all the conversions that I performed are 'generic' in some sense of the word. This means that the modules should become more generic over time. My primary purpose is to reduce the amount of code I have to write for each future dataset conversion.

Btw, module dcg_generic is intended to be truly generic (independent of the dataset conversions I may or may not perform). It contains some rules for peeking (I derived the idea for this from your tutorial), RE-like extensions (plus, star), and generalizations of stuff that is also in swipl's library dcg/basics.

On the inclusion/submodule topic: it is indeed very easy to add the PrologGenericsCollection as a submodule. I learned how to use it from Lars Vogel's tutorial over at http://www.vogella.com/articles/Git/article.html#submodules. I must warn though that the PGC contains code that I use across my projects, so many of the stuff that is in there will not be considered a 'generic' module by anyone that is not me :-P (e.g., there is an ILP algorithm in there, the original TMS as defined by Doyle, etc. There is even a Prolog version of cowsay! :-D)

This summer I want to segment my PGC repository into multiple smaller ones. DCG will probably be a single repo at that point. The problem is that currently it takes a little bit of overhead to maintain a submodule in a project. The overhead increases for each submodule that you include. I want to have a look at http://www.swi-prolog.org/pldoc/doc/home/vnc/prolog/lib/swipl/library/git.pl in order to automate this process. I know that Jan uses some of this stuff for the Prolog Packs (http://www.swi-prolog.org/pack/list) but this is (1) a high entry level for me to be in the same list as Jan and Michael, and (2) Prolog Packs seem to form a flat hierarchy whereas I would have to use submodules in submodules if I want my codebase to be split into smaller repositories.

PS: I've been looking at the progress you're making with weblog and it looks like a very interesting project! I'm especially interested in using open Web standards to create a full-fledged GUI for a visual modeling environment I'm currently running from the command line (models displayed in SVG, interactions with the module components using JavaScript, HTML5 for the menu's and stuff). Also my PGC repo contains some stuff that's in weblog (and this is much more versatile and better implemented in weblog!), e.g. Standards/HTML/html.pl contains a simple Prolog-list-to-HTML-table predicate. At some point I want to thoroughly look at the weblog code in order to use it for the GUI purpose, hopefully making some code contributions as I go along :-)

Cheers!, Wouter.

Anniepoo commented 11 years ago

Wow, I'm tickled pink at your great note. It's so full of interesting bits that I'm goign to have to leave this short note now and answer in the morning, as it's late here.

Anniepoo commented 11 years ago

Hey Wouter - if you're around, pop up on ##prolog on freenode.

Anniepoo commented 11 years ago

I wasn't sure where your stuff was going. Weblog's (deliberately) kind of a fibber mcgee's closet of useful web bits. But it sounds like you're making more than a 'bit'. Still, we should definitely be in each other's closely watched trains.

I've been working and reworking a few forms - tables, accordion, and the maps - trying to find some architectural direction I like. Here's design rules I've come up with:

1) It's forbidden for the entire system to become a monolithic 'take it or leave it' lib. If you want the maps, currently you only need the info/maps subtree, the static files from statics, resources, and keys. After a bit I'm hoping a core of infrastructure settles down so to use a piece you just take the tiny infrastructure and the piece.

2) I'm liking the interface to the maps. User supplies a closure that we call with a partially instantiated structure. They fill it in to supply us info. This works well for systems that have to ask lots of questions about different dribs and drabs of data - like a map with various icons and points and popups and views and.... So I'm thinking of moving towards that pattern for most things, so there's not a learning curve with each new widget.

3) javascript, and to a lesser extent HTML, are assembler languages. They should be swept under the rug by higher level abstractions.

4) widgets are of minimal use by themselves without good low friction ways to glue them to backend data. Ideally, putting a signin box on your web page is all you have to do to have registration and signin.

I've been trying recently to figure out a good architecture for sweeping the fact that something's ajax under the rug. Ideally you'd just do \ajax([inner html]) and it'd automagically figure out when it needed the innerds and go get them from an autogenerated handler.

Anniepoo commented 11 years ago

I'd more than welcome contributions. The flat nature of weblog means it's particularly a project many people could contribute to. It's actually only a small part my work now - many pieces were just plucked out of other projects.

I imagine eventually weblog will end up rolled into somethign else. For now it's an exercise in sorting and cleaning bits of random code.

wouterbeek commented 11 years ago

Hi Anne,

Thanks for your positive reactions! And sorry for me writing back with a slight delay. I have a hate/love relationship with my mailbox :-)

##prolog On the ##prolog thing: I have no idea how Freenode works. I'll look into it sometime. It would be great to chat to other Prolog-minded people!

PGC As I already expressed in my previous email, I am not too happy with the architectural underpinnings of PGC currently. It's development is primarily driven by research purposes (produce results for the next conference), and these often conflict with software design principles (modularity, reusability, documentation, etc.). I do think that some parts of PGC could be spun off in the future as Prolog packages. I'm thinking primarily of the TMS and ILP modules (but there may be other candidates, a future version of DCG maybe).

weblog: non-monolithic architecture I like your approach in building weblog! I would like to elaborate a bit on your first point, involving the non-monolithic architecture of weblog:

"It's forbidden for the entire system to become a monolithic 'take it or leave it' lib. If you want the maps, currently you only need the info/maps subtree, the static files from statics, resources, and keys. After a bit I'm hoping a core of infrastructure settles down so to use a piece you just take the tiny infrastructure and the piece." I strongly agree that this is the ideal way to present libraries/packages to others! I am very much interested in that 'strategies' that one could use to make this work in Prolog technically. Some projects try to import as few modules as possible, which results in a set of modules with scarce preconditions that can consequently be transported relatively easily. But in such approaches you miss the advantage of using as many existing predicates as is possible. I am thinking of an approach in which the use_module/[1,2]-like directives are used to include namespace prefixes in module specifications. Such a prefixe would point to a Git repository. For example:

:- git_register_namespace(anne_pgc, https://github.com/Anniepoo/PrologGenericsCollection.git').

This would Git pull the anne_pgc repository locally as a submodule. This would allow local changes to 'DCG/emoticons.pl' to be pushed back to the original Git repository.

:- use_git_module(anne_pgc, 'DCG/emoticons.pl').

The file 'DCG/emoticons.pl' would be consulted from the previously registered submodule.

These 'remote module imports' could of could be processed recursively. This may include import-loops, but for a first version it may be reasonable to assume that people don't do weird stuff :-). I'm not sure whether this can be easily done using =|library(git)|=.

_Emoticons Another DCG module has landed! I often don't know the exact semantics of an emoticon (I only know :-), :-(, and :-P), so this will help me a great deal. Would it be possible to parse emoticon-art with this module? E.g. http://skypefun.net/Skype_fun_art.html And then, do you know whether it is possible to produce narrative structures with emoticons in an automated fashion? E.g. [":-(",":-)"] is the simple comedy, while [":-)",":-("] is the simplest tragedy. The following quote is from a discussion of Aristotle's Poetics_:

The plot may be either simple or complex, although complex is better. Simple plots have only a “change of fortune” (catastrophe). Complex plots have both “reversal of intention” (peripeteia) and “recognition” (anagnorisis) connected with the catastrophe. Both peripeteia and anagnorisis turn upon surprise. Aristotle explains that a peripeteia occurs when a character produces an effect opposite to that which he intended to produce, while an anagnorisis “is a change from ignorance to knowledge, producing love or hate between the persons destined for good or bad fortune.” He argues that the best plots combine these two as part of their cause-and-effect chain (i.e., the peripeteia leads directly to the anagnorisis); this in turns creates the catastrophe, leading to the final “scene of suffering”.

Notions like 'fortune', 'love', 'hate', 'surprise' can be modeled by emoticons. Could one detect plot in sequences of emoticons?

Cheers!, Wouter.

E-mail: me@wouterbeek.com WWW: www.wouterbeek.com Tel.: 0647674624

On Mon, Jun 10, 2013 at 11:04 AM, Anne Ogborn notifications@github.com wrote:

I'd more than welcome contributions. The flat nature of weblog means it's particularly a project many people could contribute to. It's actually only a small part my work now - many pieces were just plucked out of other projects.

I imagine eventually weblog will end up rolled into somethign else. For now it's an exercise in sorting and cleaning bits of random code.

— Reply to this email directly or view it on GitHub.

Anniepoo commented 11 years ago

prolog's a channel on the freenode.net IRC server.

IRC is an ancient protocol (it dates from when having the internet forward your chat was an amazing piece of magic) for chat.

I suspect you'd love ##prolog

Anyway, there's a web interface at 

webchat.freenode.net

Or, if you're on most versions of Linux for a desktop, try the Xchat client.

On windows I use Besirc

You can use any nick you want - Some people 'register' their nicks.

Be wonderful to have you on ##prolog!

You might also enjoy the ##swig channel, which discusses all things semantic web

From: Wouter Beek notifications@github.com To: Anniepoo/weblog weblog@noreply.github.com Cc: Anne Ogborn annie66us@yahoo.com Sent: Wednesday, June 12, 2013 2:17 AM Subject: Re: [weblog] Wouter's Generics (#6)

Hi Anne,

Thanks for your positive reactions! And sorry for me writing back with a slight delay. I have a hate/love relationship with my mailbox :-)

*##prolog

PGC As I already expressed in my previous email, I am not too happy with the architectural underpinnings of PGC currently. It's development is primarily driven by research purposes (produce results for the next conference), and these often conflict with software design principles (modularity, reusability, documentation, etc.). I do think that some parts of PGC could be spun off in the future as Prolog packages. I'm thinking primarily of the TMS and ILP modules (but there may be other candidates, a future version of DCG maybe).

weblog: non-monolithic architecture I like your approach in building weblog! I would like to elaborate a bit on your first point, involving the non-monolithic architecture of weblog:

*"It's forbidden for the entire system to become a monolithic 'take it or leave it' lib. If you want the maps, currently you only need the info/maps subtree, the static files from statics, resources, and keys. After a bit I'm hoping a core of infrastructure settles down so to use a piece you just take the tiny infrastructure and the piece."

*:- git_register_namespace(anne_pgc, https://github.com/Anniepoo/PrologGenericsCollection.git';).

This would Git pull the anne_pgc repository locally as a submodule. This would allow local changes to 'DCG/emoticons.pl' to be pushed back to the original Git repository.

*:- use_git_module(anne_pgc, 'DCG/emoticons.pl').

The file 'DCG/emoticons.pl' would be consulted from the previously registered submodule.

These 'remote module imports' could of could be processed recursively. This may include import-loops, but for a first version it may be reasonable to assume that people don't do weird stuff :-). I'm not sure whether this can be easily done using =|library(git)|=.

*Emoticons

The plot may be either simple or complex, although complex is better. Simple plots have only a “change of fortune” (catastrophe). Complex plots have both “reversal of intention” (peripeteia) and “recognition” (anagnorisis) connected with the catastrophe. Both peripeteia and anagnorisis turn upon surprise. Aristotle explains that a peripeteia occurs when a character produces an effect opposite to that which he intended to produce, while an anagnorisis “is a change from ignorance to knowledge, producing love or hate between the persons destined for good or bad fortune.” He argues that the best plots combine these two as part of their cause-and-effect chain (i.e., the peripeteia leads directly to the anagnorisis); this in turns creates the catastrophe, leading to the final “scene of suffering”.

Notions like 'fortune', 'love', 'hate', 'surprise' can be modeled by emoticons. Could one detect plot in sequences of emoticons?

Cheers!, Wouter.

E-mail: me@wouterbeek.com WWW: www.wouterbeek.com Tel.: 0647674624

On Mon, Jun 10, 2013 at 11:04 AM, Anne Ogborn notifications@github.com wrote:

I'd more than welcome contributions. The flat nature of weblog means it's particularly a project many people could contribute to. It's actually only a small part my work now - many pieces were just plucked out of other projects.

I imagine eventually weblog will end up rolled into somethign else. For now it's an exercise in sorting and cleaning bits of random code.

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

Anniepoo commented 11 years ago

closed WNF, per 'more than a bit' interesting discussion moved to wiki