Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

It works for me.

6 (31.6%)

It does not work for me.

1 (5.3%)

I'd be willing to help test it.

6 (31.6%)

I'm not interested in testing it.

1 (5.3%)

I might be willing to help test it.

5 (26.3%)

Total Members Voted: 14

[Eagleon]

Also, Angle, as someone who loves designing but hates programming UIs, if you have any question about whether something you're thinking about for this is possible or technically accurate, I encourage you to disregard that and let your developers tell you thatcomplain about it and get it done anyway instead You can always pull in more of us.

I suggest that as you work out more of what you want from the project, we shift onto a more collaborative medium like Google Docs to share ideas and feedback a little faster. I'm onboard for whatever. I need a little more direction to start work though (I can't run or serve a database, electric bill is an issue), or else I'm just going to end up being redundant and in the way, code-wise.

Talking about this project with my own 'crew' (mostly family, granted, but still capable people) has me excited to continue. Especially since, for the time being, my own plans are on hold while I bunker down until the government starts back up. My mother (who has participated in budget matters) suggested that this might help Congress to present their debate more intelligently. My brother wants to try using something like it to figure out where we need to bone up and what we need to focus on for our university project. It could be applied to detect fault-points in diagnostic reasoning without using a large special-built informatics program, in medicine or just technician work - I can see repair people (and teams of repair people) using it to keep their reasoning and workflow more tightly organized, reducing redundant work without needing to hire a process engineer to point it out. That would be fantastic for small businesses that don't have that luxury or expertise.

Not to say you have to worry about fitting a UI or design to those things, just saying that I think it shows a lot of promise.

[Anvilfolk]

Eagleon: Getting Congress to debate intelligently would be an absurdly amazing achievement. A debating process at the Congress level, or at any institutional level really, that is accompanied by proper argumentation practices would be immeasurable in getting rid of some of the absolute absurd statements we hear some politicians say.

Plus, I'd love to see a lot of the applications of these systems you are talking about.



Here's the current situation. So far, none of the proposals we've seen here so far warrant significant involvement from my research group. Please don't take it the wrong way, but like I said before, we're talking about some serious involvement on our part, which could take up a non-trivial amount of what we do for work daily, at the expense of our other research activities.

Most of the proposals I've seen here are either going in a direction that is of little interest to us academically (e.g. they're not interested in calculating a formal outcome to a debate, simply in representing it); or whoever's developing it doesn't really have a lot of time; or its ideas are still a little too abstract.

It's very hard for us to advise an open-source community, since all of us are pretty busy and coordinating with such a fluid entity requires a whole lot more involvement than working with an independent and efficient implementation team/person.

However, if you guys are interested in following up with the idea that we want a formal outcome to a debate that we need to compute and present to the user (i.e. based on the Social Abstract Argumentation that we presented in our papers, open to modification), I'd be happy to help around on my free time. That means I can advise on some technicalities of the project, related to efficiency and good software practices, as well as how the infrastructure is supported, and might even get my hands dirty at some point

If you are interested, you should state how you would like to contribute to the project and your qualifications for it. This should help us organise people around better. Also, before starting any implementation, we must figure out the basic architecture of the system. I have a couple of ideas for that, but would like to hear back from you all first.


Since I'm already volunteering with this post, I'll start. Let's meet each other Here's what I'd like to help doing:

• - Overall my goal is to have an implementation of the SAA theory.
• Alter the theory as necessary to make the implementation usable and provide what the users want.
• I can be the liaison with my research group as the project becomes more mature, and perhaps involve it officially if this matures enough.
• Make sure that the overall architecture is extensible and as far-reaching as possible. We want it to be technically possible for this to be pervasive.
• Advise overall tech stuff.
• Set up the tech infrastructure for this, like manage GitHub repositories, etc.

My qualifications: I'm a 4th year CS PhD student, and I've got a BSc and an MSc also in CS. I don't know all of these newfangled web technologies, so I probably won't do any of that, but I have a fair knowledge of software architecture, DB and programming languages.

[Angle]

I have this thing where I will occasionally get wildly excited about a project, work at it for a while, and then get burned out. I'm afraid I've kinda reached that point: I'd like to continue, but I just don't know how to proceed. That said, I'd be happy to put together a google doc page, if people are interested.

[Eagleon]

