<https://youtu.be/2xZqoU-PCMY> - video demo of v1....
# share-your-work
j

https://youtu.be/2xZqoU-PCMY

- video demo of v1.1.0-alpha of Blawx, released yesterday. Blockly-based easy-to-use visual programming environment for declarative logic knowledge representations of legislation. Any and all feedback welcome.
a
The attribute declarations that say "any number of" made me nervous; maybe it's obvious for people who know older versions of the project, but it would help to explain how to specify that, e.g. there are actually exactly two players (what happens when you try to add a third player to a game?). When you started talking about the "'beats' relation", I was fully expecting a general system for relations, not just attributes. It took me a while to figure out how the rule for winning RPS was commutative; that might be worth explaining immediately (in future versions, I guess, I'm sure this was enough work to make without trying to do weird edits). I feel like there were a couple other places where I wasn't sure how the system was going to resolve apparent underspecification. I'm tempted to suggest that "scenario" is a more evocative term than "model" for people who don't care about formal logic.
j
That's very valuable, Andrew, thanks. The opacity of "model" is a problem. Part of the reason I didn't call them 'scenarios', is because the word 'scenario' is typically used in legal training in the context of 'fact scenario', which in comp-sci terms is more analogous to "inputs" than it is to models, which are more of an output... but your point is well-taken. "Stable model" is not a particularly useful term, and we can do better.
🤔 1
Technically, they are relations, and not attributes, which is probably why my vocabulary slipped, there.
A previous version of the tool allowed you to be explicit about cardinality, but the current implementation doesn't have that feature, yet, so the only attribute declaration available is the "any number of". Previous versions indeed.
👍 1
It took me a while to figure out how the rule for winning RPS was commutative
I'm not sure what this means, exactly. It's not commutative, I don't think. I expect that if the semantics were a little fuzzy, that's fine. That can be motivation for someone to read the documentation (when it catches up). But I'd be interested to know what you mean, exactly.
a
I guess I assumed that Player1 and Player2 were in some sense fixed prior to the rule about winning being evaluated, and there was no rule that specified how Player2 could win. I was thinking you were going to add another rule about how if Player2's throw beats Player1's, etc, but instead you just declared it done. :)
j
Oh, I see! Yes, it's logic programming, so they are logical variables, which are unified. When you run the query, it checks bob/bob, bob/jane, jane/bob, and jane/jane to see if any of them work. (To be honest, it also checks "rock/scissors", etc.). That's something that is covered in the beginner's documentation, but not in the video.