Angle: It's no problem, no pressure, no disappointment or terrible all-consuming rage or anything, I understand that feeling. Put up a doc page and we can figure out how we'll get this done (or just talk, that's cool), because I'm still excited

Anvil: Sounds good to me. I'm interested in getting an SAA model first as well, since it's based on published work. The idea of a formal outcome is definitely complimentary to having something that can also function to highlight contradictions and areas that need more backing data or statistical examination for bias. I'm only just poking my head up into collaboration with this, so forgive me if I get distracted by that.
Other areas I'd like to contribute:

• Outline and plan the datastructure for each component, once we figure out what those components are. I love datastructures, finding and eliminating redundancies, etc.
• Make sure there is an interface to the architecture that is as generic as possible. Down the line including things like references to video, HTML, PDF, images, just basically any element we'd like to include in a quickly user-formattable way would permit this to be applied to much more than 'just' debate
• Porting what we have and what I can to Java for general use
• Documentation, organizational and otherwise, with some help for accuracy in terminology and thorough head-kicking for verbosity At the very least I'm enthusiastic with my java-docs, if not entirely lucid
• Debugging, analysis for problem areas, as able
• Research on related projects and hunting down code-snippets that are faster, better, stronger than our own

Qualifications are nebulous at best, unfortunately. I have two courses in Java to point to as formal instruction. My formal math is rusty but getting steadily better as I work outside my comfort zones. I have experience writing much more carefully edited documents than I've written here (my love of parentheticals can be suppressed ), but I can't point at anything to prove that.

[Anvilfolk]

Angle: no worries whatsoever! I'm afraid I might've been putting too much pressure on something that was meant to be a bit of a hobby project rather than something super serious. My fault on that, so my apologies if I've inadvertently caused some or all of that burnout Anyway, if this is going to be an open-source project like you wanted it to be, and I don't see any reason why not, then everybody's more than invited to participate, even if just bouncing ideas

Eagleon, awesome! From my conversation with BoboJack, I think he's also pretty interested in these kinds of things, and his ideas were already super close to SAA, so hopefully he might contribute a bit.

It's important to realise that this is totally not going to be a full-time job or anything. When you can and feel like it, you contribute. That's all

We could use GitHub's wiki system to store decisions we make. In the meantime, we can keep our discussions over here.


Here's my thoughts about architecture. There should be three components:

• Database: it simply stores all the arguments and attacks in an easily accessible format. There can be multiple of these, all over the internet. One for each website, and each website has an ID to identify its own arguments; like A1:D1 means argument 1 from database 1.
• SAA component: it is authoritative over one or more databases. It accesses the databases, crunches the data to provide outcomes, and stores argument acceptabilities in the database. It can do this either periodically or whenever there is an update.
• Interface: there can be as many of these as you want. They can be programmed in any language, and available on any platform. The more the merrier. These gather data from the databases, and just display it for users. They also provide function for adding/removing arguments, etc.

So basically, you've got your arguments all over the place, and some applications crunch the numbers for you, so that you can always display debate outcomes in the interfaces.

Both the interfaces and the SAA components are going to have to query several databases. If I query a database D1, and an argument D1:A1 is attacked by an argument A2 from database D2, then I'm going to have to query D2 about the strength of A2. We can use DNS as an inspiration for how to do these things. We can provide this argument-fetching service as a library with bindings in several languages.

Also, databases are going to have to carry enough metadata for each argument so that you can configure the whole thing like a forum/subforum/thread thing. This needs some thought.


Also, does anyone have a name for the project? That way we could create a GitHub repository (if everyone is ok with that choice, which is free!) and start editing its wiki with information we agree on. I've never done wiki editing before, but it can't be too hard, right?

[Angle]

@Eagleon, Anvilfolk: Not your fault, I do this all the time on my own.

Here's a scenarii, albeit with more pictures than words:

Spoiler (click to show/hide)

"When user reach log in to the main forum page, they will see what looks like most any other forum: lists of topics, with some kind of measurement determining activity. Like This:

They can go and click on one of these to look into that thread, getting this view:

From here, they can navigate the forum, by clicking on one of the peripheral posts, or by zooming out to a view like this:

The purple dot is the center topic, green dots are posts from other topics that have been included (The two black dots over the purple one should be green), and the red dot is a reply that has also been posted to the main bulletin (It's one of the topics in the first picture). The colors are just for the purpose of this demonstration, the actual product would not have them, or would have them for different reasons. By mousing over a particular post, they can display the title and the first few sentences. By clicking, they can reorient their view around that post, and by double clicking, they can drop back into the second stage view. From there, they can begin composing a new post by choosing which posts they want it to be in reply to. Once they have all of these selected, they can begin writing they're post, in a view that looks like this:

And here's the link to the google doc..

In terms of forum name, I was thinking of something based on ancient democracy, freedom of speech, discussion, discourse, that sort of thing. I had been working under Project Athens, but decided I didn't like it.

[Eagleon]

The google doc is coming along. Right now we're bashing out datapoints that can be used for a more thorough design document once all the pieces are together.

We could use some help figuring out what database/server software to work with, and what needs to be done to get a basic interface with one on a remote client up and running. I have very little experience with them - I understand protocol buffers as our best bet for getting readable information to our interface(s) without sending huge XML files or similar back and forth constantly, but I could be completely off-target for all I know.

Lacking that, I could start basing my work on Gephi's server plugin and try to reduce what it provides to an arbitrarily chosen database format, but I don't know how good it'd be, or if there's a better solution already around. Does anyone know any tutorials I could poke through to learn where my efforts are best placed? I'd be more willing to work on a local database if I knew I wasn't wasting my time on things that have already been worked out.

[BoboJack]

We could use some help figuring out what database/server software to work with,

Database:
The big 3 of Databases I know: MySQL, PostgreSQL and MongoDB.
I've used PostgreSQL and it was ok. I've tried MongoDB first, wasn't so nice.
If someone can come up with a layout for mongoDB upfront, it would maybe be worth it.

Server:
Options I know of:
Apache HTTP server and write stuff in php (which sounds very ugly to me)
Node.js very cool for a community project. Server and web fronted would be in the same, very common, language. +1 from me.
Ruby on Rails also very popular now, but slow to my knowledge.

I've used a Haskell library, http://snapframework.com/, just for the record
Here's a dropbox folder of my stuff

This is the coffeescript(javascript) front-end I've written.

and what needs to be done to get a basic interface with one on a remote client up and running.

I wholeheartedly recommend D3: http://d3js.org/

I understand protocol buffers as our best bet for getting readable information to our interface(s) without sending huge XML files or similar back and forth constantly

Just send JSON data. JSON is widely supported (native support in javascript, libraries everywhere) and has an efficient binary counterpart called BSON.
MongoDB also uses BSON!

[Antsan]

Apache HTTP server and write stuff in php (which sounds very ugly to me)

Actually Apache can be configured to accept any language, if I remember that right. At the very least Hunchentoot (Common Lisp) can work with Apache.

[BoboJack]

Actually Apache can be configured to accept any language, if I remember that right. At the very least Hunchentoot (Common Lisp) can work with Apache.

Right. I didn't think about all the cgi stuff.
CGI doesn't sound like a "batteries included" solution though.

[Anvilfolk]

Hey guys,

I'm going through the document and adding comments right now. This is so cool I am itching to get started

We need a name to set up the GitHub repository. From there we can start putting up code, put information on a nice wiki, some pretty images of what we envision, and I have a webserver that we can use for testing purposes.

I'm tempted to just start with something simple like SocialDebate or TrueDebate - we can easily change the name at this stage.


Quick note: I think you guys are on the same page as to what you mean by server side stuff, but I think I haven't quite gotten it. The database stores the debate itself. The interfaces grabs information from the DB and shows it to the user. What are you guys expecting the server side stuff to do? I've always imagined that all it's doing is computing and updating debate outcomes.

Also, Angle, could you update the OP with the google doc and other information? We should sig this and make it obvious that it's open-source and open to participation

[BoboJack]

What are you guys expecting the server side stuff to do?

The server could also host the web front-end and manage users and their authentication.
It would also make changes to the DB through an API accessible from the front-end.
+calculations

The interfaces grabs information from the DB and shows it to the user.

How would the interface authenticate with the DB?
If the interface can directly change the DB (voting for example) you could use the login/password from the interface to make any changes you want.

[Antsan]

I have no experience at all with server-client relations and all of that stuff, but I think computation should not be done by the server but the client. When more and more people start accessing the server you would probably get serious performance problems pretty soon.

[Eagleon]

Agreed, server should provide data and decide if client's changes are trustworthy and sane, nothing else. Even for argumentation - for an argumentation-oriented client, there's no reason for the end user to meddle with the results, because everyone else should be getting the same result. It'd be like writing over the teacher's answers to cheat. If we introduce elements of randomness, or if there are results that crop up that are different for other users because of floating point errors and crap like that, we can shift more of it server-side for that particular function. For now the handshake process, storage, retrieval, and sending of data is more than enough to chew on.

BoboJack - thank you! I'll look at those when I get back from my aunt's later. I knew JSON was a thing, but I didn't know it was that kind of thing, heh. So much to learn.

[BoboJack]

The computation needs to be on the server, because search queries need the "acceptance of a topic" as a search criteria.
Also server side computation should be OK, if you don't have to recalculate the whole network on every change.
If the client would do all the computation, the client would have to recalculate everything again on every access, at least for a web front-end.
I also wouldn't want a website to suck all the energy of my smartphone.

Also I encourage you to make the communication between server and client work through a RESTful API (basically the client communicates with the server only through a bunch of HTTP requests)