Welcome to TiddlyWiki created by Jeremy Ruston, Copyright © 2007 UnaMesa Association
|''Type:''|file|
|''URL:''|http://tiddlywiki.bidix.info|
|''Workspace:''|(default)|
This tiddler was automatically created to record the details of this server
I suspect that extremal models of a smart adversary are weak. I.e., assuming that the adversary wants to //seemingly// maximize (e.g., running in a greedy manner), or //seemingly// minimize its utility (e.g., stopping in the covered area, wait a bit and then run back and escape through the same point which it used to enter - deceptive startegy). The reason would be that these models lead to singular cases, probability of which is probably rather high (these strategies require just one level of meta-level thinking, i.e., the enemy want to maximize its utility and thus straightforwardly acts in a greedy way). The minimization is a bit more complicated, because it assumes that the target wants to escape, but it knows that the tracker knows this, therefore the target predicts that the tracker will try to minimize its utility exactly along the routes which are maximal for it. Hence, it chooses to do exactly the opposite and acts as if it wanted to minimize its utility. I.e., first level of meta-reasoning at work.
But if we rule out the extremal positions as they are quite easily predictable, we end up with a large number of options with non-extremal utility which require much higher levels of meta-level reasoning. Now, assuming that the escape routes are ordered according to their expected naive utility, in the infinitesimal case, the target should choose the route with utility exactly in the middle between the minimal and maximal. But again, this is a single case, thus it's easily predictable!!!
//Assuming there are classes of options according to the level of meta-reasoning required to identify the solutions from this class as the extremal points, the best the target can do is to randomly choose (assuming a uniform distribution) an option which belongs to the largest of them!!!//
This requires some kind of probabilistic analysis of options according to the meta-level reasoning. We also have to assume that the setup of the game is such, that every option is an extremal case on some level of meta-reasoning, or something like that...
Suppose a MAS in which agents can ask other agents about their capabilities so that they can get help when needed. Now, there are two ways to do it:
# agent which needs help sends requests to other agents, or
# everybody publishes an interface, i.e., description of capabilities/services offered and the help-seeking agents simply chooses one of them from some kind of a yellow pages service, or alike.
Now in both cases, agents must be able to process and reason about such capability descriptions. As these capabilities can be complex processes which can be also unknown apriori (in a very open system), we need a very general and expressive language for their description. This must already be expressive enough to enable encoding of temporal aspects of those capabilities...
A straightforward idea is to take a ''temporal logic'', or a language which can be compiled into such a logic - ideally a ''fragment'' of it. Since for a well encapsulated component/behaviour/capability, there is just a single future (the same argument as I used for BSM+DCTL*), ''LTL'' would be a natural choice.
Now we are able to even reason about those capabilities and match them against each other. So the problem of //plan matching// could be moved into the realm of LTL formulae. I.e., provided that we have two capabilities/plans $\pi_1$ and $\pi_2$ described by LTL formulae $\varphi_1$ and $\varphi_2$ respectively, we can say that the capability $\pi_1$ can be used to implement the capability $\pi_2$ (e.g., the query for help) iff
\[ \varphi_1 \models \varphi_1 \]
* --- prepare the AC/SC charter ---
Some notes I took while trying to get accustomed to the ATG web (outside, wiki, internal, docarch, etc.)
!! Summary
Generally, I find the design and the website style quite appealing and nice. A bit more should be invested in sorting out the stuff and trying to see the website from the point of view of a visitor. Some things are a bit confusing, such as teh group hierarchy/structure.
!! More detailed comments
# ''contact details'':
** no phone number, no fax number, no e-mail, no secretary contact, just a plain s-mail address
# ''members'':
** the structure of the group is completely mysterious. Who is the management? Who are the senior staff members, who are PhD. students and who are undergrads, secretaries, technicians, etc.?
** e-mail contact to members, but no phone number, room number, etc. It would be better to at least link to the automatically generated Dept. of Cybernetics pages (they have profile for every member, right? [[See|http://cyber.felk.cvut.cz/people/page.php?id=362&detailed=y]])
# ''projects'':
** very difficult to see which projects are running, which are finished, etc.
** little about projects members and/or contacts to projects
** videos of all projects which include some should also be there (*Scout, tactical, AgentC, etc.)
** some projects do not really have a project website. That's not bad //per se//, except they leave a kind of an "//empty//" impression
*** (list them!)
# ''hierarchy and position of the group''
** from the web it's clear that the group is at the FEE@CVUT, but how does it play with the Gerstner Lab?
** perhaps a brief //history// section?
# ''wiki vs. internal''
** there seems to be some kind of confusion here. Click on //wiki/private// pages and that is different than //internal//
** there's no way to get from wiki to docarch, i.e., the internal area. This needs some rethinking. There should be a public portal (i.e., http://agents.felk.cvut.cz/) and a separate internal portal for the members. But just a single one.
# ''news'' & ''highlights''
** up-to-date news section including actual information (conferences, projects starting, finishing, seminars, etc.) could add value to the website
** more promotion of members' achievements could look better, e.g., covers of books members wrote, edited, etc.
!What?
//Mental State// is an //open research scrapbook//. It is a collection of more, or less, (a)ssorted notes on my research. It revolves mostly around [[Artificial Intelligence|http://en.wikipedia.org/wiki/Artificial_intelligence]], in particular cognitive agents, multi-agent systems and related topics. Occasionally it touches also other fields and disciplines. //Mental State// simply contains whatever I considered at certain point in time important, or relevant for [[my|http://peter.aronde.net/]] own research work.
!Who?
My name is of [[Peter Novák|http://peter.aronde.net/]]. Currently, I am a postdoc fellow in [[Agent Technology Center|http://agents.felk.cvut.cz/]] of [[Department of Cybernetics|http://cyber.felk.cvut.cz/]], [[Czech Technical University|http://www.cvut.cz/]] in Prague, Czech Republic.
!Why?
In the course of my doctoral studies I used to collect notes, links and sketches of ideas mostly in my notice books. Most of the time, I never read them again, except for notes which were very much "task oriented", i.e., written in the context of a current project, paper, on-going smaller research. As my perspective was broadening, at certain point, however, it became quite difficult for me to keep track of several paths of exploration which run in parallel. Thus I started to record notes by sending them to myself per e-mail. Well, while this approach works, it doesn't scale up very well (at least not for me) as after a short time my inbox was full of junk consisting of mostly self-generated e-mail notes. I started to have a need to a better way of storing notes, yet I do not want to them to be sorted to much. After all, I am not after spending more time with sorting my notes than with making progress on my on-going projects.
Some time ago, I came across the notion of [[Open Notebook Science|http://en.wikipedia.org/wiki/Open_notebook_science]]. The idea very much resonated with me. And at the point when I started to look for a solution to my notes, I realized that perhaps a technology, such as a personal [[wiki|http://en.wikipedia.org/wiki/Wiki]], used by others for open notebooks might be also useful for me. However, most of the open research notebooks are kept in a form of an electronic [[lab book|http://en.wikipedia.org/wiki/Lab_notebook]], so that the records are structured and often can be taken sequentially as they can be understood as a journal of a researcher. However, I am not sure this form would work for me. Most of my research, even when taking applied avenues, is (or resembles that) of a theoretical nature. It rather is a cloud of thoughts, which occasionally result in something coherent and useful out of which perhaps a research paper might come out. In fact, it probably resembles a [[scrapbook|http://en.wikipedia.org/wiki/Scrapbook]], rather than a structured and tidy notebook. In search for a lab book variant useful for a theoretician, I stumbled upon [[Garrett Lisi|http://sifter.org/~aglisi/]]'s open research notebook [[Deferential Geometry|http://deferentialgeometry.org/]] and I quickly saw that that type of thing could work for me. I.e., an unstructured wiki, rather a flat database of records, which refer each other and which are structured only //ex post//, when the author has a particular need to structure them into a more coherent body. That's how //Mental State// was started and I am myself curious how far will I go with it.
!Why //Mental State//?
My long run, interests are revolving around cognitive robotics research, i.e., the art and craft of creating, possibly teams of, artificial entities, agents, which //model// the world around them, //reason// about it and use that model for their //decision making//. Thus an internal state of an agent, its //mental state// is essential for such a research stance. In a way, this scrapbook is meant to capture a fragment of own mental state relevant to my research.
The idea is actually quite simple. Let's have a BSM which consists of rules of the following type
\[ \models_G \gamma \longrightarrow \tau \]
$\models_G$ is a query operator on the agent's goal base, $\gamma$ is a goal formula and $\tau$ is an arbitrary mental state transformer, basically leading to real actions in the environment. Let also $\mathcal{L}_G$ be the language of goal formulae and $\Gamma$ be the set of agent's potential desires, i.e., a collection of formulae which the agent is capable of handling, i.e., acting towards, or commit to.
Now in every mental state \sigma we can identify the set
\[ \Gamma_\mathit{active}= \{ \gamma | \sigma \models_G \gamma = \top \} \]
as the set of //currently pursued goals//. All the other goals are //inactive//.
Alternatively, we can also relate the active goals to those which actually currently reside in $\Gamma$. I.e., if $\Gamma$ is a set, then we can additionally identify //suspended// goals in a mental state $\sigma = (\mathit{Beliefs}, \mathit{Goals})$
\[ \Gamma_\mathit{suspended}= \{ \gamma | \mathit{Goals} \models_G \gamma = \bot \wedge \gamma \in \mathit{Goals} \} \]
This distinction would allow us to argue that in BSM goals can switch extremely fast as a consequence of reasoning within the agent's goal base and resolution of the currently consistent set of actual goals. Actually some kind of [[Non-monotonic temporal logics]] would be very useful in this kind of a setting.
It might be interesting and useful to try to take a fundamental approach to the problem of //adversarial planning with background knowledge//. I would take the HTN planning as the basis and try to formulate a framework where the knowledge about the adversary is //procedural/algorithmic// in the form of partial HTN operators. This could play well with the (HTN-based?) multi-agent planner. Such a setup would perhaps allow us to study properties of the problem w.r.t., various constraints imposed on the form of the background knowledge. Apart from that, it would allow to formulate a //nicer// instance of the idea formulate in the AAMAS/ICAART paper by VLY et al.
# each player could be characterized by a set of planning operators.
# when the main agent is planning, it is capable of constructing at least partial plans for adversaries and take them into account while constructing his own plan
# this could open a way towards a clear formulation of the adversarial planning problem as a complex planning problem (which it actually is).
There seem to be at least two threads of stuff called "Agent Dynamic Logic":
# Schmidt, Tishkovsky and Hustadt: [[Interactions between Knowledge, Action and Commitment within Agent Dynamic Logic|http://www.springerlink.com/content/q28189n262074864/fulltext.pdf]]
# [[Wayne Wobcke's works|http://www.cse.unsw.edu.au/~wobcke/Publications.html]]
Schmidt et al.'s work seems to be more complete than the other one.
I should study these logics in order to be able to well relate the DCTL* work into a proper context.
A lot of research goes into various aspects of agents, yet actually most of it is just a hidden agenda of other AI research fields, such as KRR, machine learning, game theory, etc. Often we do reinvent wheel in the agent community because we ignore the fact that most of the topics we care for (especially in the KRR realm) are not agent-specific. To keep one's research healthy, we should see //agent-oriented computing// as a quest for technologies enabling synergistic exploitation and utilization of various AI technologies. I.e., the field should care more for internal structure and intra-agent infrastructure for agents, rather than specifics of their internal mechanisms, such as reasoning, adaptivity, etc. These are better solved elsewhere and we, the AAMAS researchers, should enable their usage as if these technologies were plugins. Only in a way similar to this, we arrive at better applications than those separate AI fields are capable to deliver.
!! Available notes
<<matchTags "#%0 (%2)<br>^^%5^^" "\n" sort:-modified [[agentcontest AND NOT project]]>>
//An AgentSpeak Meta-Interpreter and its Applications// by [[Michael Winikoff]].
This work seems to go along the lines of rapid prototyping for languages such as [[AgentSpeak]]. In that sense, meta interpreters for agent oriented languages are similar to what I claim for the framework of [[Behavioural State Machines]]. Namely, that it can be seen as a meta-language for other AOPLs. The inspiration to this claim is the work with [[Koen Hindriks]] on the relationship between [[GOAL]] and [[Jazzyk]].
* Michael shows there how to make the selection functions of AgentSpeak explicit. This is exaclty something what I proposed in general for doing in Jazzyk. Very relevant work here...
* Michael even uses similar proof technique as we did with Koen for the paper on GOAL and Jazzyk!
Blog: http://anand-rao.com/
Corporate homepage: http://www.diamondconsultants.com/PublicSite/people/team/?topic=Partners&name=Anand+S.+Rao
* BDI pioneer.
* curently with [[Diamond Management & Technology Consultants, Inc.|http://www.diamondconsultants.com/]]
* very interesting work on //behavioural economics & BDI//: [[Behavioral Economics Comes to the Rescue of Retirement Savings]]
* also links interesting blogs on multi-agent systems applications etc.
[[Answer Set Programming]] language. Also A-Prolog. Refer to [[Knowledge Representation, Reasoning and Declarative Problem Solving]].
http://www.cs.uni-potsdam.de/~torsten/asp/
Maintained by [[Torsten Schaub]] of Uni Potsdam, Germany..
A very interesting article by [[Tom Barbalet]], a guy from artificial life and simulations(?). Provides very interesting insights into complex systems.
http://www.hplusmagazine.com/articles/ai/ape-brain-narcissism-misses-singularity-artificial-life-view
Blurb:
"After 13 years, the creator of the Noble Ape cognitive simulation says he's learned two things about artificial intelligence. 'Survival is a far better metric of intelligence than replicating human intelligence,' and "There are a number of examples of vastly more intelligent systems (in terms of survival) than human intelligence." Both Apple and Intel have used his simulation as a processor metric, but now Tom Barbalet argues its insights could be broadly applied to real life. His examples of durable non-human systems? The legal system, the health care system, and even the internet, where individual humans are simply the 'passive maintaining agents,' and the systems can't be conquered without a human onslaught that's several magnitudes larger."
http://www.prnewswire.com/news-releases/army-experiments-to-bring-increased-network-connectivity-to-the-soldier-79327582.html
http://en.wikipedia.org/wiki/Strong_AI
Vanevaar Bush's take on research and beyond:
http://www.theatlantic.com/doc/194507/bush
The idea is to model each mst as an ongoing process which can be
active (enabled), suspended, etc. within a Kripke structure trace. This
can provide a bridge to process algebras and similar stuff...
That leads to a kind of Behavioural paradigm for programming agents.
They are collections of behaviours. Also roles etc...
http://en.wikipedia.org/wiki/Actor_model
http://en.wikipedia.org/wiki/API-Calculus
Actually the BDI execution model ought to be analysed w.r.t. the process algebra formalism. Thsi seems to be very relevant and most probably also a very suitable formal framework for showing how BDI executions stand w.r.t. the standard parallel computation.
This architecture seems to be more relevant than the Tambe/TEAMCORE's works (STEAM, Machinetta, Team-oriented programming, etc.) in that it doesn't seem to deal with proxies, but rather goes towards multi-robot systems.
* [[Gal Kaminka's publications on teamwork and coordination|http://u.cs.biu.ac.il/~galk/Publications/class_rescat.html#Teamwork%20and%20Coordination]]
* Gal A. Kaminka and Inna Frenkel. //Integration of Coordination Mechanisms in the BITE Multi-Robot Architecture//. In Proceedings of IEEE International Conference on Robotics and Automation (ICRA-07), 2007.
* Thuc D.Vu, Jared Go, Gal A. Kaminka, Manuela M. Veloso, and Brett Browning. //MONAD: A Flexible Architecture for Multi-Agent Control//. In Proceedings of the Second International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS-03), pp. , 2003.
Check better!!!
! Behavioural State Machines: Agent Programming and Engineering
!! To be done
''REDO''
* journal paper(s)
** more macros for various commitments w.r.t. goals:
*** open-minded
*** single-minded commitment
*** flexible-single minded
*** etc. - the more and trivial, the better
** handle variables for the macros better (ask Wojtek for help?)
----
!! Notes on the BSM project
<<matchTags "#%0 (%2)<br>^^%5^^" "\n" sort:-modified [[BSM AND NOT project]]>>
I should finally work out the compilation of 2APL into BSM. In itself it would be a insignificant paper, but what might be a nice blow into the community could be to provide those compilations as Jazzyk modules and allow their usage in a single agent program ;-) mixing them. I.e., several rules of GOAL type, a part of the program in AgentSpeak and a part in 2APL. Or allowing to write mixed rules adding things to intention stacks and at the same time directly acting in the environment...
That might be a funny piece of work. I do not believe it would be significant, but at least it would show the major differences between the rivals on the garbage heap...
The technical trick would be macros for actions (atomic plans) hiding that actual manipulations of intention stacks...
[[Barry Silverman|http://www.seas.upenn.edu/~barryg/]] is doing a very interesting pioneering research on [[Serious Games]].
http://www.seas.upenn.edu/~barryg/sg.html
* customized Unreal Tournament via GameBots
* a lot of stuff of US Army (also australians?)
http://www.diamondconsultants.com/PublicSite/ideas/perspectives/downloads/INSIGHT%20-%20Retirement_Behavioral%20Economics.pdf
An interesting application of BDI concepts to real world case, namely analysis of pension funds in US/UK/AU-like environment.
What I am after in the [[TL system specifications with failures]] note seems to be a etude on [[Bernoulli Processes|http://en.wikipedia.org/wiki/Bernoulli_process]]
Excerpts:
@@
* The number of successes in the first n trials, which has a binomial distribution B(n, p)
* The number of trials needed to get r successes, which has a negative binomial distribution NB(r, p)
* The number of trials needed to get one success, which has a geometric distribution NB(1, p), a special case of the negative binomial distribution
@@
Cf. also [[geometric distribution|http://en.wikipedia.org/wiki/Geometric_distribution]]
An interesting article about piece of research in which the authors investigated reactivity to external events. They foiund that when we are reacting to something, we act significantly faster than when we act as a result of decision making. Interesting...
http://sciencenow.sciencemag.org/cgi/content/full/2010/203/1
Homepage: http://www.pst.ifi.lmu.de/people/staff/riemsdijk/ (soon obsolete?)
Papers: http://mmi.tudelft.nl/index.php?option=com_contact&task=view&id=139
Cognitive robots are autonomous agents usually embodied in highly-dynamic unstructured environments and functionality of which is based on cognitive processes, such as complex perception or knowledge representation and reasoning. We are concerned especially with those which internally construct a symbolic model of their environment, themselves as well as their peers (the world) and subsequently use it as a basis for decision making, action selection and possibly even communication and coordination. Because of the environment dynamics, such agents must be capable of acquiring new knowledge and incorporating it into its internal knowledge base(s).
The proposed research project should start from knowledge bases with non-monotonic semantics, in particular the //Answer Set Programming// (ASP) approach. While there already exist a number of theoretical and analytical solutions to the problem of evolving knowledge bases w.r.t. ASP, due to various factors, they present either an overkill to the problem in question, or are inapplicable to the class of cognitive agents embodied in highly-dynamic environments. In particular, an ideal approach to updating agent's knowledge bases in this class of agents should respect the following issues
## in the context of perception, embodied agents frequently execute simple updates with factual knowledge;
## as a result of inter-agent communication the agent occasionally needs to execute an update with a relatively complex knowledge;
## because of the lack of unbounded memory, the approach cannot rely on unbounded histories of updates.
We propose a research topic towards a diploma thesis in which the candidate would
# propose an approach for incorporation of newly acquired knowledge into a logic-based knowledge base with //Answer Set Programming// semantics, such that it will be suitable for application in embodied cognitive agents (see the above constraints), and
# develop a prototype implementation of the approach, together with a case-study demonstrating its functionality in a simulated environment of a first-person shooter game (or other, subject to later agreement).
Besides the standard overview of the state of the art and introducing the approach itself, the final thesis should also provide a discussion of properties of the approach w.r.t. the consistency of the knowledge bases resulting from updates with the proposed technique. The thesis should be also accompanied by a quality technical manual for the implemented software (which should be published under an open-source license, such as GNU GPLv2/3).
The starting point for the research would be the study of the state of the art in the field of Dynamic Logic Programming. The initial resource pointers include among many others also:
* C. Baral [2003] //Knowledge Representation, Reasoning and Declarative Problem Solving//. Cambridge University Press.
* M. Gelfond [2008] //Answer sets//. In: Handbook of Knowledge Representation, Elsevier, pages 285-316.
* M. Brain, R. Watson and M. De Vos [2005] //An Interactive Approach to Answer Set Programming//. In: Answer Set Programming, Advances in Theory and Implementation, Proceedings of the 3rd Intl. ASP'05 Workshop, Bath, UK, September 27-29, 2005
* D. Billington, G. Antoniou, G. Governatori and M. J. Maher [1999] //Revising Nonmonotonic Theories: The Case of Defeasible Logic//. In: Proceedings of KI-99: Advances in Artificial Intelligence, 23rd Annual German Conference on Artificial Intelligence, Bonn, Germany, September 13-15, 1999
* J. Sefranek (2006) //Rethinking semantics of dynamic logic programming// In: Proceedings of NMR 2006
The research will be supervised by Jan Sefranek (Department of Applied Informatics, Comenius University) and Peter Novak (Department of Cybernetics, Czech Technical University). We are interested in high-quality self-motivated student(s) capable of independent work. The project should span 1+ year of both theoretical and practical work and should be concluded by a diploma thesis, preferably in English language. There is a possibility to also extend and split the project into several sub-projects, or reformulate the thesis topic so that it fits a significant partial result (subject to a later agreement).
/***
|Name|BreadcrumbsPluginInfo|
|Author|Eric Shulman|
|Source|http://www.TiddlyTools.com/#BreadcrumbsPlugin|
|Documentation|http://www.TiddlyTools.com/#BreadcrumbsPluginInfo|
|Version|2.1.0|
|License|[[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides|Story.prototype.displayTiddler,TiddlyWiki.prototype.removeTiddler|
|Description|Documentation for BreadcrumbsPlugin|
This plugin provides a list of links to all tiddlers opened during the session, creating a "trail of breadcrumbs" from one tiddler to the next, allowing you to quickly navigate to any previously viewed tiddler, or select 'home' to reset the display to the initial set of tiddlers that were open at the start of the session (i.e., when the document was loaded into the browser).
!!!!!Usage
<<<
syntax:
{{{
<<breadcrumbs homeSeparator crumbSeparator>>
}}}
By default, the breadcrumbs are displayed as a continuous, //horizontal// word-wrapped line of text, using default character sequences for ''homeSeparator'' (" | ") and ''crumbSeparator'' (" > "). The //optional// ''homeSeparator'' and ''crumbSeparator'' macro parameters allow you to specify alternative separators. For example, to display the breadcrumbs //vertically// (in a stack, rather than a row), set the separator values to use {{{[[<br>]]}}}... and, to display a horizontal line as the home separator, use {{{[[<html><hr></html>]]}}}.
<<<
!!!!!Examples:
<<<
{{{
<<breadcrumbs>>
}}}
<<breadcrumbs>>
{{{
<<breadcrumbs [[<html><hr></html>]] [[<br>]]>>
}}}
<<breadcrumbs [[<html><hr></html>]] [[<br>]]>>
<<<
!!!!!Customization
<<<
Using CSS and a few of the plugin configuration options (see below), you can make the breadcrumbs display resemble browser tabs by adding the following to your [[StyleSheet]]:
{{{
.breadCrumbs { border-bottom:1px solid; }
.breadCrumbs a {
border: 1px solid; padding: 0px 1em;
-moz-border-radius-topleft:.5em; -moz-border-radius-topright:.5em;
-webkit-border-top-left-radius:.5em; -webkit-border-top-right-radius:.5em;
}
}}}
and this in [[ConfigTweaks]] (tagged with systemConfig, of course):
{{{
config.options.chkShowStartupBreadcrumbs=true;
config.options.chkBreadcrumbsLimitOpenTiddlers=true;
config.options.txtBreadcrumbsLimitOpenTiddlers=1;
config.macros.breadcrumbs.homeSeparator=" ";
config.macros.breadcrumbs.crumbSeparator=" ";
}}}
<<<
!!!!!Configuration
<<<
__''display placement:''__
<<option chkCreateDefaultBreadcrumbs>> automatically create breadcrumbs display (if needed)
{{{<<option chkCreateDefaultBreadcrumbs>>}}}
>By default, the plugin automatically creates the "breadCrumbs" display element at the top of the story column, just above the tiddlerDisplay area. To manually control the display and placement of the breadcrumbs display, you can define a DIV with class="breadCrumbs" in a custom [[PageTemplate]] or embed the {{{<<breadcrumbs>>}}} macro in specific tiddler content.
>
>For example, to add the breadcrumbs below the mainMenu, change this:
{{{
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
}}}
>to:
{{{
<div id='mainMenu'>
<div refresh='content' tiddler='MainMenu'></div>
<div id='breadCrumbs' class='breadCrumbs'></div>
</div>
}}}
>You can also block automatic creation of the breadcrumbs display by setting
{{{
config.options.chkCreateDefaultBreadcrumbs=false;
}}}
>in a [[CookieJar]]/[[ConfigTweaks]] plugin tiddler.
__''other settings:''__
<<option chkShowBreadcrumbs>> show/hide breadcrumbs display
{{{<<option chkShowBreadcrumbs>>}}}
>This checkbox toggles the visibility of the breadcrumbs display. However, the display is not updated until the next crumb is added (or a previous crumb is clicked on). For immediate effect, the [[ToggleBreadcrumbs]] script uses [[InlineJavascriptPlugin]] to synchronize the checkbox setting and the breadcrumbs display.
<<option chkReorderBreadcrumbs>> re-order breadcrumbs when visiting a previously viewed tiddler
{{{<<option chkReorderBreadcrumbs>>}}}
>When visiting a previously viewed tiddler, the title of the most-recently displayed tiddler is simply moved to the end of the list and individual breadcrumbs are not removed from the list unless the underlying tiddler is deleted. When ''re-ordering'' is disabled, the breadcrumbs list is ''trimmed'' so that all crumbs following that tiddler are removed from the list.
<<option chkBreadcrumbsHideHomeLink>> omit 'Home' link from breadcrumbs display
{{{<<option chkBreadcrumbsHideHomeLink>>}}}
>Enabling this option suppresses the automatic display of the "Home" link (and home separator). To manually add the home link elsewhere in your document, use the following HTML:
{{{
<html><a href="javascript:;" onclick="config.macros.breadcrumbs.home()">home</a></html>
}}}
<<option chkBreadcrumbsSave>> prompt to save breadcrumbs when 'Home' link is pressed
{{{<<option chkBreadcrumbsSave>>}}}
>Whenever you press the 'home' button, you can be prompted to save the current breadcrumbs in a tiddler as a space-separated list of tiddler links (default title="SavedBreadcrumbs").
<<option chkShowStartupBreadcrumbs>> show breadcrumbs for 'startup' tiddlers
{{{<<option chkShowStartupBreadcrumbs>>}}}
>Breadcrumbs are usually only added for tiddlers that are opened after the document has been loaded, and not for tiddlers displayed during initial startup (e.g., [[DefaultTiddlers]]). Enabling this option displays breadcrumbs for all viewed tiddlers, regardless of when they are opened.
<<option chkBreadcrumbsReverse>> show breadcrumbs in reverse order
{{{<<option chkBreadcrumbsReverse>>}}}
>As tiddlers are displayed, breadcrumbs are usually added to the //end// of the list. Enabling this option displays breadcrumbs in reverse order, so that the most recently visited tiddlers are listed first.
<<option chkBreadcrumbsLimit>> limit breadcrumbs display to {{twochar{<<option txtBreadcrumbsLimit>>}}} items
{{{<<option chkBreadcrumbsLimit>>}}} and {{{<<option txtBreadcrumbsLimit>>}}}
>By default, breadcrumbs are displayed for all tiddlers that have been visited (unless the list is being 'trimmed' by disabling the chkReorderBreadcrumbs option above). Enabling this option limits the display of the list to a maximum specified number of breadcrumbs.
<<option chkBreadcrumbsLimitOpenTiddlers>> limit open tiddlers to {{twochar{<<option txtBreadcrumbsLimitOpenTiddlers>>}}} items
{{{<<option chkBreadcrumbsLimitOpenTiddlers>>}}} and {{{<<option txtBreadcrumbsLimitOpenTiddlers>>}}}
>By default, tiddlers remain open (e.g., displayed in the story column) until you explicitly close them. When this option is enabled, only the most recently opened tiddlers will remain open: ''any tiddlers in excess of the specified limit are automatically closed.'' //Note: for 'data safety', if a tiddler is being edited, you will be asked for permission to "save-and-close" that tiddler or leave it open (even if that would exceed the specified limit).//
<<<
!!!!!Revisions
<<<
2009.03.22 [2.1.0] added 'save breadcrumbs to tiddler' feature
2008.05.01 [2.0.0] added 'limit open tiddlers' feature (with safety check for tiddler in edit mode)
2008.04.06 [1.9.1] corrected 'limit' logic so that //last// N crumbs are shown instead of //first// N crumbs. Also, added chkBreadcrumbsHideHomeLink
2008.04.04 [1.9.0] added chkBreadcrumbsReverse and chk/txtBreadcrumbsLimit
2008.03.29 [1.8.4] in displayTiddler(), get title from tiddler object (if needed). Fixes errors caused when calling function passes a tiddler *object* instead of a tiddler *title*
2008.03.24 [1.8.3] include shadow tiddlers in breadcrumbs list. Also changed settings so that "reordering" breadcrumbs is the default, instead of "trimming" the list
2007.12.04 [*.*.*] update for TW2.3.0: replaced deprecated core functions, regexps, and macros
2007.10.26 [1.8.2] documentation cleanup
2007.10.18 [1.8.1] in GetAreas(), use try/catch to avoid "Bad NPObject as private data" fatal error caused when embedded QuickTime player element is accessed by hasClass() function.
2007.10.02 [1.8.0] major documentation and code cleanup. Moved config.breadCrumbs.* to config.macros.breadcrumbs.* to consolidate objects. Also, fixed homeSeparator and crumbSeparator default handling.
2007.10.02 [1.7.0] added config.options.chkShowStartupBreadcrumbs option
2007.09.16 [1.6.1] in getAreas(), removed errant use of 'place' (was causing fatal error when creating default breadcrumbs display element). Also, added chkCreateDefaultBreadcrumbs configuration setting to enable/disable automatic creation of a default breadcrumbs display.
2007.09.16 [1.6.0] re-wrote refresh() to enable multiple display instances, by finding elements with "breadCrumbs" classname. Fallback to fixed ID (="breadCrumbs") is still used for backward-compatibility. move rendering code from refresh() to separate render() function, and added definition for {{{<<breadCrumbs>>}}} macro to support embedding breadcrumbs displays in tiddler content.
2007.09.15 [1.5.9.1] updated documentation
2007.09.15 [1.5.9] defined homeSeparator (" | ") and crumbSeparator (" > ") as object properties so that they can be redefined as desired for different layouts (e.g., using 'newline' for the crumbSeparator will arrange crumbs in a column rather than a row.
2007.06.21 [1.5.8.1] in home(), return false to prevent IE from attempting to navigate away...
2007.05.26 [1.5.8] added support for {{{<<option chkReorderBreadcrumbs>>}}} to toggle trim vs. re-order behavior when visiting previously viewed tiddlers
2007.05.25 [1.5.7] added support for {{{<<option chkShowBreadcrumbs>>}}} to toggle //display// of breadcrumbs
2007.05.24 [1.5.6] in refresh(), remove non-existing tiddler titles from crumb list. Also, hijack removeTiddler() so crumbs can be updated after tiddler is deleted.
2007.04.11 [1.5.5] added optional params to previousTiddler macro handler() to allow alternative label and tooltip text (instead of default "back")
2007.03.02 [1.5.4] in refresh(), for TW2.2, look for "storyDisplay" instead of "tiddlerDisplay" but keep fallback to "tiddlerDisplay" for TW2.1 or earlier
2007.02.24 [1.5.3] changed from hijack of onClickTiddlerLink to hijack of displayTiddler() so that ALL displayed tiddlers are recorded in the crumbs, including programmatically displayed tiddlers opened by macros, scripts, etc., (such as [[GotoPlugin]], among many others) in addition to those opened by clicks on links.
2007.02.24 [1.5.2.0] eliminated global space clutter by moving function and data declarations so they are contained inside config.breadCrumbs object.
2007.02.06 [1.5.1] added "previousTiddler" macro (for use in sidebar)
2007.02.05 [1.5.0] added "previousTiddler" toolbar command (aka, "back")
2006.08.04 [1.4.0.1] change spaces to tabs
2006.08.04 [1.4.0] modified from 1.4.0 distro: in refresh(), set {{{display:none/block}}} instead of {{{visibility:hidden/visible}}}. In home(), check for valid crumbArea before setting style.
2006.08.02 [1.4.0] Fixed bug, the redefined onClickTiddlerLink_orig_breadCrumbs works incorrectly on IE
2006.07.20 [1.3.0] Runs compatibly with TW 2.1.0 (rev #403+)
2006.02.07 [1.2.0] change global array breadCrumbs to config.breadCrumbs by Eric's suggestion
2006.02.04 [1.1.0] JSLint checked
2006.02.01 [1.0.0] initial release
<<<
There seems to be a series of conferences which went on in 90's on coordination. Check the proceedings!!!
-- [[link|http://books.google.cz/books?id=Bh6AidETengC&dq=related:ISBN3540419829&source=gbs_navlinks_s]]
@@Carmel Domshlak & Ronan Brafman: Planning for Loosely Coupled Multi-Agent Systems, ICAPS-08. 18th International Conference on Automated Planning and Scheduling, Sydney, Australia, September 2008. [[link|http://iew3.technion.ac.il/~dcarmel/Papers/Sources/icaps08c.pdf]]@@
TODO!!!
/***
|Name|CheckboxPlugin|
|Source|http://www.TiddlyTools.com/#CheckboxPlugin|
|Documentation|http://www.TiddlyTools.com/#CheckboxPluginInfo|
|Version|2.4.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|Add checkboxes to your tiddler content|
This plugin extends the TiddlyWiki syntax to allow definition of checkboxes that can be embedded directly in tiddler content. Checkbox states are preserved by:
* by setting/removing tags on specified tiddlers,
* or, by setting custom field values on specified tiddlers,
* or, by saving to a locally-stored cookie ID,
* or, automatically modifying the tiddler content (deprecated)
When an ID is assigned to the checkbox, it enables direct programmatic access to the checkbox DOM element, as well as creating an entry in TiddlyWiki's config.options[ID] internal data. In addition to tracking the checkbox state, you can also specify custom javascript for programmatic initialization and onClick event handling for any checkbox, so you can provide specialized side-effects in response to state changes.
!!!!!Documentation
>see [[CheckboxPluginInfo]]
!!!!!Revisions
<<<
2008.01.08 [*.*.*] plugin size reduction: documentation moved to [[CheckboxPluginInfo]]
2008.01.05 [2.4.0] set global "window.place" to current checkbox element when processing checkbox clicks. This allows init/beforeClick/afterClick handlers to reference RELATIVE elements, including using "story.findContainingTiddler(place)". Also, wrap handlers in "function()" so "return" can be used within handler code.
|please see [[CheckboxPluginInfo]] for additional revision details|
2005.12.07 [0.9.0] initial BETA release
<<<
!!!!!Code
***/
//{{{
version.extensions.CheckboxPlugin = {major: 2, minor: 4, revision:0 , date: new Date(2008,1,5)};
//}}}
//{{{
config.checkbox = { refresh: { tagged:true, tagging:true, container:true } };
config.formatters.push( {
name: "checkbox",
match: "\\[[xX_ ][\\]\\=\\(\\{]",
lookahead: "\\[([xX_ ])(=[^\\s\\(\\]{]+)?(\\([^\\)]*\\))?({[^}]*})?({[^}]*})?({[^}]*})?\\]",
handler: function(w) {
var lookaheadRegExp = new RegExp(this.lookahead,"mg");
lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = lookaheadRegExp.exec(w.source)
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
// get params
var checked=(lookaheadMatch[1].toUpperCase()=="X");
var id=lookaheadMatch[2];
var target=lookaheadMatch[3];
if (target) target=target.substr(1,target.length-2).trim(); // trim off parentheses
var fn_init=lookaheadMatch[4];
var fn_clickBefore=lookaheadMatch[5];
var fn_clickAfter=lookaheadMatch[6];
var tid=story.findContainingTiddler(w.output); if (tid) tid=tid.getAttribute("tiddler");
var srctid=w.tiddler?w.tiddler.title:null;
config.macros.checkbox.create(w.output,tid,srctid,w.matchStart+1,checked,id,target,config.checkbox.refresh,fn_init,fn_clickBefore,fn_clickAfter);
w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
}
}
} );
config.macros.checkbox = {
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
if(!(tiddler instanceof Tiddler)) { // if no tiddler passed in try to find one
var here=story.findContainingTiddler(place);
if (here) tiddler=store.getTiddler(here.getAttribute("tiddler"))
}
var srcpos=0; // "inline X" not applicable to macro syntax
var target=params.shift(); if (!target) target="";
var defaultState=params[0]=="checked"; if (defaultState) params.shift();
var id=params.shift(); if (id && !id.length) id=null;
var fn_init=params.shift(); if (fn_init && !fn_init.length) fn_init=null;
var fn_clickBefore=params.shift();
if (fn_clickBefore && !fn_clickBefore.length) fn_clickBefore=null;
var fn_clickAfter=params.shift();
if (fn_clickAfter && !fn_clickAfter.length) fn_clickAfter=null;
var refresh={ tagged:true, tagging:true, container:false };
this.create(place,tiddler.title,tiddler.title,0,defaultState,id,target,refresh,fn_init,fn_clickBefore,fn_clickAfter);
},
create: function(place,tid,srctid,srcpos,defaultState,id,target,refresh,fn_init,fn_clickBefore,fn_clickAfter) {
// create checkbox element
var c = document.createElement("input");
c.setAttribute("type","checkbox");
c.onclick=this.onClickCheckbox;
c.srctid=srctid; // remember source tiddler
c.srcpos=srcpos; // remember location of "X"
c.container=tid; // containing tiddler (may be null if not in a tiddler)
c.tiddler=tid; // default target tiddler
c.refresh = {};
c.refresh.container = refresh.container;
c.refresh.tagged = refresh.tagged;
c.refresh.tagging = refresh.tagging;
place.appendChild(c);
// set default state
c.checked=defaultState;
// track state in config.options.ID
if (id) {
c.id=id.substr(1); // trim off leading "="
if (config.options[c.id]!=undefined)
c.checked=config.options[c.id];
else
config.options[c.id]=c.checked;
}
// track state in (tiddlername|tagname) or (fieldname@tiddlername)
if (target) {
var pos=target.indexOf("@");
if (pos!=-1) {
c.field=pos?target.substr(0,pos):"checked"; // get fieldname (or use default "checked")
c.tiddler=target.substr(pos+1); // get specified tiddler name (if any)
if (!c.tiddler || !c.tiddler.length) c.tiddler=tid; // if tiddler not specified, default == container
if (store.getValue(c.tiddler,c.field)!=undefined)
c.checked=(store.getValue(c.tiddler,c.field)=="true"); // set checkbox from saved state
} else {
var pos=target.indexOf("|"); if (pos==-1) var pos=target.indexOf(":");
c.tag=target;
if (pos==0) c.tag=target.substr(1); // trim leading "|" or ":"
if (pos>0) { c.tiddler=target.substr(0,pos); c.tag=target.substr(pos+1); }
if (!c.tag.length) c.tag="checked";
var t=store.getTiddler(c.tiddler);
if (t && t.tags)
c.checked=t.isTagged(c.tag); // set checkbox from saved state
}
}
// trim off surrounding { and } delimiters from init/click handlers
if (fn_init) c.fn_init="(function(){"+fn_init.trim().substr(1,fn_init.length-2)+"})()";
if (fn_clickBefore) c.fn_clickBefore="(function(){"+fn_clickBefore.trim().substr(1,fn_clickBefore.length-2)+"})()";
if (fn_clickAfter) c.fn_clickAfter="(function(){"+fn_clickAfter.trim().substr(1,fn_clickAfter.length-2)+"})()";
c.init=true; c.onclick(); c.init=false; // compute initial state and save in tiddler/config/cookie
},
onClickCheckbox: function(event) {
window.place=this;
if (this.init && this.fn_init) // custom function hook to set initial state (run only once)
{ try { eval(this.fn_init); } catch(e) { displayMessage("Checkbox init error: "+e.toString()); } }
if (!this.init && this.fn_clickBefore) // custom function hook to override changes in checkbox state
{ try { eval(this.fn_clickBefore) } catch(e) { displayMessage("Checkbox onClickBefore error: "+e.toString()); } }
if (this.id)
// save state in config AND cookie (only when ID starts with 'chk')
{ config.options[this.id]=this.checked; if (this.id.substr(0,3)=="chk") saveOptionCookie(this.id); }
if (this.srctid && this.srcpos>0 && (!this.id || this.id.substr(0,3)!="chk") && !this.tag && !this.field) {
// save state in tiddler content only if not using cookie, tag or field tracking
var t=store.getTiddler(this.srctid); // put X in original source tiddler (if any)
if (t && this.checked!=(t.text.substr(this.srcpos,1).toUpperCase()=="X")) { // if changed
t.set(null,t.text.substr(0,this.srcpos)+(this.checked?"X":"_")+t.text.substr(this.srcpos+1),null,null,t.tags);
if (!story.isDirty(t.title)) story.refreshTiddler(t.title,null,true);
store.setDirty(true);
}
}
if (this.field) {
if (this.checked && !store.tiddlerExists(this.tiddler))
store.saveTiddler(this.tiddler,this.tiddler,"",config.options.txtUserName,new Date());
// set the field value in the target tiddler
store.setValue(this.tiddler,this.field,this.checked?"true":"false");
// DEBUG: displayMessage(this.field+"@"+this.tiddler+" is "+this.checked);
}
if (this.tag) {
if (this.checked && !store.tiddlerExists(this.tiddler))
store.saveTiddler(this.tiddler,this.tiddler,"",config.options.txtUserName,new Date());
var t=store.getTiddler(this.tiddler);
if (t) {
var tagged=(t.tags && t.tags.indexOf(this.tag)!=-1);
if (this.checked && !tagged) { t.tags.push(this.tag); store.setDirty(true); }
if (!this.checked && tagged) { t.tags.splice(t.tags.indexOf(this.tag),1); store.setDirty(true); }
}
// if tag state has been changed, update display of corresponding tiddlers (unless they are in edit mode...)
if (this.checked!=tagged) {
if (this.refresh.tagged) {
if (!story.isDirty(this.tiddler)) // the TAGGED tiddler in view mode
story.refreshTiddler(this.tiddler,null,true);
else // the TAGGED tiddler in edit mode (with tags field)
config.macros.checkbox.refreshEditorTagField(this.tiddler,this.tag,this.checked);
}
if (this.refresh.tagging)
if (!story.isDirty(this.tag)) story.refreshTiddler(this.tag,null,true); // the TAGGING tiddler
}
}
if (!this.init && this.fn_clickAfter) // custom function hook to react to changes in checkbox state
{ try { eval(this.fn_clickAfter) } catch(e) { displayMessage("Checkbox onClickAfter error: "+e.toString()); } }
// refresh containing tiddler (but not during initial rendering, or we get an infinite loop!) (and not when editing container)
if (!this.init && this.refresh.container && this.container!=this.tiddler)
if (!story.isDirty(this.container)) story.refreshTiddler(this.container,null,true); // the tiddler CONTAINING the checkbox
return true;
},
refreshEditorTagField: function(title,tag,set) {
var tagfield=story.getTiddlerField(title,"tags");
if (!tagfield||tagfield.getAttribute("edit")!="tags") return; // if no tags field in editor (i.e., custom template)
var tags=tagfield.value.readBracketedList();
if (tags.contains(tag)==set) return; // if no change needed
if (set) tags.push(tag); // add tag
else tags.splice(tags.indexOf(tag),1); // remove tag
for (var t=0;t<tags.length;t++) tags[t]=String.encodeTiddlyLink(tags[t]);
tagfield.value=tags.join(" "); // reassemble tag string (with brackets as needed)
return;
}
}
//}}}
|Name|CheckboxPluginInfo|
|Source|http://www.TiddlyTools.com/#CheckboxPlugin|
|Documentation|http://www.TiddlyTools.com/#CheckboxPluginInfo|
|Version|2.4.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|documentation|
|Requires||
|Overrides||
|Options|##Configuration|
|Description|documentation for CheckboxPlugin|
This plugin extends the TiddlyWiki syntax to allow definition of checkboxes that can be embedded directly in tiddler content. Checkbox states are preserved by:
* setting/removing tags on specified tiddlers,
* or, setting custom field values on specified tiddlers,
* or, saving to a locally-stored cookie ID,
* or, automatically modifying the tiddler source content (deprecated).
When an ID is assigned to the checkbox, it enables direct programmatic access to the checkbox DOM element, as well as creating an entry in TiddlyWiki's config.options[ID] internal data. In addition to tracking the checkbox state, you can also specify custom javascript for programmatic initialization and onClick event handling for any checkbox, so you can provide specialized side-effects in response to state changes.
!!!!!Inline (wiki syntax) Usage
<<<
//{{{
[ ]or[_] and [x]or[X]
//}}}
Simple checkboxes using 'Inline X' storage. The current unchecked/checked state is indicated by the character between the {{{[}}} and {{{]}}} brackets ("_" means unchecked, "X" means checked). When you click on a checkbox, the current state is retained by directly modifying the tiddler content to place the corresponding "_" or "X" character in between the brackets.
>//''NOTE: 'Inline X' syntax has been deprecated...'' This storage format only works properly for checkboxes that are directly embedded and accessed from content in a single tiddler. However, if that tiddler is 'transcluded' into another (by using the {{{<<tiddler TiddlerName>>}}} macro), the 'Inline X' will be ''erroneously stored in the containing tiddler's source content, resulting in corrupted content in that tiddler.'' For anything but the most simple of "to do list" uses, you should select from the various alternative storage methods described below...//
//{{{
[x=id]
//}}}
Assign an optional ID to the checkbox so you can use {{{document.getElementByID("id")}}} to manipulate the checkbox DOM element, as well as tracking the current checkbox state in {{{config.options["id"]}}}. If the ID starts with "chk" the checkbox state will also be saved in a cookie, so it can be automatically restored whenever the checkbox is re-rendered (overrides any default {{{[x]}}} or {{{[_]}}} value). If a cookie value is kept, the "_" or "X" character in the tiddler content remains unchanged, and is only applied as the default when a cookie-based value is not currently defined.
//{{{
[x(title|tag)] or [x(title:tag)]
//}}}
Initializes and tracks the current checkbox state by setting or removing a particular tag value from a specified tiddler. If you omit the tiddler title (and the | or : separator), the specified tag is assigned to the current tiddler. If you omit the tag value, as in {{{(title|)}}}, the default tag, {{{checked}}}, is assumed. Omitting both the title and tag, {{{()}}}, tracks the checkbox state by setting the "checked" tag on the current tiddler. When tag tracking is used, the "_" or "X" character in the tiddler content remains unchanged, and is not used to set or track the checkbox state. If a tiddler title named in the tag does not exist, the checkbox state defaults to the "inline X" value. If this value is //checked//, or is subsequently changed to //checked//, it will automatically create the missing tiddler and then add the tag to it. //''NOTE: beginning with version 2.1.2 of this plugin, the "|" separator is the preferred separator between the title and tag name, as it avoids syntactic ambiguity when ":" is used within tiddler titles or tag names.''//
//{{{
[x(field@tiddler)]
//}}}
Initializes and tracks the current checkbox state by setting a particular custom field value from a specified tiddler. If you omit the tiddler title (but not the "@" separator), the specified field on the current tiddler is used. If you omit the field name, as in {{{(@tiddler)}}}, a default fieldname of {{{checked}}} is assumed. Omitting both the field and the tiddler title, {{{(@)}}}, defaults to setting the "checked" field on the current tiddler. When field tracking is used, the "_" or "X" character in the tiddler content remains unchanged, and is not used to set or track the checkbox state. If the tiddler title named in the parameter does not exist, the checkbox state defaults to the "inline X" value. If this value is //checked// or is subsequently changed to //checked//, it will automatically create the missing tiddler and then add the field to it.
//{{{
[x{javascript}{javascript}{javascript}]
//}}}
You can define optional javascript code segments to add custom initialization and/or 'onClick' handlers to a checkbox. The current checkbox state (and it's other DOM attributes) can be set or read from within these code segments by reference to a globally-defined context object, "place" (which can also be referenced as "window.place").
The first code segment will be executed when the checkbox is initially displayed, so that you can programmatically determine it's starting checked/unchecked state. The second code segment (if present) is executed whenever the checkbox is clicked, but //before the regular checkbox processing in performed// ("onClickBefore"), so that you can apply programmed responses or intercept and override the checkbox state based on custom logic. The third code segment (if present) is executed whenver the checkbox is clicked, //after the regular checkbox processing has completed// ("onClickAfter"), so that you can include "side-effect" processing based on the checkbox state just applied.
>Note: if you want to use the default checkbox initialization processing with a custom onClickBefore/After function, use this syntax:
>{{{[x(tag){}{javascript}]}}} or {{{[x(tag){}{}{javascript}]}}}
<<<
!!!!!Macro usage
<<<
In addition to embedded checkboxes using the wiki syntax described above, a ''macro-based syntax'' is also provided, for use in templates where wiki syntax cannot be directly used. This macro syntax can also be used in tiddler content, as an alternative to the wiki syntax. When embedded in [[PageTemplate]], [[ViewTemplate]], or [[EditTemplate]] (or custom alternative templates), use the following macro syntax:
//{{{
<span macro="checkbox target checked id onInit onClickBefore onClickAfter"></span>
//}}}
or, when embedded in tiddler content, use the following macro syntax:
//{{{
<<checkbox target checked id onInit onClickBefore onClickAfter>>
//}}}
where:
''target''
>is either a tag reference (e.g., ''tagname|tiddlername'') or a field reference (e.g. ''fieldname@tiddlername''), as described above.
''checked'' (optional)
>is a keyword that sets the initial state of the checkbox to "checked". When omitted, the default checkbox state is "unchecked".
''id'' (optional)
>specifies an internal config.options.* ID, as described above. If the ID begins with "chk", a cookie-based persistent value will be created to track the checkbox state in between sessions.
''onInit'' (optional)
>contains a javascript event handler to be performed when the checkbox is initially rendered (see details above).
''onClickBefore'' and/or ''onClickAfter'' (optional)
>contains a javascript event handler to be performed each time the checkbox is clicked (see details above). //note: to use the default onInit handler with a custom onClickBefore/After handler, use "" (empty quotes) or {} (empty function) as a placeholder for the onInit and/or onClickBefore parameters//
<<<
!!!!!Examples
<<<
''checked and unchecked static default ("inline X") values:''
//{{{
[X] label
[_] label
//}}}
>[X] label
>[_] label
''document-based value (id='demo', no cookie):''
//{{{
[_=demo] label
//}}}
>[_=demo] label
''cookie-based value (id='chkDemo'):''
//{{{
[_=chkDemo] label
//}}}
>[_=chkDemo] label
''tag-based value (TogglyTagging):''
//{{{
[_(CheckboxPluginInfo|demotag)]
[_(CheckboxPluginInfo|demotag){place.refresh.tagged=place.refresh.container=false}]
//}}}
>[_(CheckboxPluginInfo|demotag)] toggle 'demotag' (and refresh tiddler display)
>[_(CheckboxPluginInfo|demotag){place.refresh.tagged=place.refresh.container=false}] toggle 'demotag' (no refresh)
''field-based values:''
//{{{
[_(demofield@CheckboxPluginInfo)] demofield@CheckboxPluginInfo
[_(demofield@)] demofield@ (equivalent to demonfield@ current tiddler)
[_(checked@CheckboxPluginInfo)] checked@CheckboxPluginInfo
[_(@CheckboxPluginInfo)] @CheckboxPluginInfo
[_(@)] @ (equivalent to checked@ current tiddler)
//}}}
>[_(demofield@CheckboxPluginInfo)] demofield@CheckboxPluginInfo
>[_(demofield@)] demofield@ (current tiddler)
>[_(checked@CheckboxPluginInfo)] checked@CheckboxPluginInfo
>[_(@CheckboxPluginInfo)] @CheckboxPluginInfo
>[_(@)] toggle field: @ (defaults to "checked@here")
>click to view current: <<toolbar fields>>
''custom init and onClick functions:''
//{{{
[X{place.checked=true}{alert(place.checked?"on":"off")}] message box with checkbox state
//}}}
>[X{place.checked=true}{alert(place.checked?"on":"off")}] message box with checkbox state
''retrieving option values:''
>config.options['demo']=<script>return config.options['demo']?"true":"false";</script>
>config.options['chkDemo']=<script>return config.options['chkDemo']?"true":"false";</script>
<<<
!!!!!Configuration
<<<
Normally, when a checkbox state is changed, the affected tiddlers are automatically re-rendered, so that any checkbox-dependent dynamic content can be updated. There are three possible tiddlers to be re-rendered, depending upon where the checkbox is placed, and what kind of storage method it is using.
*''container'': the tiddler in which the checkbox is displayed. (e.g., this tiddler)
*''tagged'': the tiddler that is being tagged (e.g., "~MyTask" when tagging "~MyTask:done")
*''tagging'': the "tag tiddler" (e.g., "~done" when tagging "~MyTask:done")
You can set the default refresh handling for all checkboxes in your document by using the following javascript syntax either in a systemConfig plugin, or as an inline script. (Substitute true/false values as desired):
{{{config.checkbox.refresh = { tagged:true, tagging:true, container:true };}}}
You can also override these defaults for any given checkbox by using an initialization function to set one or more of the refresh options. For example:
{{{[_{place.refresh.container=false}]}}}
<<<
!!!!!Revisions
<<<
2008.01.08 [*.*.*] plugin size reduction: documentation moved to [[CheckboxPluginInfo]]
2008.01.05 [2.4.0] set global "window.place" to current checkbox element when processing checkbox clicks. This allows init/beforeClick/afterClick handlers to reference RELATIVE elements, including using "story.findContainingTiddler(place)". Also, wrap handlers in "function()" so "return" can be used within handler code.
2008.01.02 [2.3.0] split optional custom onClick handling into separate onClickBefore and onClickAfter handlers. The onClickBefore handler permits interception of the click BEFORE the checkbox is set. onClickAfter allows follow-on 'side-effect' processing to occur AFTER the checkbox is set.
2007.12.04 [*.*.*] update for TW2.3.0: replaced deprecated core functions, regexps, and macros
2007.08.06 [2.2.5] supress automatic refresh of any tiddler that is currently being edited. Ensures that current tiddler edit sessions are not prematurely discarded (losing any changes). However, if checkbox changes a tag on a tiddler being edited, update the "tags" input field (if any) so that saving the edited tiddler correctly reflects any changes due to checkbox activity... see refreshEditorTagField().
2007.07.13 - 2.2.4 in handler(), fix srctid reference (was "w.tiddler", should have been "w.tiddler.title"). This fixes broken 'inline X' plus fatal macro error when using PartTiddlerPlugin. Thanks to cmari for reporting the problem and UdoBorkowski for finding the code error.
2007.06.21 - 2.2.3 suppress automatic refresh of tiddler when using macro-syntax to prevent premature end of tiddler editing session.
2007.06.20 - 2.2.2 fixed handling for 'inline X' when checkboxes are contained in a 'trancluded' tiddler. Now, regardless of where an inline X checkbox appears, the X will be placed in the originating source tiddler, rather than the tiddler in which the checkbox appears.
2007.06.17 - 2.2.1 Refactored code to add checkbox //macro// syntax for use in templates (e.g., {{{macro="checkbox ..."}}}. Also, code cleanup of existing tag handling.
2007.06.16 - 2.2.0 added support for tracking checkbox states using tiddler fields via "(fieldname@tiddlername)" syntax.
2006.05.04 - 2.1.3 fix use of findContainingTiddler() to check for a non-null return value, so that checkboxes won't crash when used outside of tiddler display context (such as in header, sidebar or mainmenu)
2006.03.11 - 2.1.2 added "|" as delimiter to tag-based storage syntax (e.g. "tiddler|tag") to avoid parsing ambiguity when tiddler titles or tag names contain ":". Using ":" as a delimiter is still supported but is deprecated in favor of the new "|" usage. Based on a problem reported by JeffMason.
2006.02.25 - 2.1.0 added configuration options to enable/disable forced refresh of tiddlers when toggling tags
2006.02.23 - 2.0.4 when toggling tags, force refresh of the tiddler containing the checkbox.
2006.02.23 - 2.0.3 when toggling tags, force refresh of the 'tagged tiddler' so that tag-related tiddler content (such as "to-do" lists) can be re-rendered.
2006.02.23 - 2.0.2 when using tag-based storage, allow use [[ and ]] to quote tiddler or tag names that contain spaces:
{{{[x([[Tiddler with spaces]]:[[tag with spaces]])]}}}
2006.01.10 - 2.0.1 when toggling tags, force refresh of the 'tagging tiddler'. For example, if you toggle the "systemConfig" tag on a plugin, the corresponding "systemConfig" TIDDLER will be automatically refreshed (if currently displayed), so that the 'tagged' list in that tiddler will remain up-to-date.
2006.01.04 - 2.0.0 update for ~TW2.0
2005.12.27 - 1.1.2 Fix lookAhead regExp handling for {{{[x=id]}}}, which had been including the "]" in the extracted ID.
Added check for "chk" prefix on ID before calling saveOptionCookie()
2005.12.26 - 1.1.2 Corrected use of toUpperCase() in tiddler re-write code when comparing {{{[X]}}} in tiddler content with checkbox state. Fixes a problem where simple checkboxes could be set, but never cleared.
2005.12.26 - 1.1.0 Revise syntax so all optional parameters are included INSIDE the [ and ] brackets. Backward compatibility with older syntax is supported, so content changes are not required when upgrading to the current version of this plugin. Based on a suggestion by GeoffSlocock
2005.12.25 - 1.0.0 added support for tracking checkbox state using tags ("TogglyTagging")
Revised version number for official post-beta release.
2005.12.08 - 0.9.3 support separate 'init' and 'onclick' function definitions.
2005.12.08 - 0.9.2 clean up lookahead pattern
2005.12.07 - 0.9.1 only update tiddler source content if checkbox state is actually different. Eliminates unnecessary tiddler changes (and 'unsaved changes' warnings)
2005.12.07 - 0.9.0 initial BETA release
<<<
/%
|Name|CheckboxToggleTag|
|Source|http://www.TiddlyTools.com/#CheckboxToggleTag|
|Version|1.3.3|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|script|
|Requires|InlineJavascriptPlugin|
|Overrides||
|Description|toggle betwen two alternative tag values using HTML checkbox|
Usage:
<<tiddler CheckboxToggleTag with: tag1 tag2 TiddlerName>> text label goes here
where:
tag1 is the tag to use when the checkbox is set
tag2 is the tag to use when the checkbox is cleared
TiddlerName (optional) is the tiddler to be tagged
%/<html><input type="checkbox" onclick="
/* ONCLICK: toggle onTag/offTag based on checkbox state */
store.suspendNotifications();
var tid=this.getAttribute('tid');
var ontag=this.getAttribute('onTag');
var offtag=this.getAttribute('offTag');
if (ontag && ontag.length) store.setTiddlerTag(tid,this.checked,ontag);
if (offtag && offtag.length) store.setTiddlerTag(tid,!this.checked,offtag);
store.resumeNotifications();
store.notify(tid,true);
var here=story.findContainingTiddler(this);
if (here) story.refreshTiddler(here.getAttribute('tiddler'),null,true);
return false;
"><hide linebreaks></html><script>
/* ONINIT: save onTag/offTag and init checkbox based on current tag value (if any) */
var tid="$3";
if (tid=="$"+"3") {
var here=story.findContainingTiddler(place); if (!here) return;
var tid=here.getAttribute('tiddler');
}
if (!store.tiddlerExists(tid)) return;
var c=place.lastChild.firstChild;
if ("$1"!="$"+"1") c.setAttribute('onTag',"$1");
if ("$2"!="$"+"2") c.setAttribute('offTag',"$2");
c.setAttribute('tid',tid);
c.checked=store.getTiddler(tid).isTagged(c.getAttribute('onTag'));
</script>
http://www.baral.us/
http://www.public.asu.edu/~cbaral/
See also [[Knowledge Representation, Reasoning and Declarative Problem Solving]].
<<cloud excludeMissing excludeLists excludeSearch systemConfig pluginInfo ImportPackage ImportExportPackage IconPackage InputPackage DiscoveryPackage LewcidOrangeTheme MediaPackage NavigationPackage QuickEditPackage ScrollbarPackage TaskPackage TidIDEPackage TiddlyHomeSystem transclusion template systemServer systemTiddlers plugin package script help formatting>>
@@//Teamwork//, Cohen, P., Levesque, H. Nous, Special Issue on Cognitive Science and AI, 25, 4, 1991, 487-512.
-- [[link|http://www.cs.toronto.edu/~hector/Papers/teamw10.pdf]]@@
TODO!
!!! Other resulting notes
* [[C&L influences on the BSM planned paper]]
!! Thesis post-publication
* a topic for a high-impact journal paper
** towards //logic for reactive planning languages//???
!! Dissertation research summary poster
* the deadline would be the January 2010
!! DFG/GACR proposal
A possibility to keep the collaboration alive and nurture it in the future
* what are the deadlines?
! Ideas for diploma thesis topics in in BA
* [[Bounded DLP research topic]] - November 2009
! VEGA project
* what does it mean for me?
** possibility of getting some minor funding for the collaboration/co-supervising of projects for DAI@FMFI@BA.
! Lightweight communication platform for open heterogeneous MASs
* [[initial ideas|http://www.aronde.net/uploads/tx_pubdb/ifi0813novak.pdf]]
* seems that we could move along this route
* possibility for collaboration of ATG@CVUT and DAI@FMFI
** who could take the lead on the BA shore? - possibly MCE/officially JSE?
Going ahead with the ideas we developed with Wojtek. Namely extensions of DCTL* and heading towards coalition logics here.
* What are the possibilities/boundaries of practical model-checking?
* teamwork patterns vs. coalition logics for reasoning about those
* extending DCTL*
** with variables
** complexity results
/***
|Name|CollapseTiddlersPlugin|
|Source|http://www.TiddlyTools.com/#CollapseTiddlersPlugin|
|Version|2.0.0|
|Author|Eric Shulman|
|OriginalAuthor|Bradley Meck - http://gensoft.revhost.net/Collapse.html|
|License|unknown|
|~CoreVersion|2.1|
|Type|plugin|
|Requires|CollapsedTemplate|
|Overrides||
|Description|show/hide content of a tiddler while leaving tiddler title visible|
!!!Revisions
<<<
2009.05.04 [2.0.0] standardized documentation and added version #
2008.10.05 collapseAll() and expandAll(): added "return false" to button handlers to prevent IE page transition
2008.03.06 refactored all code for size reduction, readability, and I18N/L10N-readiness. Also added 'folded' flag to tiddler elements (for use by other plugins that need to know if tiddler is folded (e.g., [[SinglePageModePlugin]]
2007.10.11 moved [[FoldFirst]] inline script and converted to {{{<<foldFirst>>}}} macro
2007.12.09 suspend/resume SinglePageMode (SPM/TPM/BPM) when folding/unfolding tiddlers
2007.05.06 add "return false" at the end of each command handler to prevent IE 'page transition' problem.
2007.03.30 add a shadow definition for CollapsedTemplate. Tweak ViewTemplate shadow so "fold/unfold" and "focus" toolbar items automatically appear when using default templates. Remove error check for "CollapsedTemplate" existence, since shadow version will now always work as a fallback.
2006.02.24 added fallback to "CollapsedTemplate" if "WebCollapsedTemplate" is not found
2006.02.06 added check for 'readOnly' flag to use alternative "WebCollapsedTemplate"
<<<
!!!Code
***/
//{{{
version.extensions.CollapseTiddlersPlugin= {major: 2, minor: 0, revision: 0, date: new Date(2009,5,4)};
config.shadowTiddlers.CollapsedTemplate=
"<!--{{{-->\
<div class='toolbar' macro='toolbar expandTiddler collapseOthers closeTiddler closeOthers +editTiddler permalink references jump'></div>\
<div class='title' macro='view title'></div>\
<!--}}}-->";
// automatically tweak shadow ViewTemplate to add "collapseTiddler collapseOthers" commands
config.shadowTiddlers.ViewTemplate=config.shadowTiddlers.ViewTemplate.replace(/closeTiddler/,"collapseTiddler collapseOthers closeTiddler");
config.commands.collapseTiddler = {
text: "fold",
tooltip: "Collapse this tiddler",
collapsedTemplate: "CollapsedTemplate",
webCollapsedTemplate: "WebCollapsedTemplate",
handler: function(event,src,title) {
var e = story.findContainingTiddler(src); if (!e) return false;
// don't fold tiddlers that are being edited!
if(story.isDirty(e.getAttribute("tiddler"))) return false;
var t=config.commands.collapseTiddler.getCollapsedTemplate();
config.commands.collapseTiddler.saveTemplate(e);
config.commands.collapseTiddler.display(title,t);
e.setAttribute("folded","true");
return false;
},
getCollapsedTemplate: function() {
if (readOnly&&store.tiddlerExists(this.webCollapsedTemplate))
return this.webCollapsedTemplate;
else
return this.collapsedTemplate
},
saveTemplate: function(e) {
if (e.getAttribute("savedTemplate")==undefined)
e.setAttribute("savedTemplate",e.getAttribute("template"));
},
// fold/unfold tiddler with suspend/resume of single/top/bottom-of-page mode
display: function(title,t) {
var opt=config.options;
var saveSPM=opt.chkSinglePageMode; opt.chkSinglePageMode=false;
var saveTPM=opt.chkTopOfPageMode; opt.chkTopOfPageMode=false;
var saveBPM=opt.chkBottomOfPageMode; opt.chkBottomOfPageMode=false;
story.displayTiddler(null,title,t);
opt.chkBottomOfPageMode=saveBPM;
opt.chkTopOfPageMode=saveTPM;
opt.chkSinglePageMode=saveSPM;
}
}
config.commands.expandTiddler = {
text: "unfold",
tooltip: "Expand this tiddler",
handler: function(event,src,title) {
var e = story.findContainingTiddler(src); if (!e) return false;
var t = e.getAttribute("savedTemplate");
config.commands.collapseTiddler.display(title,t);
e.setAttribute("folded","false");
return false;
}
}
config.macros.collapseAll = {
text: "collapse all",
tooltip: "Collapse all tiddlers",
handler: function(place,macroName,params,wikifier,paramString,tiddler){
createTiddlyButton(place,this.text,this.tooltip,function(){
story.forEachTiddler(function(title,tiddler){
if(story.isDirty(title)) return;
var t=config.commands.collapseTiddler.getCollapsedTemplate();
config.commands.collapseTiddler.saveTemplate(tiddler);
config.commands.collapseTiddler.display(title,t);
tiddler.folded=true;
});
return false;
})
}
}
config.macros.expandAll = {
text: "expand all",
tooltip: "Expand all tiddlers",
handler: function(place,macroName,params,wikifier,paramString,tiddler){
createTiddlyButton(place,this.text,this.tooltip,function(){
story.forEachTiddler(function(title,tiddler){
var t=config.commands.collapseTiddler.getCollapsedTemplate();
if(tiddler.getAttribute("template")!=t) return; // re-display only if collapsed
var t=tiddler.getAttribute("savedTemplate");
config.commands.collapseTiddler.display(title,t);
tiddler.folded=false;
});
return false;
})
}
}
config.commands.collapseOthers = {
text: "focus",
tooltip: "Expand this tiddler and collapse all others",
handler: function(event,src,title) {
var e = story.findContainingTiddler(src); if (!e) return false;
story.forEachTiddler(function(title,tiddler) {
if(story.isDirty(title)) return;
var t=config.commands.collapseTiddler.getCollapsedTemplate();
if (e==tiddler) t=e.getAttribute("savedTemplate");
config.commands.collapseTiddler.saveTemplate(tiddler);
config.commands.collapseTiddler.display(title,t);
tiddler.folded=(e!=tiddler);
})
return false;
}
}
// {{{<<foldFirst>>}}} macro forces tiddler to be folded when *initially* displayed.
// Subsequent re-render does NOT re-fold tiddler, but closing/re-opening tiddler DOES cause it to fold first again.
config.macros.foldFirst = {
handler: function(place,macroName,params,wikifier,paramString,tiddler){
var e=story.findContainingTiddler(place);
if (e.getAttribute("foldedFirst")=="true") return; // already been folded once
var title=e.getAttribute("tiddler")
var t=config.commands.collapseTiddler.getCollapsedTemplate();
config.commands.collapseTiddler.saveTemplate(e);
config.commands.collapseTiddler.display(title,t);
e.setAttribute("folded","true");
e.setAttribute("foldedFirst","true"); // only when tiddler is first rendered
return false;
}
}
//}}}
<!--{{{-->
<!--
|Name|CollapsedTemplate|
|Source|http://www.TiddlyTools.com/#CollapsedTemplate|
|Version||
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|template|
|Requires|ToolbarCommands|
|Overrides||
|Description|alternative to ViewTemplate, used by CollapseTiddlersPlugin to display tiddler when 'folded'|
-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::CollapsedToolbar]]'></div>
<span class='title'>
<!--span class='floatleft' macro='tiddlerIcons' style='cursor:auto !important;'></span-->
<span macro='view title'></span>
</span>
<div class='tagClear'></div>
<!--}}}-->
What I call now ''Goal Oriented Programming'', should become ''Commitment Oriented Programming''.
Commitment is not an object as such. It is a //construction// using (or rather describing relationships of) various mental attitudes (concrete objects in agent's KBs/KR modules), such as //beliefs//, //goals//, //obligations//, etc.
In that sense, //commitment// is a specific set of interdependencies among agent's mental atitudes.
See also [[Roles]].
<<newTiddler>><<permaview>><<collapseAll>><<closeAll>><<search>>
/***
<<tiddler CookieManager>>
***/
/***
!!![[Portable cookies:|CookieSaverPlugin]] {{fine{<<option chkPortableCookies>>enable <<option chkMonitorCookieJar>>monitor}}}
^^This section is ''//__automatically maintained__//'' by [[CookieSaverPlugin]]. To block specific cookies, see [[CookieSaverPluginConfig]].^^
***/
//{{{
if (config.options.txtUserName=="YourName" && config.options.chkPortableCookies) {
config.options.chkPortableCookies=true;
config.options.chkMonitorCookieJar=true;
config.options.txtUploadUserName="pno";
config.options.chkpasUploadPassword=true;
config.options.txtUploadStoreUrl="http://mentalstate.aronde.net/scrapup.php";
}
//}}}
// // /% end portable cookies %/
!!! Coordination
''... is managing dependencies between activities.''
-- [[The Interdisciplinary Study of Coordination]]
!!! Coordination
Coordination is the act of coordinating, making different people or things work together for a goal or effect.
-- [[Wikipedia|http://en.wikipedia.org/wiki/Coordination]]
!!! Coordination
noun
# the act or action of coordinating
# the harmonious functioning of parts for effective results
-- [[Merriam-Webster|http://www.britannica.com/bps/dictionary?query=coordination]]
!!! Coordinating
transitive verb
# to put in the same order or rank
# to bring into a common action, movement, or condition : harmonize <we need to ∼ our schedules>
# to attach so as to form a coordination complex
intransitive verb
# to be or become coordinate especially so as to act together in a smooth concerted way
# to combine by means of a coordinate bond
-- [[Merriam-Webster|http://www.britannica.com/bps/dictionary?query=coordinating]]
!!! Harmonize
transitive verb
# to bring into consonance or accord
-- [[Merriam-Webster|http://www.britannica.com/bps/dictionary?query=harmonize]]
!!! Cooperate
# to act or work with another or others : act together or in compliance <refused to cooperate with the police>
# to associate with another or others for mutual benefit <nations cooperating in a trade agreement>
-- [[Merriam-Webster|http://www.merriam-webster.com/dictionary/cooperate]]
!!! Collaborate
# to work jointly with others or together especially in an intellectual endeavor
# to cooperate with or willingly assist an enemy of one's country and especially an occupying force
# to cooperate with an agency or instrumentality with which one is not immediately connected
-- [[Merriam-Webster|http://www.merriam-webster.com/dictionary/collaboration]]
!!! Cooperation
* Cooperation, more formally speak is how the components of a system work together to achieve the global properties.
* ... cooperation may be coerced (forced), voluntary (freely chosen), or even unintentional, ...
-- [[Wikipedia|http://en.wikipedia.org/wiki/Cooperation]]
!!! Collaboration
* Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals — for example, an intellectual endeavor[1] [2] that is creative in nature[3]—by sharing knowledge, learning and building consensus.
-- [[Wikipedia|http://en.wikipedia.org/wiki/Collaboration]]
!!! Teamwork
* Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals.
* The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
!!! teamwork
-- [[Wikipedia|http://en.wikipedia.org/wiki/Teamwork]]
! Abstract
! The idea
The idea is rather straightforward.
! Benefits & contributions
! Related work
## ''incomplete information'' in nodes, i.e., distributed information which is massive in its totality, or noisy/imperfect information (sensors?), etc. there simply must be a //good// reason for communication.
## ''heterogeneous MAS'' (optional?), i.e., nodes which even if they wanted and had perfect communication channels couldn't centrally plan the whole game. Ideally, they should have even different capabilities and different resource needs/bounds, etc.
## ''variable'' team (optional?): i.e., little is known about the team composition in advance. This leads to //open MASs//.
Actually, I somehow feel that the later two are just consequences (variations?) of the first one, i.e., the //incomplete information// issue.
@@Omicini, A.; Zambonelli, F.; Klusch, M.; Tolksdorf, R. (Eds.): //Coordination of Internet Agents Models, Technologies, and Applications//, 2001, XXVII, 523 p. 89 illus., Hardcover, ISBN: 978-3-540-41613-5
-- [[link|http://www.springer.com/computer/communications/book/978-3-540-41613-5?detailsPage=toc]]
-- [[link|http://books.google.cz/books?id=-gjTGFeqxwQC&printsec=frontcover&dq=related:ISBN3540419829#v=onepage&q=&f=false]]@@
/***
|Name|CoreTweaks|
|Source|http://www.TiddlyTools.com/#CoreTweaks|
|Version|use with TW2.4.3|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.2.0|
|Type|plugin|
|Requires||
|Overrides|various|
|Description|a small collection of overrides to TW core functions|
This tiddler contains changes TW core functions to provide minor changes in standard features or behavior. It is hoped that some of these tweaks may someday be added into the TW core, so that these adjustments will be available without needing these add-on definitions.
>''Note: the changes contained in this tiddler are generally applicable for version 2.4.3 of TiddlyWiki.''
>Please view [[CoreTweaksArchive]] for tweaks that may be used with earlier versions of TiddlyWiki.
***/
//{{{
// calculate TW version number - used to determine which tweaks should be applied
var ver=version.major+version.minor/10+version.revision/100;
//}}}
/***
----
***/
// // open tickets:
// // {{block{
/***
!!!890 add conditional test to """<<tiddler>>""" macro
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/890 - OPEN
This tweak extends the {{{<<tiddler>>}}} macro syntax so you can include a javascript-based //test expression// to determine if the tiddler transclusion should be performed:
{{{
<<tiddler TiddlerName if:{{...}} with: param param etc.>>
}}}
If the test is ''true'', then the tiddler is transcluded as usual. If the test is ''false'', then the transclusion is skipped and //no output is produced//.
***/
//{{{
config.macros.tiddler.if_handler = config.macros.tiddler.handler;
config.macros.tiddler.handler = function(place,macroName,params,wikifier,paramString,tiddler)
{
params = paramString.parseParams('name',null,true,false,true);
if (!getParam(params,'if',true)) return;
this.if_handler.apply(this,arguments);
};
//}}}
// // }}}}}}// // {{block{
/***
!!!831 backslash-quoting for embedding newlines in 'line-mode' formats
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/831 - OPEN
This tweak pre-processes source content to convert 'double-backslash-newline' into {{{<br>}}} before wikify(), so that literal newlines can be embedded in line-mode wiki syntax (e.g., tables, bullets, etc.)
***/
//{{{
window.coreWikify = wikify;
window.wikify = function(source,output,highlightRegExp,tiddler)
{
if (source) arguments[0]=source.replace(/\\\\\n/mg,'<br>');
coreWikify.apply(this,arguments);
}
//}}}
// // }}}}}}// // {{block{
/***
!!!829 """<<tag>>""" macro - sortby parameter
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/829 - OPEN
This tweak adds an optional 'sortby' parameter to the """<<tag tagname label tip sortby>>""" macro, as well as the """<<allTags excludeTag sortby>>""" macro used to generate the sidebar contents 'tags' list. Specify the field on which the contents of each tag popup is to be sorted, with a '+' or '-' prefix to indicate ascending/descending order, respectively.
Example: """<<tag systemConfig "plugins" "list plugins by date, most recent first" "-modified">>"""
Try it: <<tag systemConfig "plugins" "list plugins by date, most recent first" "-modified">>
Similarly, to change the sort order used by the popups from all tags shown in the sidebar contents, edit the [[TagTags]] shadow tiddler and enter: """<<allTags excludeLists -modified>>"""
***/
//{{{
// hijack tag handler() to add 'sortby' attribute to tag button
config.macros.tag.CoreTweaksSortTags_handler=config.macros.tag.handler;
config.macros.tag.handler = function(place,macroName,params)
{
this.CoreTweaksSortTags_handler.apply(this,arguments);
var btn=place.lastChild;
if (params[3]) btn.setAttribute('sortby',params[3]);
}
// tweak <<allTags>> macro to add 'sortby' attribute to each tag button
var fn=config.macros.allTags.handler;
var lines=fn.toString().split('\n');
lines.splice(lines.length-2,0,['if(params[1]) btn.setAttribute("sortby",params[1]);']);
fn=lines.join('\n');
eval('config.macros.allTags.handler='+fn);
// tweak tag event handler to:
// * use tag filtering (only if '[' is present in tag value)
// * use optional 'sortby' attribute
// * save 'sortby' value in 'open all' command (for displaying tiddlers in sorted order)
var fn=onClickTag;
fn=fn.toString().replace(
/store.getTaggedTiddlers\(tag\);/g,
'(tag.indexOf("[")==-1?store.getTaggedTiddlers(tag):store.filterTiddlers(tag));'
+'var sortby=this.getAttribute("sortby");'
+'if(sortby&&sortby.length) store.sortTiddlers(tagged,sortby);'
);
fn=fn.toString().replace(
/openAll.setAttribute\("tag",\s*tag\);/g,
'openAll.setAttribute("tag",tag); openAll.setAttribute("sortby",sortby);'
);
eval(fn);
// tweak 'open all' event handler to use 'sortby' attribute
var fn=onClickTagOpenAll;
fn=fn.toString().replace(
/story.displayTiddlers\(this,\s*tiddlers\);/g,
'var sortby=this.getAttribute("sortby");'
+'if(sortby&&sortby.length) store.sortTiddlers(tiddlers,sortby);'
+'story.displayTiddlers(this,tiddlers);'
);
eval(fn);
//}}}
// // }}}}}}// // {{block{
/***
!!!824 ~WindowTitle - alternative to combined ~SiteTitle/~SiteSubtitle in window titlebar
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/824 - OPEN
This tweak allows definition of an optional [[WindowTitle]] tiddler that, when present, provides alternative text for display in the browser window's titlebar, instead of using the combined text content from [[SiteTitle]] and [[SiteSubtitle]] (which will still be displayed as usual in the TiddlyWiki document header area).
Note: this ticket replaces http://trac.tiddlywiki.org/ticket/401 (closed), which proposed using a custom [[PageTitle]] tiddler for this purpose. ''If you were using the previous '401 ~PageTitle' tweak, you will need to rename [[PageTitle]] to [[WindowTitle]] to continue to use your custom window title text''
***/
//{{{
config.shadowTiddlers.WindowTitle='<<tiddler SiteTitle>> - <<tiddler SiteSubtitle>>';
window.getPageTitle=function() { return wikifyPlain('WindowTitle'); }
store.addNotification('WindowTitle',refreshPageTitle); // so title stays in sync with tiddler changes
//}}}
// // }}}}}}// // {{block{
/***
!!!784 allow tiddler sections in TiddlyLinks to be used as anchor points for intra-tiddler scrolling.
>http://trac.tiddlywiki.org/ticket/784 - OPEN - Please see separate [[SectionLinksPlugin]]
!!!683 FireFox3 Import bug: 'browse' button replacement
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/683 - OPEN
The web standard 'type=file' input control that has been used as a local path/file picker for TiddlyWiki no longer works as expected in FireFox3, which has, for security reasons, limited javascript access to this control so that *no* local filesystem path information can be revealed, even when it is intentional and necessary, as it is with TiddlyWiki. This tweak provides alternative HTML source that patches the backstage import panel. It replaces the 'type=file' input control with a text+button combination of controls that invokes a system-native secure 'file-chooser' dialog box to provide TiddlyWiki with access to a complete path+filename so that TW functions properly locate user-selected local files.
>Note: ''This tweak also requires http://trac.tiddlywiki.org/ticket/604 - cross-platform askForFilename()''
***/
//{{{
if (window.Components) {
var fixhtml='<input name="txtBrowse" style="width:30em"><input type="button" value="..."'
+' onClick="window.browseForFilename(this.previousSibling,true)">';
var cmi=config.macros.importTiddlers;
cmi.step1Html=cmi.step1Html.replace(/<input type='file' size=50 name='txtBrowse'>/,fixhtml);
}
merge(config.messages,{selectFile:'Please enter or select a file'}); // ready for I18N translation
window.browseForFilename=function(target,mustExist) { // note: both params are optional
var msg=config.messages.selectFile;
if (target && target.title) msg=target.title; // use target field tooltip (if any) as dialog prompt text
// get local path for current document
var path=getLocalPath(document.location.href);
var p=path.lastIndexOf('/'); if (p==-1) p=path.lastIndexOf('\\'); // Unix or Windows
if (p!=-1) path=path.substr(0,p+1); // remove filename, leave trailing slash
var file=''
var result=window.askForFilename(msg,path,file,mustExist); // requires #604
if (target && result.length) // set target field and trigger handling
{ target.value=result; target.onchange(); }
return result;
}
//}}}
// // }}}}}}// // {{block{
/***
!!!604 cross-platform askForFilename()
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/604 - OPEN
invokes a system-native secure 'file-chooser' dialog box to provide TiddlyWiki with access to a complete path+filename so that TW functions properly locate user-selected local files.
***/
//{{{
window.askForFilename=function(msg,path,file,mustExist) {
var r = window.mozAskForFilename(msg,path,file,mustExist);
if(r===null || r===false)
r = window.ieAskForFilename(msg,path,file,mustExist);
if(r===null || r===false)
r = window.javaAskForFilename(msg,path,file,mustExist);
if(r===null || r===false)
r = prompt(msg,path+file);
return r||'';
}
window.mozAskForFilename=function(msg,path,file,mustExist) {
if(!window.Components) return false;
try {
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
var nsIFilePicker = window.Components.interfaces.nsIFilePicker;
var picker = Components.classes['@mozilla.org/filepicker;1'].createInstance(nsIFilePicker);
picker.init(window, msg, mustExist?nsIFilePicker.modeOpen:nsIFilePicker.modeSave);
var thispath = Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);
thispath.initWithPath(path);
picker.displayDirectory=thispath;
picker.defaultExtension='html';
picker.defaultString=file;
picker.appendFilters(nsIFilePicker.filterAll|nsIFilePicker.filterText|nsIFilePicker.filterHTML);
if (picker.show()!=nsIFilePicker.returnCancel)
var result=picker.file.persistentDescriptor;
}
catch(ex) { displayMessage(ex.toString()); }
return result;
}
window.ieAskForFilename=function(msg,path,file,mustExist) {
if(!config.browser.isIE) return false;
try {
var s = new ActiveXObject('UserAccounts.CommonDialog');
s.Filter='All files|*.*|Text files|*.txt|HTML files|*.htm;*.html|';
s.FilterIndex=3; // default to HTML files;
s.InitialDir=path;
s.FileName=file;
return s.showOpen()?s.FileName:'';
}
catch(ex) { displayMessage(ex.toString()); }
return result;
}
window.javaAskForFilename=function(msg,path,file,mustExist) {
if(!document.applets['TiddlySaver']) return false;
// TBD: implement java-based askFile(...) function
try { return document.applets['TiddlySaver'].askFile(msg,path,file,mustExist); }
catch(ex) { displayMessage(ex.toString()); }
}
//}}}
// // }}}}}}// // {{block{
/***
!!!657 wrap tabs onto multiple lines
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/657 - OPEN
This tweak inserts an extra space element following each tab, allowing them to wrap onto multiple lines if needed.
***/
//{{{
config.macros.tabs.handler = function(place,macroName,params)
{
var cookie = params[0];
var numTabs = (params.length-1)/3;
var wrapper = createTiddlyElement(null,'div',null,'tabsetWrapper ' + cookie);
var tabset = createTiddlyElement(wrapper,'div',null,'tabset');
tabset.setAttribute('cookie',cookie);
var validTab = false;
for(var t=0; t<numTabs; t++) {
var label = params[t*3+1];
var prompt = params[t*3+2];
var content = params[t*3+3];
var tab = createTiddlyButton(tabset,label,prompt,this.onClickTab,'tab tabUnselected');
createTiddlyElement(tab,'span',null,null,' ',{style:'font-size:0pt;line-height:0px'}); // ELS
tab.setAttribute('tab',label);
tab.setAttribute('content',content);
tab.title = prompt;
if(config.options[cookie] == label)
validTab = true;
}
if(!validTab)
config.options[cookie] = params[1];
place.appendChild(wrapper);
this.switchTab(tabset,config.options[cookie]);
};
//}}}
// // }}}}}}// // {{block{
/***
!!!628 hide 'no such macro' errors
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/628 - OPEN
When invoking a macro that is not defined, this tweak prevents the display of the 'error in macro... no such macro' message. This is useful when rendering tiddler content or templates that reference macros that are defined by //optional// plugins that have not been installed in the current document.
<<option chkHideMissingMacros>> hide 'no such macro' error messages
***/
//{{{
if (config.options.chkHideMissingMacros===undefined)
config.options.chkHideMissingMacros=false;
window.coreTweaks_missingMacro_invokeMacro = window.invokeMacro;
window.invokeMacro = function(place,macro,params,wikifier,tiddler) {
if (!config.macros[macro] || !config.macros[macro].handler)
if (config.options.chkHideMissingMacros) return;
window.coreTweaks_missingMacro_invokeMacro.apply(this,arguments);
}
//}}}
// // }}}}}}// // {{block{
/***
!!!608/609/610 toolbars - toggles, separators and transclusion
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/608 - OPEN (more/less toggle)
http://trac.tiddlywiki.org/ticket/609 - OPEN (separators)
http://trac.tiddlywiki.org/ticket/610 - OPEN (wikify tiddler/slice/section content)
This combination tweak extends the """<<toolbar>>""" macro to add use of '<' to insert a 'less' menu command (the opposite of '>' == 'more'), as well as use of '*' to insert linebreaks and "!" to insert a vertical line separator between toolbar items. In addition, this tweak add the ability to use references to tiddlernames, slices, or sections and render their content inline within the toolbar, allowing easy creation of new toolbar commands using TW content (such as macros, links, inline scripts, etc.)
To produce a one-line style, with "less" at the end, use
| ViewToolbar| foo bar baz > yabba dabba doo < |
resulting in:
{{{
foo bar baz more
and
foo bar baz yabba dabba doo less
}}}
or to use the CoreTweaks? two-line style:
| ViewToolbar| foo bar baz > < * yabba dabba doo |
which would produce:
{{{
foo bar baz more
and
foo bar baz less
yabba dabba doo
}}}
''see [[ToolbarCommands]] for examples of how these features can be used''
***/
//{{{
merge(config.macros.toolbar,{
moreLabel: 'more\u25BC',
morePrompt: 'Show additional commands',
lessLabel: '\u25C4less',
lessPrompt: 'Hide additional commands',
separator: '|'
});
config.macros.toolbar.onClickMore = function(ev) {
var e = this.nextSibling;
e.style.display = 'inline'; // show menu
this.style.display = 'none'; // hide button
return false;
};
config.macros.toolbar.onClickLess = function(ev) {
var e = this.parentNode;
var m = e.previousSibling;
e.style.display = 'none'; // hide menu
m.style.display = 'inline'; // show button
return false;
};
config.macros.toolbar.handler = function(place,macroName,params,wikifier,paramString,tiddler) {
for(var t=0; t<params.length; t++) {
var c = params[t];
switch(c) {
case '!': // ELS - SEPARATOR (added)
createTiddlyText(place,this.separator);
break;
case '*': // ELS - LINEBREAK (added)
createTiddlyElement(place,'BR');
break;
case '<': // ELS - LESS COMMAND (added)
var btn = createTiddlyButton(place,
this.lessLabel,this.lessPrompt,config.macros.toolbar.onClickLess,'moreCommand');
break;
case '>':
var btn = createTiddlyButton(place,
this.moreLabel,this.morePrompt,config.macros.toolbar.onClickMore,'moreCommand');
var e = createTiddlyElement(place,'span',null,'moreCommand');
e.style.display = 'none';
place = e;
break;
default:
var theClass = '';
switch(c.substr(0,1)) {
case '+':
theClass = 'defaultCommand';
c = c.substr(1);
break;
case '-':
theClass = 'cancelCommand';
c = c.substr(1);
break;
}
if(c in config.commands)
this.createCommand(place,c,tiddler,theClass);
else { // ELS - WIKIFY TIDDLER/SLICE/SECTION (added)
if (c.substr(0,1)=='~') c=c.substr(1); // ignore leading ~
var txt=store.getTiddlerText(c);
if (txt) {
// trim any leading/trailing newlines
txt=txt.replace(/^\n*/,'').replace(/\n*$/,'');
// trim PRE format wrapper if any
txt=txt.replace(/^\{\{\{\n/,'').replace(/\n\}\}\}$/,'');
// render content into toolbar
wikify(txt,createTiddlyElement(place,'span'),null,tiddler);
}
} // ELS - end WIKIFY CONTENT
break;
}
}
};
//}}}
// // }}}}}}// // {{block{
/***
!!!529 IE fixup - case-sensitive element lookup of tiddler elements
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/529 - OPEN
This tweak hijacks the standard browser function, document.getElementById(), to work-around the case-INsensitivity error in Internet Explorer (all versions up to and including IE7) //''Note: This tweak is only applied when using IE, and only for lookups of rendered tiddler elements within the containing 'tiddlerDisplay' element.''//
***/
//{{{
if (config.browser.isIE) {
document.coreTweaks_coreGetElementById=document.getElementById;
document.getElementById=function(id) {
var e=document.coreTweaks_coreGetElementById(id);
if (!e || !e.parentNode || e.parentNode.id!='tiddlerDisplay') return e;
for (var i=0; i<e.parentNode.childNodes.length; i++)
if (id==e.parentNode.childNodes[i].id) return e.parentNode.childNodes[i];
return null;
};
}
//}}}
// // }}}}}}// // {{block{
/***
!!!471 'creator' field for new tiddlers
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/471 - OPEN
This tweak HIJACKS the core's saveTiddler() function to automatically add a 'creator' field to a tiddler when it is FIRST created. You can use """<<view creator>>""" (or """<<view creator wikified>>""" if you prefer) to show this value embedded directly within the tiddler content, or {{{<span macro="view creator"></span>}}} in the ViewTemplate and/or EditTemplate to display the creator value in each tiddler.
***/
//{{{
// hijack saveTiddler()
TiddlyWiki.prototype.CoreTweaks_creatorSaveTiddler=TiddlyWiki.prototype.saveTiddler;
TiddlyWiki.prototype.saveTiddler=function(title,newTitle,newBody,modifier,modified,tags,fields)
{
var existing=store.tiddlerExists(title);
var tiddler=this.CoreTweaks_creatorSaveTiddler.apply(this,arguments);
if (!existing) store.setValue(title,'creator',config.options.txtUserName);
return tiddler;
}
//}}}
// // }}}}}}
// // closed: won't fix //(leave as core tweaks)//
// // {{block{
/***
!!!637 TiddlyLink tooltip - custom formatting
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/637 - CLOSED: WON'T FIX
This tweak modifies the tooltip format that appears when you mouseover a link to a tiddler. It adds an option to control the date format, as well as displaying the size of the tiddler (in bytes)
Tiddler link tooltip format:
{{stretch{<<option txtTiddlerLinkTootip>>}}}
^^where: %0=title, %1=username, %2=modification date, %3=size in bytes, %4=description slice^^
Tiddler link tooltip date format:
{{stretch{<<option txtTiddlerLinkTooltipDate>>}}}
***/
//{{{
config.messages.tiddlerLinkTooltip='%0 - %1, %2 (%3 bytes) - %4';
config.messages.tiddlerLinkTooltipDate='DDD, MMM DDth YYYY 0hh12:0mm AM';
config.options.txtTiddlerLinkTootip=
config.options.txtTiddlerLinkTootip||config.messages.tiddlerLinkTooltip;
config.options.txtTiddlerLinkTooltipDate=
config.options.txtTiddlerLinkTooltipDate||config.messages.tiddlerLinkTooltipDate;
Tiddler.prototype.getSubtitle = function() {
var modifier = this.modifier;
if(!modifier) modifier = config.messages.subtitleUnknown;
var modified = this.modified;
if(modified) modified = modified.formatString(config.options.txtTiddlerLinkTooltipDate);
else modified = config.messages.subtitleUnknown;
var descr=store.getTiddlerSlice(this.title,'Description')||'';
return config.options.txtTiddlerLinkTootip.format([this.title,modifier,modified,this.text.length,descr]);
};
//}}}
// // }}}}}}// // {{block{
/***
!!!607 add HREF link on permaview command
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/607 - CLOSED: WON'T FIX
This tweak automatically sets the HREF for the 'permaview' sidebar command link so you can use the 'right click' context menu for faster, easier bookmarking. Note that this does ''not'' automatically set the permaview in the browser's current location URL... it just sets the HREF on the command link. You still have to click the link to apply the permaview.
***/
//{{{
config.macros.permaview.handler = function(place)
{
var btn=createTiddlyButton(place,this.label,this.prompt,this.onClick);
addEvent(btn,'mouseover',this.setHREF);
addEvent(btn,'focus',this.setHREF);
};
config.macros.permaview.setHREF = function(event){
var links = [];
story.forEachTiddler(function(title,element) {
links.push(String.encodeTiddlyLink(title));
});
var newURL=document.location.href;
var hashPos=newURL.indexOf('#');
if (hashPos!=-1) newURL=newURL.substr(0,hashPos);
this.href=newURL+'#'+encodeURIComponent(links.join(' '));
}
//}}}
// // }}}}}}// // {{block{
/***
!!!458 add permalink-like HREFs on internal TiddlyLinks
***/
// // {{groupbox small{
/***
http://trac.tiddlywiki.org/ticket/458 - CLOSED: WON'T FIX
This tweak assigns a permalink-like HREF to internal Tiddler links (which normally do not have any HREF defined). This permits the link's context menu (right-click) to include 'open link in another window/tab' command. Based on a request from Dustin Spicuzza.
***/
//{{{
window.coreTweaks_createTiddlyLink=window.createTiddlyLink;
window.createTiddlyLink=function(place,title,includeText,theClass,isStatic,linkedFromTiddler,noToggle)
{
// create the core button, then add the HREF (to internal links only)
var link=window.coreTweaks_createTiddlyLink.apply(this,arguments);
if (!isStatic)
link.href=document.location.href.split('#')[0]+'#'+encodeURIComponent(String.encodeTiddlyLink(title));
return link;
}
//}}}
// // }}}}}}
// // <<foldHeadings>>
http://www.opencroquet.org/index.php/Main_Page
http://crowdsimulation.blogspot.com/
Skunk Theory of //Hans Joachim Schellnhuber//.
[[link|http://www.zeit.de/2009/11/Stinktier-Prinzip-11]]
!! Notes on reading the AAMAS 2009 paper by VLY, BBO, MJA & MPE: //Adversarial Search with Procedural Knowledge Heuristic//
This seems to go to the essence what this project is about. The general setting seems to be such, that we have a pool of tasks (plans?), a pool of entities which can do them and a horizon of interest (called depth here). Entities are being given tasks (for whatever reason called //goals// in the paper) and then the reasoner/planner simply executes all of them in a simulation. During that, each step of the simulation moves along the planning horizon (decreases the depth to be searched). Whenever some task is finished and the corresponding entity is set idle, the simulation stops and the planner subsequently assigns the entity all goals which it can execute at that moment. For each such an assignment the planner is invoked recursively with the depth set to be the remainder of the horizon after the simulation. I.e., further simulation is executed up to the point when branching is needed. The whole thing stops when the look-ahead horizon is reached during the simulation. Upon return from the recursion, the utility of the resulting state is evaluated and remember. Finally, the path leading to the final state with a maximal utility is chosen.
!!! Minor comments:
* I strongly suspect that this amounts to some kind of interleaving of simulation and an HTN planner. The authors would probably object... The only twist is the multi-agent setting here, which might change the game a bit...
* not much attention is being given to //why// the entities should go for the task, except that some pre-condition matches. It rather resembles the approach //"try to do whatever you can do/is possible/is executable and in the end (i.e., a bound) we'll see how well did you perform w.r.t., some abstract utility function."//
* crucial question: ''//where does the utility function come from???//''
* it seems that not any entity can execute any task/plan, though it is expressed only indirectly
* IMHO, the notation and nomenclature a bit confused and vague. At times it is not very rigorously defined (e.g., the //goal satisfaction condition//, or the confusion of goal where it actually amounts to an abstract algorithm/task/plan etc.)
About 2.5hrs meeting (+lunch) with VL.
* explanation of the DeepA projects structure, aims, main results and the future
* significant time spent on discussion of potential synergies between formal approaches to strategic games (ATL and friends) and the project
!!!Notes:
* strong emphasis on planning through //search// and //optimization of utility values//
* it's a game with //multiple players//, where each has //several actions// sometimes even using //resources//
* all the players use the same algorithm for playing against each other, just their goals and utilities are different
* the results were published in the AAMAS 2009 and a submission AAMAS'10
** from the presentation I recollect that it was mostly about a particular adaptation of kind of a min-max search
** integration with HTN(?)
!!! ToDo:
<<tiddler [[DeepA-20091020 - todo]]>>
* read the final report of DeepA 1
* read midterm report of DeepA 2
* contact Wojtek regarding practical applications of model checking of (strategic) games.
** how large problems were already approached?
- published on the //DocArch// server.
! Starting points - towards truly //open heterogeneous multi-agent systems//
''Working assumption:'' it seems that truly open heterogeneous MASs (OHMAS) are rather neglected in the current MAS-related research. In the future, OHMASs will find their applications in domains such as //Internet// (e.g., social networks(?), AgentCities-like systems) and //ambient intelligence//. Perhaps even elsewhere (military?).
Below, I summarize the main research vectors in this realm as I currently recognize them:
! Agent-Oriented Software engineering
There seems to be a gap in the current research on coordination programming left by the previous work. It lies in the fact that the current approaches, such as [[Machinetta|Reading notes on teamwork programming: Machinetta]] seem to be focused on
# closed multi-agent systems with heterogeneous agents (MAS type issue)
# implemented by single development teams (Agent-Oriented Software Engineering issue)
These issues stem from the fact (currently a suspicion only), that the state-of-the-art approaches seem to favour //centralized teamwork programming//. Of course //decentralizing// would increase communication amount needed within the MAS.
Implementation of //open heterogeneous MASs// should stem from minimal assumptions, such as the following
# common communication platform
# common communication language
# common communication ontology
Implementation of teamwork in such systems poses two main research problems:
# ''team (coalition) formation'', and
# ''coordination mechanisms and models''
** which in fact have to do with ''communication protocols'' and market-like ''coordination models''
! Domain-independent measuring of effects of coordination in MASs
TODO:
* the entropy stuff
* the shared information stuff
* check again Gal Kaminka's paper
/***
|Name|DisableWikiLinksPlugin|
|Source|http://www.TiddlyTools.com/#DisableWikiLinksPlugin|
|Version|1.6.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides|Tiddler.prototype.autoLinkWikiWords, 'wikiLink' formatter|
|Options|##Configuration|
|Description|selectively disable TiddlyWiki's automatic ~WikiWord linking behavior|
This plugin allows you to disable TiddlyWiki's automatic ~WikiWord linking behavior, so that WikiWords embedded in tiddler content will be rendered as regular text, instead of being automatically converted to tiddler links. To create a tiddler link when automatic linking is disabled, you must enclose the link text within {{{[[...]]}}}.
!!!!!Usage
<<<
You can block automatic WikiWord linking behavior for any specific tiddler by ''tagging it with<<tag excludeWikiWords>>'' (see configuration below) or, check a plugin option to disable automatic WikiWord links to non-existing tiddler titles, while still linking WikiWords that correspond to existing tiddlers titles or shadow tiddler titles. You can also block specific selected WikiWords from being automatically linked by listing them in [[DisableWikiLinksList]] (see configuration below), separated by whitespace. This tiddler is optional and, when present, causes the listed words to always be excluded, even if automatic linking of other WikiWords is being permitted.
Note: WikiWords contained in default ''shadow'' tiddlers will be automatically linked unless you select an additional checkbox option lets you disable these automatic links as well, though this is not recommended, since it can make it more difficult to access some TiddlyWiki standard default content (such as AdvancedOptions or SideBarTabs)
<<<
!!!!!Configuration
<<<
<<option chkDisableWikiLinks>> Disable ALL automatic WikiWord tiddler links
<<option chkAllowLinksFromShadowTiddlers>> ... except for WikiWords //contained in// shadow tiddlers
<<option chkDisableNonExistingWikiLinks>> Disable automatic WikiWord links for non-existing tiddlers
Disable automatic WikiWord links for words listed in: <<option txtDisableWikiLinksList>>
Disable automatic WikiWord links for tiddlers tagged with: <<option txtDisableWikiLinksTag>>
<<<
!!!!!Revisions
<<<
2008.07.22 [1.6.0] hijack tiddler changed() method to filter disabled wiki words from internal links[] array (so they won't appear in the missing tiddlers list)
2007.06.09 [1.5.0] added configurable txtDisableWikiLinksTag (default value: "excludeWikiWords") to allows selective disabling of automatic WikiWord links for any tiddler tagged with that value.
2006.12.31 [1.4.0] in formatter, test for chkDisableNonExistingWikiLinks
2006.12.09 [1.3.0] in formatter, test for excluded wiki words specified in DisableWikiLinksList
2006.12.09 [1.2.2] fix logic in autoLinkWikiWords() (was allowing links TO shadow tiddlers, even when chkDisableWikiLinks is TRUE).
2006.12.09 [1.2.1] revised logic for handling links in shadow content
2006.12.08 [1.2.0] added hijack of Tiddler.prototype.autoLinkWikiWords so regular (non-bracketed) WikiWords won't be added to the missing list
2006.05.24 [1.1.0] added option to NOT bypass automatic wikiword links when displaying default shadow content (default is to auto-link shadow content)
2006.02.05 [1.0.1] wrapped wikifier hijack in init function to eliminate globals and avoid FireFox 1.5.0.1 crash bug when referencing globals
2005.12.09 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.DisableWikiLinksPlugin= {major: 1, minor: 6, revision: 0, date: new Date(2008,7,22)};
if (config.options.chkDisableNonExistingWikiLinks==undefined) config.options.chkDisableNonExistingWikiLinks= false;
if (config.options.chkDisableWikiLinks==undefined) config.options.chkDisableWikiLinks=false;
if (config.options.txtDisableWikiLinksList==undefined) config.options.txtDisableWikiLinksList="DisableWikiLinksList";
if (config.options.chkAllowLinksFromShadowTiddlers==undefined) config.options.chkAllowLinksFromShadowTiddlers=true;
if (config.options.txtDisableWikiLinksTag==undefined) config.options.txtDisableWikiLinksTag="excludeWikiWords";
// find the formatter for wikiLink and replace handler with 'pass-thru' rendering
initDisableWikiLinksFormatter();
function initDisableWikiLinksFormatter() {
for (var i=0; i<config.formatters.length && config.formatters[i].name!="wikiLink"; i++);
config.formatters[i].coreHandler=config.formatters[i].handler;
config.formatters[i].handler=function(w) {
// supress any leading "~" (if present)
var skip=(w.matchText.substr(0,1)==config.textPrimitives.unWikiLink)?1:0;
var title=w.matchText.substr(skip);
var exists=store.tiddlerExists(title);
var inShadow=w.tiddler && store.isShadowTiddler(w.tiddler.title);
// check for excluded Tiddler
if (w.tiddler && w.tiddler.isTagged(config.options.txtDisableWikiLinksTag))
{ w.outputText(w.output,w.matchStart+skip,w.nextMatch); return; }
// check for specific excluded wiki words
var t=store.getTiddlerText(config.options.txtDisableWikiLinksList);
if (t && t.length && t.indexOf(w.matchText)!=-1)
{ w.outputText(w.output,w.matchStart+skip,w.nextMatch); return; }
// if not disabling links from shadows (default setting)
if (config.options.chkAllowLinksFromShadowTiddlers && inShadow)
return this.coreHandler(w);
// check for non-existing non-shadow tiddler
if (config.options.chkDisableNonExistingWikiLinks && !exists)
{ w.outputText(w.output,w.matchStart+skip,w.nextMatch); return; }
// if not enabled, just do standard WikiWord link formatting
if (!config.options.chkDisableWikiLinks)
return this.coreHandler(w);
// just return text without linking
w.outputText(w.output,w.matchStart+skip,w.nextMatch)
}
}
Tiddler.prototype.coreAutoLinkWikiWords = Tiddler.prototype.autoLinkWikiWords;
Tiddler.prototype.autoLinkWikiWords = function()
{
// if all automatic links are not disabled, just return results from core function
if (!config.options.chkDisableWikiLinks)
return this.coreAutoLinkWikiWords.apply(this,arguments);
return false;
}
Tiddler.prototype.disableWikiLinks_changed = Tiddler.prototype.changed;
Tiddler.prototype.changed = function()
{
this.disableWikiLinks_changed.apply(this,arguments);
// remove excluded wiki words from links array
var t=store.getTiddlerText(config.options.txtDisableWikiLinksList,"").readBracketedList();
if (t.length) for (var i=0; i<t.length; i++)
if (this.links.contains(t[i]))
this.links.splice(this.links.indexOf(t[i]),1);
};
//}}}
[[McCarthy's 1998 paper|http://www-formal.stanford.edu/jmc/elaboration/elaboration.html]]
> //Elaboration tolerance// is the ability to accept changes to a person's or a computer program's representation of facts about a subject without having to start all over. Often the addition of a few sentences describing the change suffices for humans and should suffice for computer programs.
/%
!info
|Name|EmbedTiddlers|
|Source|http://www.TiddlyTools.com/#EmbedTiddlers|
|Version|2.0.1|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|Type|transclusion|
|Description|transclude a list of tiddlers in a specific order|
Usage
<<<
{{{
<<tiddler EmbedTiddlers with: "TiddlerName [[TiddlerName with spaces]] TiddlerName ...">>
<<tiddler EmbedTiddlers with: @TiddlerName>>
<<tiddler EmbedTiddlers with: =tagValue sortby>>
}}}
*''"~TiddlerName """[[TiddlerName with spaces]] TiddlerName ...""""''<br>specifies a list of tiddlers to embed
*''@~TiddlerName''<br>specifies a //separate// tiddler containing the space-separated, bracketed list of tiddlers to embed (e.g., like [[DefaultTiddlers]])
*''=tagValue''<br>embeds all tiddlers that are tagged with the indicated value
*''sortby'' (optional)<br> specifies a tiddler field for sorting the results (default="title"). Use "+" or "-" prefix to indicate the sort direction (ascending/descending), e.g., "-modified" sorts by tiddler modification date, most recent first.
Note: if MatchTagsPlugin is installed, you can use //compound Boolean logic expressions// in place of the "tagValue" (following the leading "="). However, because a boolean expression will always contain spaces, it MUST be enclosed in [[...]], like this:
{{{
<<tiddler EmbedTiddlers with: [[=settings AND NOT systemConfig]]>>
}}}
<<<
!end
!out
$1
!end
!show
<<tiddler EmbedTiddlers##out with: {{
var list='$1';
var sortby='title'; if ('$2'!='$'+'2') sortby='$2';
var tids=[];
if (list.substr(0,1)=='=') {
var fn=store.getMatchingTiddlers||store.getTaggedTiddlers;
var tagged=store.sortTiddlers(fn.apply(store,[list.substr(1)]),sortby);
for (var t=0; t<tagged.length; t++) tids.push(tagged[t].title);
} else {
if (list.substr(0,1)=='@') list=store.getTiddlerText(list.substr(1),'');
var tids=list.readBracketedList();
}
var out='';
for (var i=0; i<tids.length; i++) out+='<<tiddler [['+tids[i]+']]>\>';
out;
}}>>
!end
%/<<tiddler {{var src='EmbedTiddlers'; src+(tiddler&&tiddler.title==src?'##info':'##show');}}
with: [[$1]] [[$2]]>>
! Motivation
While reading [[The Interdisciplinary Study of Coordination]] and related papers, it occurred to me that actually why the Army is changing towards more flexible, modular, adaptable, etc. entity is the recognition of increase of the entropy in the warfare. Let us consider a kind of (for now only imaginary) //entropy// measure of a multi-agent system (simulation, a real military operation, basically any larger dynamic and unpredictable MAS deployment). It should speak about //concert// in which the entities of the system act. In a military domain this could be imagined e.g., as a Roman square formation, or soldiers marching in rows in a certain direction, or 18-19th century rows of soldiers shooting on command and marching towards the enemy. These would be examples of MASs with low degree of entropy (unless on the run ;-) ). On the other hand, the guerrilla tactics has a much higher degree of entropy. Agents are acting in a much more decentralized and unconcerted ways. They perhaps share joint goals, or perhaps even a strategy, but their actions are much more autonomous. The current terrorist tactics seems to feature even higher level of entropy than guerrilla tactics. That's because now even a strategic goals seem to be much weaker - the aim is just to inflict damage. Any damage. Anywhere. It's more annoying that harmful in reality.
It seems to me that actually recognition of the increase in the entropy of enemy activities led to the need to increase the entropy in ones own units. That's why they are now more thinking in //goal-oriented// terms rather than //plan-oriented//. This can be easily seen in training documents, such as the [[No approved solutions in asymmetric warfare|http://globalguerrillas.typepad.com/files/assembly-article.pdf]] or perhaps even in books such as [[this|http://globalguerrillas.typepad.com/files/vandergriff-raising_the_bar.pdf]] (didn't read it yet). [a side note: this also seems to appear in business processes - there seems to be a shift towards //goal-oriented business processes//].
! How to measure the entropy of a MAS?
One of the interesting ideas on this could be to count //loci of activity// and see whether our system is succeeding in handling them successfully, or not (well, all this sounds very vague). Perhaps something like this could be useful:
\[ \epsilon = \frac{\#success\_points}{\#active\_points} \]
where $success\_points$ are those in which our team was able to reach the team goal in a given time-window. This assumes there is a notion of a //team goal w.r.t. a single activity locus// of course. Or we could integrate that over time somehow like this
\[ \epsilon = \int_0^\infty \frac{\#success\_points}{\#active\_points} dt \]
The idea is that //coordination helps to push this objective function towards 1//.
The problems of such a measure are:
* it does not capture the cost of coordination, i.e., [[things like information exchange|Information as the cost factor of coordination]], etc.
* it also doesn't capture the size of the overall system
* definitely it is more valuable to have smaller team to deal with a large number of loci of activity (such as the MxN tracking), rather than huge lot of resources which are idle most of the time... The measure doesn't capture any of these issues.
* in an ideal case the measure should show differences in qualitatively different systems (no clue what this really means though - something like the concept of the intelligence as robustness against disruption against a human actor)
! Class of entropy measures
Most probably we are not able to come up with a single measure fitting a large number application domains. Rather, there might be a whole class of such measures (even though perhaps not easily identifiable in some domains). Therefore, it seems to be reasonable to try to formulate properties of such measures and admit any which fulfills them.
The first ideas would go along the following lines:
* we consider an environment $e$ and a multi-agent system (the team) $t$
* let $\epsilon_e$ measure the entropy of the //environment// and $\epsilon_t$ measure the entropy of the //team//
* let's assume a range of values $\epsilon_{e/t}\in[0,1]$
** loosely, $\epsilon_t=1$ means that the team does not coordinate //at all//, i.e., it's members act completely autonomously without a regard for other team members' actions
** loosely, $\epsilon_t=0$ means that the team is //perfectly orchestrated//, i.e., each action depends on other team member's actions and the team agents do not have any free will - perhaps there is a //centralized planner// for their activities
* let's also assume a team goal $\gamma$
Now, we can characterize the whole problem domain through the values of $\epsilon_e$ as follows:
* iff $\epsilon_e=0$, then there exists an implementation of the team $t$ with $\epsilon_t=1$, such that for all possible traces of team activity, $t$ reaches $\gamma$
** $\Rightarrow$ there's no real need to coordinate in such an environment
* iff $\epsilon_e=1$, then there exists an implementation of the team $t$ with $\epsilon_t=0$, such that there exists its team activity trace reaching $\gamma$ and at the same time there's no implementation of $t$ with $\epsilon_t>0$ which would have a team activity trace reaching $\gamma$
** $\Rightarrow$ only perfectly coordinated effort brings about success in such a domain
http://www.paulgraham.com/essay.html
Great article on writing essays and history of that. Very interesting reading, especially when seen from the perspective of a scholar in the business of writing scientific articles.
Michel de Montaigne: // Expressing ideas helps to form them.//
//Essays should aim for maximum surprise.//
//Collecting surprises is a similar process. The more anomalies you've seen, the more easily you'll notice new ones. Which means, oddly enough, that as you grow older, life should become more and more surprising. When I was a kid, I used to think adults had it all figured out. I had it backwards. Kids are the ones who have it all figured out. They're just mistaken.//
//I write down things that surprise me in notebooks. I never actually get around to reading them and using what I've written, but I do tend to reproduce the same thoughts later. So the main value of notebooks may be what writing things down leaves in your head.//
Essay = essayer (fr. to try)
Essay = essai (fr. an attempt)
What he says about meandering is very much what I tend to do. I write a long "essay" on stuff only to later find out what it really is about, extract the essence, put it up as the thesis and then vigorously defend (well...). So this reflects the process of writing a paper...
But it also speaks about how to organize this scrapbook perhaps. These are to be essays. Not scientific papers. So the organization of stuff should follow this meandering. I should rather collect thoughts, put them somehow together and organize, re-organize and re-organize again until I find an argument. And to store the process well, the scrapbook will help. Good, let's do it in the future...
!!Just an informal note:
Sometimes I think that most approaches to programming agents people come up with would work with some effort. The point therefore shouldn't be to evaluate whether a proposed new framework works, or not. It most probably does. The point should be to evaluate ''how well'' the framework, or the proposal actually ''works''. I.e., we should evaluate on the ground of considering the following questions
# can I create with the framework systems/artifacts which are //objectively// (whatever that means) //better//, or of a //higher quality//, or more //efficient//, etc.?
# in the case I can create about the same class of systems as with the other frameworks/approaches, does this framework provide //natural// ways of doing it //faster//, in a more //shorter// / //concise// manner?
# and if none of the above (of besides those above), does the framework/approach allow me to //change// the system in a more practical way, or faster, etc.? I.e., is the proposal //ensuring// / //enabling// a more //elaboration tolerant// way of doing things?
* Baudinet: //Temporal logic programming is complete and expressive// - [[link|http://portal.acm.org/citation.cfm?id=75301&coll=GUIDE&dl=GUIDE&CFID=91848747&CFTOKEN=22776199&ret=1#Fulltext]]
** temporal logic programming and the TEMPLOG system. Something to check one day...
* Fisher, Wooldridge: //Executable Temporal Logic for Distributed A.I.// - [[link|http://www.csc.liv.ac.uk/~mjw/pubs/iwdai93.pdf]]
** the MetateM stuff
The power of BSM's is in the fact that we can handle infinite number of states, rather than FSMs - they handle just a finite number.
agents ai apl asp collaboration events folder games help ideas journal kr links meta people reading robotics serious thesis conferences prolog todo done projects meeting [[To Do]]
Argument from:
http://www.bit-tech.net/gaming/2009/03/05/how-ai-in-games-works/
http://www.bit-tech.net/gaming/2009/03/05/how-ai-in-games-works/2
//Creative Assembly’s studio communications manager, Kieran Brigden, explains, "When you start talking about an ever-expanding number of states then you start to run into problems. For example, if you have a huge number of states for a man in Empire: Total War, you then put 160 men in a unit, and 20 units in an army, think how many decision trees you’re having to do for every single man on the screen. We’re talking about several thousands of guys on the screen at one time; each of those has a massive state-based logic tree, so never mind your two percent processor overhead."//
//Crytek’s Matthew Jack concurs, saying that "the problem with state machines is defining all the transitions between them; 25 states isn’t such a big number for an AI character, but it can be hard for a developer to manage all the ways that a state might be reached, and ensure that it can be reached where it’s needed". Without revealing any specifics, Jack also adds that "since Crysis, we’ve moved towards other behaviour models to help us manage that complexity". //
GOAL is [[Koen Hindriks]]'s [[agent oriented programming language]].
http://mmi.tudelft.nl/~koen/goal.php
* as of now (June 2009), just an interpreter - no serious application demoed.
* very much along lines of my thoughts on Beliefs + Desires, i.e., no explicit notion of Intentions included
* actions as STRIPS-like atomic action specs
!! Starting point
The final aim of the series of 1-3 meetings with BBO & VLY is to reach a state where we agree on a partial scenario within the frame of the TAF II MxN tracking scenario(s) which in ideal case should satisfy the following:
# fit the TAF II framework
# in the future extensions should fit the TAS II scenario (should have a potential to become the core TAS II scenario)
# provide a solid research basis for at least one of the GT/Adver team members (VLY, BBO)
!! Results of the 2hrs discussion
We went over a series of smaller candidate scenarios. The two emerging topics seem to revolve around //patrolling games// and //search & capture games//. It seems that we want to play these games on graphs, subgraphs of the ground street map of the environment. These topics naturally fit the TAS II scenario. Later we tried to push towards brainstorming on applications of these things in TAF II scenarios, i.e., targets vs. UAVs. One of the feelings I have from that meeting is that we are after a kind of symmetric algorithms which would work for both the //smart target//, as well as for the //UAV// in the game.
We came up with some ineteresting scenarios leading to an implementation of 1xN, or MxN tracking scenarios. I.e., provided that the targets try to evade, the planes have to seek strategies allowing them to patrol a set of multiple targets which on the other hand assume the best tracking method on the side of the UAVs.
There were two styles of work which I felt emerged from the discussion. Either to go after a general theoretical result with high significance in the community, or to go after an instance of a problem which the community did not see yet. It seems that VLY and BBO prefer the latter.
An interesting discussion emerged around the 1xN tracking scenario, where the UAV tracks several targets and knows about them, while the targets do not know about other tracked entities. In result, the targets operate in a setting where they need to make locally optimal (or similar) decisions, while the UAV can make globally optimal decisions. What are the interesting problems are the relations of the local optima vs. the global optima. This kind of work would go after the high-significance theoretical approach I would prefer, but BBO&VLY do not seem to be fond of this direction.
We were also seeking overlaps between the AgentC project and the TAF II project. No particular notes emerged.
BTW, are there any overlaps with the DeepA, or some other older project? Can we re-use something from the past???
//''todo:'' ask VLY about applications of this//
----
Overall, the meeting was a good brainstorming however with little concrete results. We agreed upon a subsequent one on Thursday where we would like to formulate a concrete scenario which we will work on within the context of the TAF II project.
There seems to be an interesting relationship between the [[Getting Things Done|http://en.wikipedia.org/wiki/Getting_Things_Done]] approach to boosting productivity in real life and the Belief-Desire-Intention architecture. In a nutshell, apart from introducing varying horizon goals hierarchy, the GTD methodology introduces a workflow of tasks and projects flowing through persons desk. In terms related to APL terminology we could say that it prescribe the following steps:
# whenever an event arrives to your inbox try to sort it to one of the knowledge bases.
## if it is an information, just archive it to the belief base
## if it has to acted upon decide whether it can be done immediately
### if YES, then simply do it
### if NO, deffer it
# upon deffering decide whether it is a multi-step task/goal
## if NO, put it into the next-actions list, i.e., the base of intentions
## if YES, create a //project// out of it and identify the //next action// of that project
# projects gradually break down into new //next actions// until the project success/failure condition is established
In BDI, the flow of information is similar. Perceptions from the environment are reflected in agent's belief. On the ground of holding certain beliefs, the agent adopts new goals and subsequently instantiates plans as intentions in order to achieve them. The main difference between the GTD and the BDI approach seems to be that while in BDI we expect the algorithm doing the goal breakdown to sub-goals and actions to be fixed, in GTD this is left to the user. That's also why most of such do not fail if done carefully. Using a human planner in between is actually a very robust point of the GTD framework.
The resulting idea boils down to //integration of a state-of-the-art planner as the algorithm for doing the goal breakdown//. Actually in its current incarnations, BDI is quite close to HTN planning algorithms, however implements a plan-as-you-go algorithm. Let's try to generalize a bit and propose an architecture which would use a solid 3rd party planner as the module generating next actions from goals an agent adopts. The agent programming language then becomes a mere tool for encoding the meta-reasoning mechanism of agent's deliberation. But come on! This is clean and useful. And the contribution is that it finally 1) makes the deliberation cycle explicit and thus flexible to tweak, and 2) separates the meta-reasoning from the actual agent's deliberation. And of course this can be done with the BSM framework easily. Actually, I could use the JShop planner together with the Scala JazzykJVM interpreter as a proof-of-concept.
Finally, an important point is that GTD works. We know that. Many many people use it. While BDI is an artificial technique for which we do not well know whether it's really good/the best one. What we know is that it is inspiring and often works. GTD seems to really work //very very often//.
[[homepage|http://u.cs.biu.ac.il/~galk/]]
A comparison and a hit list of the best state of the art computer game 3D engines:
http://news.cnet.com/8301-13860_3-10286732-56.html
This is of a lot of interest for programming and experimentation with [[Serious Games]].
An older engine for connecting to [[Unreal Tournament]].
http://gamebots.planetunreal.gamespy.com/
http://www.gamebots.org/
* seems to be discontinued, but I am not sure
* [[Barry Silverman]] is using it in army simulations
* [[Pogamut]] project is also using it (very fresh! 2009)
* [[Gal Kaminka]] is one of the co-founders
In what follows, I try to reformulate some of the ideas presented in the [[Notes on the scenario]]. The new attempt should basically serve as a clarification and improved presentation of the idea.
!!! Core scaffolding: the scenario structure
The scenario basically consists of 2 highest-level units:
# the task force
# the environment
Furthermore, the task force is decomposed into 3 high-level entities of our primary interest:
# the convoy
# team of UGVs (scouts)
# team of UAVs (trackers)
The environment is not of the primary interest in the scenario, yet plays a very important role in that it provides the dynamics of the world in which the task force lives. Generally it provides
# basic physics
# the landscape and solid structures, such as the ground, buildings, structural damage thereof, human agents, such as civilians, or adversary units, etc.
The communication infrastructure is considered a technical part of the system which is not explicitly modeled in the scenario.
The scenario functionality is determined by encapsulation of the entities into closed //autonomous// functional units only providing clean interfaces in terms of the communication protocol specification they comply to, thus implicitly defining the set of their corresponding capabilities. Of the main interest is the //task force// functionality and "intelligence".
!!!!! Functional decomposition
!!!!!! Convoy
* decides about its own //destination//
* on the basis of the information about the map it has, it plans the route to the destination
* moves along the route as the physical conditions allow. I.e., with the speed corresponding to the density of obstacles (people) on the road.
!!!!!! UGVs
* on the ground of the current convoy route + the current information about the state of the environment (the map), the team of scouts autonomously decides about the destinations its members move to
* team members autonomously navigate on the ground according to the destinations identified/decided upon by either themselves and/or the team as a whole (whatever that means)
* UGVs have the capability to clean areas of civilians in that these are repelled by UGVs
* UGVs can identify new targets for tracking, i.e., suspiciousimplementation team members entities (crowds?)
* has the ability to track targets on the ground
!!!!!! UAVs
* on the ground of the current convoy route + the current information about the state of the environment (the map), the team of UAVs autonomously decides about the destinations its members move to
* team members autonomously navigate in the air according to the destinations identified/decided upon by either themselves and/or the team as a whole (whatever that means)
* the team of UAVs has the ability to //explore// an area and provide a global view
* UAVs have the capability to //track// targets
* UAVs can identify new targets for tracking, i.e., suspicious entities (crowds?)
!!!!! Interfaces and roles of the component teams within the task force structure
!!!!!! Convoy
__IN__:
* it accepts information about the changes in the environment (map)
__OUT__:
* request for support to the UGV-/UAV-teams along with the details about the route it currently plans to take to whatever destination it has
__INTENDED BEHAVIOUR__:
* movement along the pre-planned route
!!!!!! UGVs
__IN__:
* the current route of the convoy
* information about important changes in the environment (important w.r.t. the UGV-team's core functionality)
__OUT__:
* information about important changes in the environment w.r.t.
## the convoy's capabilities
## the UAV-team's capabilities
* request for target tracking support from the UAV-team
__INTENDED BEHAVIOUR__:
* explore the quality/navigability of the pre-planned convoy route and its surroundings
* guard the route segments in the vicinity of the convoy itself as it passes through the environment (implies movement in a (semi-)formation, or something in that direction)
!!!!!! UAVs
__IN__:
* information about important changes in the environment (important w.r.t. the UAV-team's core functionality)
* can receive requests for support by tracking a target
* possibly can receive requests for support by providing continuous surveillance of an area (???)
__OUT__:
* information about important changes in the environment w.r.t.
## the convoy's capabilities
## the UAV-team's capabilities
__INTENDED BEHAVIOUR__:
* explore the environment at the first phase of the mission
* explore area/segments of the environment on request from UGVs
* track targets on either request from UGV-team, or because of own decision
!!!!! Communication structure (Variant 1)
!!!!!! Convoy vs. UGVs
* convoy informs the UGV team about the planned route
* UGVs inform the convoy about important changes of the environment. I.e.,
## newly identified structural changes to the environment
## newly identified suspicious entities
## updates of the position (status?) of already identified suspicious entities
!!!!!! Convoy vs. UAVs
* the same as above (convoy vs. UGVs)
!!!!!! UAVs vs. UGVs
* UGVs request UAVs to provide support in tracking of suspicious entities (unidirectional)
* UGVs and UAVs provide each other with the same type of information they pass to the convoy (bidirectional)
!!!!! Communication structure (Variant 2)
!!!!!! Convoy vs. UGVs
* the same as Variant 1
!!!!!! Convoy vs. UAVs
* nothing
!!!!!! UAVs vs. UGVs
* UGVs request UAVs to provide support in tracking of suspicious entities (unidirectional)
* UAVs provide UGVs the same type of information as in the Variant 1 (unidirectional)
!!! Modularity
The scenario is modular in that it decomposes the functionality of the task force unit into encapsulated sub-teams. From outside these are modelled as a //single autonomous entity//. This decomposition allows for a rather large freedom in the concrete functionality of the teams and scientific/engineering approach taken to implement them. Another positive(?) point is that it allows to start implementation work on the technological infrastructure rather rapidly, leaving out the particular details of team functionality to be defined and implemented later - as far as the main functionality (INTENDED BEHAVIOURS) of the teams somehow work (possibly a mock-up at the beginning).
!!! Note on orthogonal interests in team design and implementation
The teams' functionality is defined only declaratively - as a set of interface and the communication structure. This allows to decouple the //software engineering methodology// from the particular// team strategy//. These can be later approached by two relatively independent implementation efforts (possibly corresponding to separate(?) scientific interests of the developers).
!!!!! Note on scenario variability
The main focus is on creating two teams of agents which perform some interesting behaviour. Thus several simplifications can be done in order to simplify the task in areas which are not in the focus of the project. E.g., the transferred information can be simply broadcasted in a shared bus by all the teams. In order ensure autonomy of the teams, these should however negotiate and communicate in a closed fashion among themselves.
!!! Demo attractivity
The main aim would be to show the coordinated efforts on two levels:
# among the teams
# within each team
An idea how to demonstrate that could be to highlight the emergent process in which the following cycle happens again and again:
# the convoy decides on a new route which will be displayed
# the UGVs start to explore the unknown areas along the route near to the convoy
# UAVs fly to explore the areas farther away along the route, as well as re-calculate the "interestingness" of tracked targets
# upon identification of a suspicious object (EOF - entity of interest) UAVs regroup and start tracking
## this might change as the EOFs turn into uninteresting entities (e.g., a crowd dissolved itself, or was forced to do so by UGVs(?))
# besides that, the UAV-team in its capacity (when idle?) explores the environment, or renews its old information about it
!!! Scientific content - a quick proposal
!!!! JVO:
* M2N tracking
* etc.?
!!!! TKO:
* planning techniques within the UGV-/UAV-teams, i.e., the particular AI strategy of the teams (see the note above)
* etc.?
!!!! PNO:
* the software engineering of the agents in the teams and techniques for //autonomous coordination// among the team members
* participation on the TKOs interests?
* etc.?
To get started with this blank TiddlyWiki, you'll need to modify the following tiddlers:
* SiteTitle & SiteSubtitle: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)
* MainMenu: The menu (usually on the left)
* DefaultTiddlers: Contains the names of the tiddlers that you want to appear when the TiddlyWiki is opened
You'll also need to enter your username for signing your edits: <<option txtUserName>>
//A case for goal-oriented programming semantics//: http://www.cag.lcs.mit.edu/~umar/publications/ubisys.pdf
Accidentally I bumped into this paper. It makes quite an interesting case for goal-orientedness in pervasive computing. Actually, the abstractions they propose there seem not to go in direction of //agentification// of a distributed AI system. In a way, this reinforces my intuition that the pervasive computing (ambient intelligence, etc.) folks could make some use of the agent oriented computing paradigm. Thus, ambient intelligence and alike seem to be a very interesting application domain for agents.
A question remains:
//How important, or prevalent, is this approach in the ambient intelligence/pervasive computing fields?//
I should take a close look at this in the future...
http://www.idsia.ch/~juergen/goedelmachine.html
Something to read when idle. Belongs to the realm of [[Artificial General Intelligence]]
http://www.ibm.com/developerworks/rational/library/jul05/pollice/index.html
Very nice article on art and craft of making software.
* [[Wikipedia|http://en.wikipedia.org/wiki/Gregory_Chaitin]]
* [[Homepage|http://www.cs.auckland.ac.nz/~chaitin/]]
* [[The Limits of Mathematics|http://www.umcs.maine.edu/~chaitin/lm.html]]
* [[LM book by Springer|http://www.springer.com/math/book/978-1-85233-668-4]]
Selected (relevant) invited talks:
# [[Paulo Moura: From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse]]
# [[Marc Denecker: A Knowledge Base System project for FO(.)]]
[[http://danielwilkerson.com/entropy.html]]
[[http://en.wikipedia.org/wiki/Entropy_%28information_theory%29]]
[[http://en.wikipedia.org/wiki/Entropy_in_thermodynamics_and_information_theory]]
[[http://www.eolss.net/ebooks/Sample%20Chapters/C02/E6-46-01-04.pdf]]
[[http://www.iep.utm.edu/time/]]
[[http://books.google.com/books?id=a25hPrUrsSMC&lpg=PA1&ots=5gWtS9-CQQ&dq=temporal%20logics%20entropy&pg=PA2#v=onepage&q=entropy&f=false]]
[[Random worlds and maximum entropy|http://www.cs.cornell.edu/home/halpern/abstract.html]]
This is a free continuation of the previous note on [[Entropy and assymetric warfare]].
Obviously, one of the most important costs of coordination is the amount of information which has to be passed between the coordinating entities. An interesting measure of this cost is the ratio of the amount of information which is actually shared in the considered system versus the complete information. I.e., something like this:
\[ I=\frac{\#shared\_information}{\#complete\_information} \]
or perhaps
\[ I=\frac{\#shared\_information}{\#complete\_information \times \#actors} \]
Assuming an ideal MAS which is always able to reach its global goals, the quality of the system increases with $I$ closer to $0$. For $I$'s closer to $1$, we have that the system is sharing too much information and is more centralized in nature (and if it is not, it can easily be made so).
!! Elaboration
In a sketch, from the point of view of the agent doing tracking (creditor) the activity structure looks similarly to the following:
# tracking
# recognition of a limit/need for handover
# call for help
# receive proposals
# select the delegee
# announce the winner (?), i.e., announce/notify about accept/reject notice
# receive ack from the delegee
# terminate
This would be the successful path through the coordination mechanism. However, there 1) is a number of terminating states with unsuccessful outcome, as well as 2) contingencies/unexpected event handling.
One can see the mechanism modeled by a //finite state machine//. However, from a multi-agent point of view, the mechanics involves also synchronization points (e.g., launch the winner decision procedure upon receivng the last reply/all bids). This calls for synchronization capability of the modeling abstraction, such as e.g., //Petri Nets//.
!! Q: How are communication protocols represented in the state-of-the-art literature?
Obviously at least FSMs and PNs are good candidates/starting points here.
@@
<<<
A: indeed FSMs and PNs are also used. References would include
; Finite State Machines
: Barbucaenu and Fox: //COOL: A language for describing coordination in multi-agent systems//, ICMAS 1995
; Petri Nets
: Cost et al. //Using colored Petri nets for conversation modelling//, LNAI 1916, 2000
-- references extracted from Yolum & Singh: //Commitment Machines//, LNAI 2333, 2002
<<<
@@
!!! Side note/question:
Most probably I can easily model FSMs with BSMs, but can I do Petri Nets easily? I mean, in a complex clumsy way there definitely is a way to do it. BSMs are powerful enough, but are they also the right way to do it?
/***
|Name|InlineJavascriptPlugin|
|Source|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
|Documentation|http://www.TiddlyTools.com/#InlineJavascriptPluginInfo|
|Version|1.9.5|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|Insert Javascript executable code directly into your tiddler content.|
''Call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
!!!!!Documentation
>see [[InlineJavascriptPluginInfo]]
!!!!!Revisions
<<<
2009.04.11 [1.9.5] pass current tiddler object into wrapper code so it can be referenced from within 'onclick' scripts
2009.02.26 [1.9.4] in $(), handle leading '#' on ID for compatibility with JQuery syntax
|please see [[InlineJavascriptPluginInfo]] for additional revision details|
2005.11.08 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.InlineJavascriptPlugin= {major: 1, minor: 9, revision: 5, date: new Date(2009,4,11)};
config.formatters.push( {
name: "inlineJavascript",
match: "\\<script",
lookahead: "\\<script(?: src=\\\"((?:.|\\n)*?)\\\")?(?: label=\\\"((?:.|\\n)*?)\\\")?(?: title=\\\"((?:.|\\n)*?)\\\")?(?: key=\\\"((?:.|\\n)*?)\\\")?( show)?\\>((?:.|\\n)*?)\\</script\\>",
handler: function(w) {
var lookaheadRegExp = new RegExp(this.lookahead,"mg");
lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = lookaheadRegExp.exec(w.source)
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
var src=lookaheadMatch[1];
var label=lookaheadMatch[2];
var tip=lookaheadMatch[3];
var key=lookaheadMatch[4];
var show=lookaheadMatch[5];
var code=lookaheadMatch[6];
if (src) { // external script library
var script = document.createElement("script"); script.src = src;
document.body.appendChild(script); document.body.removeChild(script);
}
if (code) { // inline code
if (show) // display source in tiddler
wikify("{{{\n"+lookaheadMatch[0]+"\n}}}\n",w.output);
if (label) { // create 'onclick' command link
var link=createTiddlyElement(w.output,"a",null,"tiddlyLinkExisting",wikifyPlainText(label));
var fixup=code.replace(/document.write\s*\(/gi,'place.bufferedHTML+=(');
link.code="function _out(place,tiddler){"+fixup+"\n};_out(this,this.tiddler);"
link.tiddler=w.tiddler;
link.onclick=function(){
this.bufferedHTML="";
try{ var r=eval(this.code);
if(this.bufferedHTML.length || (typeof(r)==="string")&&r.length)
var s=this.parentNode.insertBefore(document.createElement("span"),this.nextSibling);
if(this.bufferedHTML.length)
s.innerHTML=this.bufferedHTML;
if((typeof(r)==="string")&&r.length) {
wikify(r,s,null,this.tiddler);
return false;
} else return r!==undefined?r:false;
} catch(e){alert(e.description||e.toString());return false;}
};
link.setAttribute("title",tip||"");
var URIcode='javascript:void(eval(decodeURIComponent(%22(function(){try{';
URIcode+=encodeURIComponent(encodeURIComponent(code.replace(/\n/g,' ')));
URIcode+='}catch(e){alert(e.description||e.toString())}})()%22)))';
link.setAttribute("href",URIcode);
link.style.cursor="pointer";
if (key) link.accessKey=key.substr(0,1); // single character only
}
else { // run script immediately
var fixup=code.replace(/document.write\s*\(/gi,'place.innerHTML+=(');
var c="function _out(place,tiddler){"+fixup+"\n};_out(w.output,w.tiddler);";
try { var out=eval(c); }
catch(e) { out=e.description?e.description:e.toString(); }
if (out && out.length) wikify(out,w.output,w.highlightRegExp,w.tiddler);
}
}
w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
}
}
} )
//}}}
// // Backward-compatibility for TW2.1.x and earlier
//{{{
if (typeof(wikifyPlainText)=="undefined") window.wikifyPlainText=function(text,limit,tiddler) {
if(limit > 0) text = text.substr(0,limit);
var wikifier = new Wikifier(text,formatter,null,tiddler);
return wikifier.wikifyPlain();
}
//}}}
// // GLOBAL FUNCTION: $(...) -- 'shorthand' convenience syntax for document.getElementById()
//{{{
if (typeof($)=='undefined') { function $(id) { return document.getElementById(id.replace(/^#/,'')); } }
//}}}
/***
|Name|InlineJavascriptPluginInfo|
|Source|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
|Documentation|http://www.TiddlyTools.com/#InlineJavascriptPluginInfo|
|Version|1.9.4|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|documentation|
|Requires||
|Overrides||
|Description|Documentation for InlineJavascriptPlugin|
''Call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
!!!!!Usage
<<<
This plugin adds wiki syntax for surrounding tiddler content with {{{<script>}}} and {{{</script>}}} markers, so that it can be recognized as embedded javascript code.
<script show>
/* javascript code goes here... */
</script>Every time the tiddler content is rendered, the javascript code is automatically evaluated, allowing you to invoke 'side-effect' processing and/or produce dynamically-generated content that is then inserted into the tiddler content, immediately following the script (see below). By including the optional ''show'' keyword as the final parameter in a {{{<script>}}} marker, the plugin will also include the script source code in the output that it displays in the tiddler. This is helpful when creating examples for documentation purposes (such as used in this tiddler!)
__''Deferred execution from an 'onClick' link''__
<script label="click here" title="mouseover tooltip text" key="X" show>
/* javascript code goes here... */
alert('you clicked on the link!');
</script>
By including a {{{label="..."}}} parameter in the initial {{{<script>}}} marker, the plugin will create a link to an 'onclick' script that will only be executed when that specific link is clicked, rather than running the script each time the tiddler is rendered. You may also include a {{{title="..."}}} parameter to specify the 'tooltip' text that will appear whenever the mouse is moved over the onClick link text, and a {{{key="X"}}} parameter to specify an //access key// (which must be a //single// letter or numeric digit only).
__''Loading scripts from external source files''__
<script src="URL" show>
/* optional javascript code goes here... */
</script>You can also load javascript directly from an external source URL, by including a src="..." parameter in the initial {{{<script>}}} marker (e.g., {{{<script src="demo.js"></script>}}}). This is particularly useful when incorporating third-party javascript libraries for use in custom extensions and plugins. The 'foreign' javascript code remains isolated in a separate file that can be easily replaced whenever an updated library file becomes available.
In addition to loading the javascript from the external file, you can also use this feature to invoke javascript code contained within the {{{<script>...</script>}}} markers. This code is invoked //after// the external script file has been processed, and can make immediate use of the functions and/or global variables defined by the external script file.
>Note: To ensure that your javascript functions are always available when needed, you should load the libraries from a tiddler that is rendered as soon as your TiddlyWiki document is opened, such as MainMenu. For example: put your {{{<script src="..."></script>}}} syntax into a separate 'library' tiddler (e.g., LoadScripts), and then add {{{<<tiddler LoadScripts>>}}} to MainMenu so that the library is loaded before any other tiddlers that rely upon the functions it defines.
>
>Normally, loading external javascript in this way does not produce any direct output, and should not have any impact on the appearance of your MainMenu. However, if your LoadScripts tiddler contains notes or other visible content, you can suppress this output by using 'inline CSS' in the MainMenu, like this: {{{@@display:none;<<tiddler LoadScripts>>@@}}}
<<<
!!!!!Creating dynamic tiddler content and accessing the ~TiddlyWiki DOM
<<<
An important difference between TiddlyWiki inline scripting and conventional embedded javascript techniques for web pages is the method used to produce output that is dynamically inserted into the document: in a typical web document, you use the {{{document.write()}}} (or {{{document.writeln()}}}) function to output text sequences (often containing HTML tags) that are then rendered when the entire document is first loaded into the browser window.
However, in a ~TiddlyWiki document, tiddlers (and other DOM elements) are created, deleted, and rendered "on-the-fly", so writing directly to the global 'document' object does not produce the results you want (i.e., replacing the embedded script within the tiddler content), and instead will //completely replace the entire ~TiddlyWiki document in your browser window (which is clearly not a good thing!)//. In order to allow scripts to use {{{document.write()}}}, the plugin automatically converts and buffers all HTML output so it can be safely inserted into your tiddler content, immediately following the script.
''Note that {{{document.write()}}} can only be used to output "pure HTML" syntax. To produce //wiki-formatted// output, your script should instead return a text value containing the desired wiki-syntax content'', which will then be automatically rendered immediately following the script. If returning a text value is not sufficient for your needs, the plugin also provides an automatically-defined variable, 'place', that gives the script code ''direct access to the //containing DOM element//'' into which the tiddler output is being rendered. You can use this variable to ''perform direct DOM manipulations'' that can, for example:
* generate wiki-formatted output using {{{wikify("...content...",place)}}}
* vary the script's actions based upon the DOM element in which it is embedded
* access 'tiddler-relative' DOM information using {{{story.findContainingTiddler(place)}}}
Note:
''When using an 'onclick' script, the 'place' element actually refers to the onclick //link text// itself, instead of the containing DOM element.'' This permits you to directly reference or modify the link text to reflect any 'stateful' conditions that might set by the script. To refer to the containing DOM element from within an 'onclick' script, you can use "place.parentNode" instead.
<<<
!!!!!Instant "bookmarklets"
<<<
You can also use an 'onclick' link to define a "bookmarklet": a small piece of javascript that can be ''invoked directly from the browser without having to be defined within the current document.'' This allows you to create 'stand-alone' commands that can be applied to virtually ANY TiddlyWiki document... even remotely-hosted documents that have been written by others!! To create a bookmarklet, simply define an 'onclick' script and then grab the resulting link text and drag-and-drop it onto your browser's toolbar (or right-click and use the 'bookmark this link' command to add it to the browser's menu).
Notes:
*When writing scripts intended for use as bookmarklets, due to the ~URI-encoding required by the browser, ''you cannot not use ANY double-quotes (") within the bookmarklet script code.''
*All comments embedded in the bookmarklet script must ''use the fully-delimited {{{/* ... */}}} comment syntax,'' rather than the shorter {{{//}}} comment syntax.
*Most importantly, because bookmarklets are invoked directly from the browser interface and are not embedded within the TiddlyWiki document, there is NO containing 'place' DOM element surrounding the script. As a result, ''you cannot use a bookmarklet to generate dynamic output in your document,'' and using {{{document.write()}}} or returning wiki-syntax text or making reference to the 'place' DOM element will halt the script and report a "Reference Error" when that bookmarklet is invoked.
Please see [[InstantBookmarklets]] for many examples of 'onclick' scripts that can also be used as bookmarklets.
<<<
!!!!!Special reserved function name
<<<
The plugin 'wraps' all inline javascript code inside a function, {{{_out()}}}, so that any return value you provide can be correctly handled by the plugin and inserted into the tiddler. To avoid unpredictable results (and possibly fatal execution errors), this function should never be redefined or called from ''within'' your script code.
<<<
!!!!!$(...) 'shorthand' function
<<<
As described by Dustin Diaz [[here|http://www.dustindiaz.com/top-ten-javascript/]], the plugin defines a 'shorthand' function that allows you to write:
{{{
$(id)
}}}
in place of the normal standard javascript syntax:
{{{
document.getElementById(id)
}}}
This function is provided merely as a convenience for javascript coders that may be familiar with this abbreviation, in order to allow them to save a few bytes when writing their own inline script code.
<<<
!!!!!Examples
<<<
simple dynamic output:
><script show>
document.write("The current date/time is: "+(new Date())+"<br>");
return "link to current user: [["+config.options.txtUserName+"]]\n";
</script>
dynamic output using 'place' to get size information for current tiddler:
><script show>
if (!window.story) window.story=window;
var title=story.findContainingTiddler(place).getAttribute("tiddler");
var size=store.getTiddlerText(title).length;
return title+" is using "+size+" bytes";
</script>
dynamic output from an 'onclick' script, using {{{document.write()}}} and/or {{{return "..."}}}
><script label="click here" show>
document.write("<br>The current date/time is: "+(new Date())+"<br>");
return "link to current user: [["+config.options.txtUserName+"]]\n";
</script>
creating an 'onclick' button/link that accesses the link text AND the containing tiddler:
><script label="click here" title="clicking this link will show an 'alert' box" key="H" show>
if (!window.story) window.story=window;
var txt=place.firstChild.data;
var tid=story.findContainingTiddler(place).getAttribute('tiddler');
alert('Hello World!\nlinktext='+txt+'\ntiddler='+tid);
</script>
dynamically setting onclick link text based on stateful information:
>{{block{
{{{
<script label="click here">
/* toggle "txtSomething" value */
var on=(config.txtSomething=="ON");
place.innerHTML=on?"enable":"disable";
config.txtSomething=on?"OFF":"ON";
return "\nThe current value is: "+config.txtSomething;
</script><script>
/* initialize onclick link text based on current "txtSomething" value */
var on=(config.txtSomething=="ON");
place.lastChild.previousSibling.innerHTML=on?"disable":"enable";
</script>
}}}
<script label="click here">
/* toggle "txtSomething" value */
var on=(config.txtSomething=="ON");
place.innerHTML=on?"enable":"disable";
config.txtSomething=on?"OFF":"ON";
return "\nThe current value is: "+config.txtSomething;
</script><script>
/* initialize onclick link text based on current "txtSomething" value */
var on=(config.txtSomething=="ON");
place.lastChild.innerHTML=on?"enable":"disable";
</script>
}}}
loading a script from a source url:
>http://www.TiddlyTools.com/demo.js contains:
>>{{{function inlineJavascriptDemo() { alert('Hello from demo.js!!') } }}}
>>{{{displayMessage('InlineJavascriptPlugin: demo.js has been loaded');}}}
>note: When using this example on your local system, you will need to download the external script file from the above URL and install it into the same directory as your document.
>
><script src="demo.js" show>
return "inlineJavascriptDemo() function has been defined"
</script>
><script label="click to invoke inlineJavascriptDemo()" key="D" show>
inlineJavascriptDemo();
</script>
<<<
!!!!!Revisions
<<<
2009.02.26 [1.9.4] in $(), handle leading '#' on ID for compatibility with JQuery syntax
2008.06.11 [1.9.3] added $(...) function as 'shorthand' for document.getElementById()
2008.03.03 [1.9.2] corrected fallback declaration of wikifyPlainText() (fixes Safari "parse error")
2008.02.23 [1.9.1] in onclick function, use string instead of array for 'bufferedHTML' (fixes IE errors)
2008.02.21 [1.9.0] output from 'onclick' scripts (return value or document.write() calls) are now buffered and rendered into into a span following the script. Also, added default 'return false' handling if no return value provided (prevents HREF from being triggered -- return TRUE to allow HREF to be processed). Thanks to Xavier Verges for suggestion and preliminary code.
2008.02.14 [1.8.1] added backward-compatibility for use of wikifyPlainText() in TW2.1.3 and earlier
2008.01.08 [*.*.*] plugin size reduction: documentation moved to ...Info tiddler
2007.12.28 [1.8.0] added support for key="X" syntax to specify custom access key definitions
2007.12.15 [1.7.0] autogenerate URI encoded HREF on links for onclick scripts. Drag links to browser toolbar to create bookmarklets. IMPORTANT NOTE: place is NOT defined when scripts are used as bookmarklets. In addition, double-quotes will cause syntax errors. Thanks to PaulReiber for debugging and brainstorming.
2007.11.26 [1.6.2] when converting "document.write()" function calls in inline code, allow whitespace between "write" and "(" so that "document.write ( foobar )" is properly converted.
2007.11.16 [1.6.1] when rendering "onclick scripts", pass label text through wikifyPlainText() to parse any embedded wiki-syntax to enable use of HTML entities or even TW macros to generate dynamic label text.
2007.02.19 [1.6.0] added support for title="..." to specify mouseover tooltip when using an onclick (label="...") script
2006.10.16 [1.5.2] add newline before closing '}' in 'function out_' wrapper. Fixes error caused when last line of script is a comment.
2006.06.01 [1.5.1] when calling wikify() on script return value, pass hightlightRegExp and tiddler params so macros that rely on these values can render properly
2006.04.19 [1.5.0] added 'show' parameter to force display of javascript source code in tiddler output
2006.01.05 [1.4.0] added support 'onclick' scripts. When label="..." param is present, a button/link is created using the indicated label text, and the script is only executed when the button/link is clicked. 'place' value is set to match the clicked button/link element.
2005.12.13 [1.3.1] when catching eval error in IE, e.description contains the error text, instead of e.toString(). Fixed error reporting so IE shows the correct response text. Based on a suggestion by UdoBorkowski
2005.11.09 [1.3.0] for 'inline' scripts (i.e., not scripts loaded with src="..."), automatically replace calls to 'document.write()' with 'place.innerHTML+=' so script output is directed into tiddler content. Based on a suggestion by BradleyMeck
2005.11.08 [1.2.0] handle loading of javascript from an external URL via src="..." syntax
2005.11.08 [1.1.0] pass 'place' param into scripts to provide direct DOM access
2005.11.08 [1.0.0] initial release
<<<
There is such an animal. It is quite related to what we wanted with DCTL*, ro to what process logic does. There obviously are tools for system specification with ITL. Among other features it also features the //chop// operator.
* [[The main link|http://www.cse.dmu.ac.uk/STRL/ITL//]]
* [[A PhD thesis on real-time system specification with ITL|http://www.csc.liv.ac.uk/~konur/Papers/PhD.pdf]]
SHOP (Simple Hierarchical Ordered Planner), JSHOP, and SHOP2 are domain-independent automated-planning systems. They are based on ordered task decomposition, which is a type of Hierarchical Task Network (HTN) planning.
[[SHOP homepage|http://www.cs.umd.edu/projects/shop/description.html]]
The BSM code patterns should also be related to the Wooldridge's work referred to in the paper [[Vokrinek, Komenda & Pechoucek: Decommitting in Multi-agent Execution in Non-deterministic Environment: Experimental Approach]], i.e., e.g., [[Wooldridge & Jennings: Cooperative Problem Solving]].
First of all, the ACHIEVE patterns already implements an instance of the formalization of the //commitment// as described in [[JVO/TKO/MPE|Vokrinek, Komenda & Pechoucek: Decommitting in Multi-agent Execution in Non-deterministic Environment: Experimental Approach]]. What they call //commitment condition// is an ADOPT condition, the //decommitment condition// is the DROP condition. However, the difference is that they consider a //social// setting, i.e., some of the drop rules must involve informing the rest of the team (see notes from reading the [[Cohen and Levesque's teamwork paper|Cohen & Levesque: Teamwork]]).
If we can implement C&L's work as well as Wolldridge's formalizations, the following question arises:
<<<
Q: @@Is the strong reactivity promoted by the BSM framework the key to provability of the nice properties w.r.t., C&L, Wooldridge, or Rao&Georgeff's BDI?@@
A: I would guess it is at least very much beneficial.
<<<
[[homepage|http://ii.fmph.uniba.sk/~sefranek/]]
* [[Collaboration: JSE@DAI@FMPH]]
Programming language for [[Behavioural State Machines]].
* published under GNU/GPLv2, i.e., open source
* homepage: http://jazzyk.sourceforge.net/
There should be a very simple way to add GUI interaction with end-users to Jazzyk. I should invest some time and develop a bash KR module. The the following things would be easy to use as well:
[[10 Tools To Add Some Spice To Your UNIX Shell Scripts|http://www.cyberciti.biz/tips/spice-up-your-unix-linux-shell-scripts.html]]
[[http://eprints.ecs.soton.ac.uk/2090/]]
* check briefly. The content is probably already distilled in [[Jennings: Coordination Techniques for Distributed Artificial Intelligence]].
@@ N.R. Jennings: //Coordination Techniques for Distributed Artificial Intelligence//, Published in: Foundations of distributed artificial intelligence, 1996, John Wiley & Sons, Inc. New York, NY, USA
-- [[link|http://eprints.ecs.soton.ac.uk/2187/1/FOUND-DAI-COORD.pdf]]
@@
!! Summary
A book chapter (i.e., an educational type of paper) which 1) introduces a conceptual framework for speaking about coordination in MASs (or generally in DAI), and subsequently 2) argues and defends it by surveying then-state-of-the-art coordination techniques, such as organizations, meta-level information exchange and multi-agent planning, and showing that they can be well described by the framework introduced.
The central thesis of the chapter is that
<<<
@@''All coordination mechanisms can ultimately be reduced to //commitments// and their associated //conventions//.''
-- ([[Jennings, 1993|Jennings: Commitments and conventions: The Foundation of Coordination in Multi-Agent Systems]])@@
<<<
In particular, the author builds upon the [[Victor Lesser]]'s //goal-graph// formalism and proposed modelling of //Distributed AI Systems// in terms of //Distributed Goal Search Problems//. He explains the concepts of
# Commitments
# Joint Commitments
# Conventions
# Social Conventions
and argues for the following schematics:
''Coordination = Commitments + Conventions + Social Conventions + Local Reasoning''
----
!! Opinion and assorted thoughts
Generally, the paper is a very good introductory material into the topic of coordination and provided me a good share of inspiration regarding positioning the work within the TAS project. This definitely is something to cite and refer to later. An important part of the paper is a thorough argument why centralized systems cannot do well in many settings and why coordination is important not only from a conceptual point of view, but mainly from the technical/pragmatic one.
!!! Observations/quotes
* the paper articulates the view that the problem of coordination is central to the field of Distributed Artificial Intelligence
* the author takes the view that coordination is a means for managing the otherwise prevalent and looming chaos - this relates to the raison d'etre of coordination discussed in [[The Interdisciplinary Study of Coordination]].
* mentions the //combinatorial implosion// put forward by Kornfield and Hewitt (1981). Interesting concept for the phenomenon based on the observation that //two agents can solve the problem more than twice as fast as an individual//(?).
** @@Interesting... Is this really so? How do they argue for this???@@
* there obviously is a trade-off between //sticking to (social) commitments// vs. the //ability to react to unexpected changes//, i.e., a dynamic environment.
** this is even more so in a multi-agent setup in which social commitments are a means for reducing the //team unpredictability//
!!! Goal dependencies
* resource dependencies can be removed simply by providing more of the resource in question. However, dependencies between goals cannot be circumvented as they are a logical consequence of the community environment (the social structure).
* there are //strong// and //weak// goal dependencies.
** strong must be satisfied in order for the dependent goal to succeed
** weak constrain the problem solving, but do not need to be satisfied for the dependent goal to succeed
* the joint goal decomposition has to be done somewhere: either centralized in a single agent, or implicitly in that everybody is informed equally about the options $\rightarrow$ [[Positioning the coordination in TAS]]
* From the goal-dependency graph it's obvious that there are multi-agent activities involved:
## defining the graph
## assigning particular regions of the graph to individual team members
## controlling decisions about the graph exploration
## traversing the graph
## ensuring that successful traversal is performed
** in the TAS project we do care for the point ''2''
!!! Other
<<<
@@Individual commitment involving a single agent is equivalent to an individual commitment.@@
* this ''must'' translate well to Agent-Oriented Programming!
<<<
* interestingly, Kinny and Georgeff (1991) found that //bold// agents are generally more successful in their activities than //normal// agents (which sometimes reconsider their commitments) and these perform better than //cautious// agents, which are prone to a frequent reconsideration.
From the analysis of the concepts proposed, I see that
# the object of a (social) commitment is a matter of local reasoning (in a BSM by a local KR module) - designer's competence
# the activity towards the commitment is a matter of single-agent programming/planning - programmer's competence
# the (social) commitment is a matter of my own interest, i.e., their re-usable engineering w.r.t. various objects+activities
** it is important to note that //social commitments must translate to individual commitments in a transparent and clear manner// - this is the task of my own research interest!!!
# the (social) convention is a meta-property of the employed programming language interpreter
** in my terms, this is something I also do care for as BSM can implement these as well. Actually my re-usable BSM commitment implementations are such conventions w.r.t. goals.
*** ''re-usable commitment patterns are actually conventions!!!'' - ''IMPORTANT OBSERVATION!!!''
* social conventions actually tell us //when to communicate// in the coordination pattern. I.e., the idea is useful as a separation of concerns between the behaviour itself and the communication activity.
* clearly, we are dealing with some simple case of organizational coordination. Definitely the TAS problems cannot be dealt with by multi-agent planning. Perhaps the meta-information exchange is worth to study more, although I doubt it.
!!! Historical note
It seems to me that the 1990's and early 2000's were the time of problem definition and analysis and nowadays we live in the period of implementation of DAI. Perhaps that's why we do not have too many successes...
!! Resulting notes
* [[Positioning the coordination in TAS]]
* [[Lesser: A retrospective view of FA/C distributed problem solving]]
* perhaps I should check the cited Decker's work on //Distributed Vehicle Monitoring Testbed// - it can be useful for the TAS project
Has a whole library of notes on behaviour based/reactive planning, AI, etc.
[[Homepage|http://www.cs.bath.ac.uk/~jjb/]]
[[Research overview|http://www.cs.bath.ac.uk/~jjb/web/related-research.html]]
[[Action Selection|http://www.cs.bath.ac.uk/~jjb/web/as.html]]
[[Dissertation|ftp://publications.ai.mit.edu/ai-publications/2002/AITR-2002-003.pdf]]
[[homepage|http://www.in.tu-clausthal.de/abteilungen/cig/cigroot/members/leaders/prof-dr-juergen-dix/]]
* [[Collaboration: JDI@CIG@CUT]]
A book by [[Chitta Baral]] on [[Answer Set Programming]]. Check here http://www.baral.us/bookone/.
Homepage: http://mmi.tudelft.nl/~koen/
Papers: http://mmi.tudelft.nl/index.php?option=com_contact&task=view&id=113
[[GOAL]]
Check!!! Language by Sycara...
! Negative normal form
//Negation appears only in front of propositional literals//
The following identities allow to derive a formula in the NNF:
* $\neg \neg \phi \equiv \phi $
* $\neg \square \phi \equiv \lozenge \neg \phi$
* $\neg \lozenge \phi \equiv \square \neg \phi$
* $\neg (\varphi \mathcal{U} \psi) \equiv (\neg \varphi) \mathcal{R} (\neg \psi) $
* $\neg (\varphi \mathcal{R} \psi) \equiv (\neg \varphi) \mathcal{U} (\neg \psi) $
A very nice brief introduction to how science works, what to believe and what sounds/seems dubious. To be handed out to anyone trying to understand some science, especially from popular sources, such as daily newspapers...
[[http://www.senseaboutscience.org.uk/]]
[[http://www.senseaboutscience.org.uk/pdf/ShortPeerReviewGuide.pdf]]
* check including all the forward citations - this can give a good overview of the field and reasons for its fade-out (hypothesis)
Book and a course on //Algorithmic Information Theory// by Gregory Chaitin.
http://www.umcs.maine.edu/~chaitin/lm.html
/***
This is a revision of the listTags plugin — [[I|Garrett Lisi]] mashed this up with Udo's big plugin.
!!Usage
{{{
<<ListTagged tag>>
}}}
!!!Code
***/
/*{{{*/
version.extensions.ListTagged = {major: 0, minor: 1, revision: 1};
config.macros.ListTagged = {
text: "Hello"
};
config.macros.ListTagged.handler = function(place,macroName,params)
{
var notes = store.getTaggedTiddlers(params[0]);
var list = document.createElement("ul");
place.appendChild(list);
for (var i = 0; i < notes.length; i++) {
var note = notes[i];
var listItem = document.createElement("li");
list.appendChild(listItem);
createTiddlyLink(listItem, note.title, true);
}
}
/*}}}*/
A paper on Math education. Very much about education in general. Very good comments in there.
http://www.maa.org/devlin/LockhartsLament.pdf
//By removing the creative process and leaving only the results of that process, you virtually
guarantee that no one will have any real engagement with the subject.//
@@[[Michael Schumacher]]: //Objective Coordination in Multi-Agent System Engineering//, LNAI 2039, Springer
-- [[link|http://www.springer.com/computer/artificial/book/978-3-540-41982-2]]
@@
!! Summary
* TBD
!! Assorted notes
* The book features a very good introduction (Part //'Positioning//). It is a general intro into multi-agent systems, their taxonomy and various aspects. Good reading and perhaps a good reference to the introduced nomenclature and taxonomy.
* additionally, the intro provides a good amount of references, thus it can be used as a survey paper and a source of info about fields. The downside is that it's a bit outdates (2001), yet very valuable.
* Sec. 3.4 Process-oriented Coordination Models:
<<<
//the state of the computation at any moment in time is defined in terms of only the coordinated patterns that the processes involved in some computation adhere to//
<<<
!! Some of the resulting references
[[S. Ossowski: Coordination in Artificial Agent Societes]]
[[Jennings: Coordination Techniques for Distributed Artificial Intelligence]]
[[About]] [[Events|Upcoming events]] [[Recent Changes]] || || [[]] [[TAS|Prj: TAS project]] [[APL|Trk: APL track]] [[MASPlan|Trk: MASPlan track]] [[GT/Adver|Trk: GT/Adver track]]
Interesting paper on manifold AnsProlog programs. The core idea is to transform the original AnsProlog program into a //product// program. Then in answer sets one can check for each literal a //witness//. I.e., for every literal we can cross-check whether every other literal also belongs to the same answer set. That way they can say also how //many times// literals belong to answer sets and thus solve AnsProlog query regarding //all the answer sets//.
http://www.dbai.tuwien.ac.at/research/project/argumentation/FaberW09.pdf
Abstract: We will discuss the development of a Knowledge Base (KB) System, for a rich KB language, equipped with several forms of inference able to solve different sorts of tasks using the same KB. The logic FO(.) used in our KBS project is an extension of classical logic with various language primitives such as inductive definitions, aggregates, arithmetic, etc. It is also a natural integration (and further extension) of classical logic and logic programming, based on the view of a logic program as a definition. We discuss informal and formal semantics of definitions in FO(.) and briefly consider the relationship with other knowledge principles such as coinduction, the closed world assumption and causality and with the LP formalisms ASP, ALP and deductive databases. On the computational level, we will report on current attempts to build finite domain inference systems for model expansion, approximate reasoning, theory debugging and model revision, with special focus on the IDP-system, a model expansion system for FO(.) competitive with the best ASP-solvers.
Call PEOPLE Calls: ''FP7-PEOPLE-2009-IEF''
http://cordis.europa.eu/fp7/dc/index.cfm?fuseaction=UserSite.PeopleDetailsCallPage&call_id=198
* add the communication with NCP!
<!--{{{-->
<link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml'/>
<style type="text/css">body {background:black;#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #848484; display: block; text-align: center; width: 320px; margin: 170px auto; padding: 50px; color:white; font-size: 26px; font-family:Verdana, Helvetica, sans-serif;; background-color:#ff8614;"><span style="font-family: 'Trebuchet MS' sans-serif;
font-weight: bold;
font-size: 32px;color:white;font-weight:bold;">Mental State</span><br> is loading<blink> ...</blink></div>
<!--}}}-->
/***
|Name|MatchTagsPlugin|
|Source|http://www.TiddlyTools.com/#MatchTagsPlugin|
|Documentation|http://www.TiddlyTools.com/#MatchTagsPluginInfo|
|Version|2.0.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|'tag matching' with full boolean expressions (AND, OR, NOT, and nested parentheses)|
!!!!!Documentation
> see [[MatchTagsPluginInfo]]
!!!!!Revisions
<<<
2008.09.04 [2.0.0] added "report" and "panel" options to generate formatted results and store in a tiddler. Also, added config.macros.matchTags.formatList(place,fmt,sep) API to return formatted output for use with other plugins/scripts
| please see [[MatchTagsPluginInfo]] for additional revision details |
2008.02.28 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.MatchTagsPlugin= {major: 2, minor: 0, revision: 0, date: new Date(2008,9,4)};
// store.getMatchingTiddlers() processes boolean expressions for tag matching
// sortfield (optional) sets sort order for tiddlers - default=title
// tiddlers (optional) use alternative set of tiddlers (instead of current store)
TiddlyWiki.prototype.getMatchingTiddlers = function(tagexpr,sortfield,tiddlers) {
var debug=config.options.chkDebug; // abbreviation
var cmm=config.macros.matchTags; // abbreviation
var r=[]; // results are an array of tiddlers
var tids=tiddlers||store.getTiddlers(sortfield||"title");
if (tiddlers && sortfield) store.sortTiddlers(tids,sortfield);
if (debug) displayMessage(cmm.msg1.format([tids.length]));
// try simple lookup to quickly find single tags or tags that
// contain boolean operators as literals, e.g. "foo and bar"
for (var t=0; t<tids.length; t++)
if (tids[t].isTagged(tagexpr)) r.pushUnique(tids[t]);
if (r.length) {
if (debug) displayMessage(cmm.msg4.format([r.length,tagexpr]));
return r;
}
// convert expression into javascript code with regexp tests,
// so that "tag1 AND ( tag2 OR NOT tag3 )" becomes
// "/\~tag1\~/.test(...) && ( /\~tag2\~/.test(...) || ! /\~tag3\~/.test(...) )"
// normalize whitespace, tokenize operators, delimit with "~"
var c=tagexpr.trim(); // remove leading/trailing spaces
c = c.replace(/\s+/ig," "); // reduce multiple spaces to single spaces
c = c.replace(/\(\s?/ig,"~(~"); // open parens
c = c.replace(/\s?\)/ig,"~)~"); // close parens
c = c.replace(/(\s|~)?&&(\s|~)?/ig,"~&&~"); // &&
c = c.replace(/(\s|~)AND(\s|~)/ig,"~&&~"); // AND
c = c.replace(/(\s|~)?\|\|(\s|~)?/ig,"~||~"); // ||
c = c.replace(/(\s|~)OR(\s|~)/ig,"~||~"); // OR
c = c.replace(/(\s|~)?!(\s|~)?/ig,"~!~"); // !
c = c.replace(/(^|~|\s)NOT(\s|~)/ig,"~!~"); // NOT
c = c.replace(/(^|~|\s)NOT~\(/ig,"~!~("); // NOT(
// change tag terms to regexp tests
var terms=c.split("~"); for (var i=0; i<terms.length; i++) { var t=terms[i];
if (/(&&)|(\|\|)|[!\(\)]/.test(t) || t=="") continue; // skip operators/parens/spaces
if (t==config.macros.matchTags.untaggedKeyword)
terms[i]="tiddlertags=='~~'"; // 'untagged' tiddlers
else
terms[i]="/\\~"+t+"\\~/.test(tiddlertags)";
}
c=terms.join(" ");
if (debug) { displayMessage(cmm.msg2.format([tagexpr])); displayMessage(cmm.msg3.format([c])); }
// scan tiddlers for matches
for (var t=0; t<tids.length; t++) {
// assemble tags from tiddler into string "~tag1~tag2~tag3~"
var tiddlertags = "~"+tids[t].tags.join("~")+"~";
try { if(eval(c)) r.push(tids[t]); } // test tags
catch(e) { // error in test
displayMessage(cmm.msg2.format([tagexpr]));
displayMessage(cmm.msg3.format([c]));
displayMessage(e.toString());
break; // skip remaining tiddlers
}
}
if (debug) displayMessage(cmm.msg4.format([r.length,tagexpr]));
return r;
}
//}}}
//{{{
config.macros.matchTags = {
msg1: "scanning %0 input tiddlers",
msg2: "looking for '%0'",
msg3: "using expression: '%0'",
msg4: "found %0 tiddlers matching '%1'",
noMatch: "no matching tiddlers",
untaggedKeyword: "-",
untaggedLabel: "no tags",
untaggedPrompt: "show tiddlers with no tags",
defTiddler: "MatchingTiddlers",
defFormat: "%0",
defSeparator: "\n",
reportHeading: "Found %0 tiddlers tagged with: '{{{%1}}}'\n----\n",
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var mode=params[0]?params[0].toLowerCase():'';
if (mode=="inline")
params.shift();
if (mode=="report" || mode=="panel") {
params.shift();
var target=params.shift()||this.defTiddler;
}
if (mode=="popup") {
params.shift();
if (params[0]&¶ms[0].substr(0,6)=="label:") var label=params.shift().substr(6);
if (params[0]&¶ms[0].substr(0,7)=="prompt:") var prompt=params.shift().substr(7);
} else {
var fmt=(params.shift()||this.defFormat).unescapeLineBreaks();
var sep=(params.shift()||this.defSeparator).unescapeLineBreaks();
}
var sortBy="+title";
if (params[0]&¶ms[0].substr(0,5)=="sort:") sortBy=params.shift().substr(5);
var expr = params.join(" ");
if (mode!="panel" && (!expr||!expr.trim().length)) return;
if (expr==this.untaggedKeyword)
{ var label=this.untaggedLabel; var prompt=this.untaggedPrompt };
switch (mode) {
case "popup": this.createPopup(place,label,expr,prompt,sortBy); break;
case "panel": this.createPanel(place,expr,fmt,sep,sortBy,target); break;
case "report": this.createReport(target,expr,fmt,sep,sortBy); break;
case "inline": default: this.createInline(place,expr,fmt,sep,sortBy); break;
}
},
formatList: function(tids,fmt,sep) {
var out=[];
for (var t=0; t<tids.length; t++) {
var title="[["+tids[t].title+"]]";
var who=tids[t].modifier;
var when=tids[t].modified.toLocaleString();
var text=tids[t].text;
var first=tids[t].text.split("\n")[0];
var desc=store.getTiddlerSlice(tids[t].title,"description");
desc=desc||store.getTiddlerSlice(tids[t].title,"Description");
desc=desc||store.getTiddlerText(tids[t].title+"##description");
desc=desc||store.getTiddlerText(tids[t].title+"##Description");
out.push(fmt.format([title,who,when,text,first,desc]));
}
return out.join(sep);
},
createInline: function(place,expr,fmt,sep,sortBy) {
wikify(this.formatList(store.sortTiddlers(store.getMatchingTiddlers(expr),sortBy),fmt,sep),place);
},
createPopup: function(place,label,expr,prompt,sortBy) {
var btn=createTiddlyButton(place,
(label||expr).format([expr]),
(prompt||config.views.wikified.tag.tooltip).format([expr]),
function(ev){ return config.macros.matchTags.showPopup(this,ev||window.event); });
btn.setAttribute("sortBy",sortBy);
btn.setAttribute("expr",expr);
},
showPopup: function(here,ev) {
var p=Popup.create(here); if (!p) return false;
var tids=store.getMatchingTiddlers(here.getAttribute("expr"));
store.sortTiddlers(tids,here.getAttribute("sortBy"));
var list=[]; for (var t=0; t<tids.length; t++) list.push(tids[t].title);
if (!list.length) createTiddlyText(p,this.noMatch);
else {
var b=createTiddlyButton(createTiddlyElement(p,"li"),
config.views.wikified.tag.openAllText,
config.views.wikified.tag.openAllTooltip,
function() {
var list=this.getAttribute("list").readBracketedList();
story.displayTiddlers(null,tids);
});
b.setAttribute("list","[["+list.join("]] [[")+"]]");
createTiddlyElement(p,"hr");
}
var out=this.formatList(tids," %0 ","\n"); wikify(out,p);
Popup.show();
ev.cancelBubble=true;
if(ev.stopPropagation) ev.stopPropagation();
return false;
},
createReport: function(target,expr,fmt,sep,sortBy) {
var tids=store.sortTiddlers(store.getMatchingTiddlers(expr),sortBy);
if (!tids.length) { displayMessage('no matches for: '+expr); return false; }
var msg=config.messages.overwriteWarning.format([target]);
if (store.tiddlerExists(target) && !confirm(msg)) return false;
var out=this.reportHeading.format([tids.length,expr])
out+=this.formatList(tids,fmt,sep);
store.saveTiddler(target,target,out,config.options.txtUserName,new Date(),[],{});
story.closeTiddler(target); story.displayTiddler(null,target);
},
createPanel: function(place,expr,fmt,sep,sortBy,tid) {
var html="<form style='display:inline'><!-- \
--><input type='text' name='expr' style='width:55%' title='tag expression'><!-- \
--><input type='text' name='fmt' style='width:10%' title='list item format'><!-- \
--><input type='text' name='sep' style='width:5%' title='list item separator'><!-- \
--><input type='text' name='tid' style='width:20%' title='target tiddler title'><!-- \
--><input type='button' name='go' style='width:8%' value='go' onclick=\" \
var expr=this.form.expr.value; \
if (!expr.length) { alert('Enter a boolean tag expression'); return false; } \
var fmt=this.form.fmt.value; \
if (!fmt.length) { alert('Enter the list item output format'); return false; } \
var sep=this.form.sep.value.unescapeLineBreaks(); \
var tid=this.form.tid.value; \
if (!tid.length) { alert('Enter a target tiddler title'); return false; } \
config.macros.matchTags.createReport(tid,expr,fmt,sep,'title'); \
return false;\"> \
</form>";
var s=createTiddlyElement(place,"span"); s.innerHTML=html;
var f=s.getElementsByTagName("form")[0];
f.expr.value=expr; f.fmt.value=fmt; f.sep.value=sep.escapeLineBreaks(); f.tid.value=tid;
}
};
//}}}
//{{{
// SHADOW TIDDLER for displaying default panel input form
config.shadowTiddlers.MatchTags="{{smallform{<<matchTags panel>>}}}";
//}}}
//{{{
// TWEAK core filterTiddlers() for enhanced boolean matching in [tag[...]] syntax:
// use getMatchingTiddlers instead getTaggedTiddlers
var fn=TiddlyWiki.prototype.filterTiddlers;
fn=fn.toString().replace(/getTaggedTiddlers/g,"getMatchingTiddlers");
eval("TiddlyWiki.prototype.filterTiddlers="+fn);
//}}}
//{{{
// REDEFINE core handler for enhanced boolean matching in tag:"..." paramifier
// use filterTiddlers() instead of getTaggedTiddlers() to get list of tiddlers.
config.paramifiers.tag = {
onstart: function(v) {
var tagged = store.filterTiddlers("[tag["+v+"]]");
story.displayTiddlers(null,tagged,null,false,null);
}
};
//}}}
/***
|Name|MatchTagsPluginInfo|
|Source|http://www.TiddlyTools.com/#MatchTagsPlugin|
|Documentation|http://www.TiddlyTools.com/#MatchTagsPluginInfo|
|Version|2.0.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|documentation|
|Requires||
|Overrides||
|Description|documentation for MatchTagsPlugin|
!!!!!Usage
<<<
This plugin extends the {{{[tag[tagname]]}}} macro parameter syntax used by the TiddlyWiki core {{{<<list>>}}} macro so that, instead of a simple tagname value, you can specify a complex combination of tagname values using a //boolean expression// containing AND, OR, and NOT operators, enclosed in nested parentheses if needed.
{{{
<<list filter "[tag[expression]]">>
}}}
In addition, the plugin defines a new macro, {{{<<matchTags ...>>}}} that can be used instead of the core {{{<<list>>}}} macro to output a list of matching tiddlers //using a custom 'item format' and 'separator'//. You can also use this macro to create a command link that displays the matching tiddlers within a popup list, similar to the standard {{{<<tag tagName>>}}} macro, but matching a combination of tag values rather than a single tag value.
{{{
<<matchTags inline "format" "separator" sort:fieldname tag expression>>
<<matchTags popup "label:..." "prompt:..." sort:fieldname tag expression>>
<<matchTags report TiddlerName "format" "separator" sort:fieldname tag expression>>
<<matchTags panel Tiddlername "format" "separator" sort:fieldname tag expression>>
}}}
where:
* ''inline'', ''report'', ''panel'', and ''popup''<br>are keywords that indicate the type of output that the macro should produce:
** ''inline'' //(default)// - displays a list of matching tiddlers embedded directly in tiddler content
** ''popup'' - embeds a command button that, when clicked, lists matching tiddlers in a ~TiddlyWiki popup display
** ''report'' - generates a list of matching tiddler in a separate [[MatchingTiddlers]] report tiddler
** ''panel'' - displays an interactive form for generating a [[MatchingTiddlers]] report
* ''format''<br>defines the wiki-syntax for rendering list items. The following //substitution markers// can be used to insert tiddler-specific information for each matched tiddler:
** {{{%0}}} - title
** {{{%1}}} - modifier (author)
** {{{%2}}} - modified (date of last change)
** {{{%3}}} - text (all tiddler content)
** {{{%4}}} - firstline (tiddler content up to the first newline)
** {{{%5}}} - description (tiddler slice or section content named "description" or "Description")
* ''separator''<br>defines the wiki-syntax to use //between// each matching title (e.g., ", " creates a comma-separated list, while "\n" displays one tiddler per line).
* ''sort:fieldname'' (optional)<br>specifies the sort order for the resulting list of tiddlers. You can specify any tiddler field name (standard or custom-defined). Standard tiddler fieldnames include: //title, created, modified, modifier//. If not specified, tiddlers are sorted by title. You can prefix the fieldname with "+" or "-" to indicate ascending or descending order, respectively.
* ''tag expression''<br>the remaining parameter(s) are joined together to define the boolean expression to be matched.
When using the ''popup'' option, there are two additional (and optional) parameters you can specify:
* ''"label:..."''(optional)<br> indicates the text for the popup command link. The default is to display the specified tag expression itself.
* ''"prompt:..."'' (optional)<br>indicates the mouseover 'tooltip' for the popup command link.
When using the ''report'' or ''panel'' option, an additional parameter may be provided:
* ''~TiddlerName''<br>specifies the target tiddler into which the output will be generated (default: [[MatchingTiddlers]])
Notes:
*A tag expression can use any combination of text operators: ''AND'', ''OR'', ''NOT'' (or their equivalent javascript operators: ''&&'', ''||'', ''!''), contained in nested parentheses as needed.
*Operators should be delimited by spaces or parentheses.
*Before matching, leading/trailing spaces are automatically trimmed and multiple spaces are reduced to single spaces.
*Tag values containing embedded spaces do //not// have to be enclosed in {{{[[...]]}}}.
*Tag values that contain boolean operators as ''literal text'' (e.g., {{{"foo and bar"}}} or {{{"foo && bar"}}} cannot be used within a compound boolean expression, but //can// be matched if specified by themselves, without any other tag values or operators.
*To match tiddlers that are untagged, use "-" as a special tag value within the expression.
*You can match "wildcard" tags by using //regular expression// (i.e., "text pattern") syntax within a tag value, e.g. {{{[Tt]agvalue.*}}}
<<<
!!!!!Examples:
<<<
display a popup list:
{{{
<<matchTags popup sample OR (settings AND systemConfig)>>
}}}
><<matchTags popup sample OR (settings AND systemConfig)>>
display a popup list with custom label:
{{{
<<matchTags popup "label:samples and settings" sample OR (settings AND systemConfig)>>
}}}
><<matchTags popup "label:samples and settings" sample OR (settings AND systemConfig)>>
display a popup list of untagged tiddlers:
{{{
<<matchTags popup ->>
}}}
><<matchTags popup ->>
generate a report using interactive form control panel
{{{
<<matchTags panel "MatchingTiddlers" "%0" "\n" sample OR (settings AND systemConfig)>>
}}}
>{{smallform{<<matchTags panel "MatchingTiddlers" "%0" "\n" sample OR (settings AND systemConfig)>>}}}
comma-separated list:
{{{
<<matchTags "%0" ", " sample OR (settings AND systemConfig)>>
}}}
><<matchTags "%0" ", " sample OR (settings AND systemConfig)>>
numbered list (sorted by modification date, most recent first):
{{{
<<matchTags "#%0 (%2)<br>^^%5^^" "\n" sort:-modified sample OR (settings AND systemConfig)>>
}}}
><<matchTags "#%0 (%2)<br>^^%5^^" "\n" sort:-modified sample OR (settings AND systemConfig)>>
bullet-item list (using the TiddlyWiki core {{{<<list filter ...>>}}} macro):
//(Note: when using the core {{{<<list>>}}} macro, you should always enclose the entire tag filter parameter within quotes)//
{{{
<<list filter "[tag[sample OR (settings AND systemConfig)]]">>
}}}
><<list filter "[tag[sample OR (settings AND systemConfig)]]">>
<<<
!!!!!Revisions
<<<
2008.09.04 [2.0.0] added "report" and "panel" options to generate formatted results and store in a tiddler. Also, added config.macros.matchTags.formatList(place,fmt,sep) API to return formatted output for use with other plugins/scripts
2008.09.01 [1.9.2] fixed return value from popup button handler so IE doesn't attempt to leave the page
2008.08.31 [1.9.1] improved expression conversion handling to permit use of regular expressions for "wildcard" matching within tag values
2008.06.12 [1.9.0] added support for formatted output of: title, who, when, text, firstline, description (slice or section)
2008.06.05 [1.8.0] in getMatchingTiddlers(), added optional sortfield and tiddlers params to support use of alternative set of tiddlers instead of using current store content (provides filtering support for ImportTiddlersPlugin)
2008.06.04 [1.7.1] in getMatchingTiddlers(), reworked conversion of expression for more robust parsing of whitespace, parentheses and javascript operators and allow use of "-" (untagged) //within// expressions
2008.05.19 [1.7.0] in getMatchingTiddlers(), use reverseLookup() instead of forEachTiddler() to permit access to tiddlers included via [[IncludePlugin|http://tiddlywiki.abego-software.de/#IncludePlugin]]
2008.05.17 [1.6.0] in getMatchingTiddlers(), rewrote expression conversion to handle tags with spaces tag values that are substrings of other tag values.
2008.05.16 [1.5.0] added special case using "-" to find UNTAGGED tiddlers
2008.05.15 [1.4.0] added "popup" output option
2008.05.14 [1.3.4] instead of hijacking getTaggedTiddlers(), added tweak of filterTiddlers() prototype to replace getTaggedTiddlers() with getMatchingTiddler() so that core use of getTaggedTiddlers() does not perform boolean processing of tiddler titles such as [[To Be or not To Be]]. Also, improved "filter error" messages in getMatchingTiddlers() to report tag expression in addition to actual eval error.
2008.04.25 [1.3.3] in getTaggedTiddlers(), fixed handling for "not" embedded within a tag
2008.04.21 [1.3.2] in getTaggedTiddlers(), fixed handling for initial "NOT" and "NOT(expr)" syntax
2008.04.20 [1.3.1] in getTaggedTiddlers(), corrected check for boolean expression to avoid excess processing of tags containing spaces. Also, improved handling for non-existing tags that contain text of existing tags
2008.04.19 [1.3.0] in filterTiddlers(), use getTaggedTiddlers() instead of matchTags(), and then hijack getTaggedTiddlers() to add matchTags() handling
2008.04.19 [*.*.*] plugin size reduction: moved documentation to [[MatchTagsPluginInfo]]
2008.03.25 [1.2.0] added optional "sort:fieldname" parameter
2008.03.20 [1.1.2] in handler(), replace 'encodeTiddlyLink' with explicit [[...]] brackets to ensure that one-word tiddler titles are properly rendered as TiddlyLinks
2008.02.29 [1.1.1] in matchTags(), added handling to skip remaining tiddlers if expression has an error
2008.02.29 [1.1.0] refactored to define store.matchTags() and extend store.filterTiddlers()
2008.02.28 [1.0.0] initial release
<<<
Webservice for on-line converting TeX math formulae to images. Could be quite useful...
[[mathtran link|http://www.mathtran.org/]]
* we have DPA in the last 2 weeks of august - till then everything has to be set up for him to migrate to the TAF codebase and cut the demos
* LCH will soon be ready for the VTOL planner integration with the TAFII codebase
* TKO will work on the integration of the VTOL physical dynamics into the TAF II codebase
* TKO will still improve the greedy1 scenario
* JVO needs 2 things before he develops the DVRP scenario:
## new sensor - task PNO
## new executor of waypoints-based paths - task PNO
* BBO will come back to report on the adversariality in TAF/TAS on 20100714
* for now, we suspend the clustering + potential fields. We should come back to it later.
* TKO will work out the greedy2 scenario - greedy1+communication about destinations
!! New sensor
The DVRP solver needs as an input a set of positions of targets. These need to be identified by some external algorithm. I will try to do the following:
# last known target positions list
# centers of the uncertainty/old info age regions
# some clustering algorithm?
!! New executor
Simple reactive mechanism controler for planes which steers them through a route of several waypoints
''Participants:'' TKO, MPE
''Topic:'' Update/Intro into MAS re-planning research track leading to a thesis (TKO)
The setup is as follows:
# the problem input is a multi-agent plan generated by some MAS planner (not an issue here)
# the MA system executes the plan and monitors progress. In the case of a failure, the plan has to be repaired. There are of course different strategies and possibilities to do it. E.g., first, agents should try to repair the plan locally and only when that cannot be done (w.r.t. the global constraints induced by agents' public actions), they should escalate to a multi-agent plan repair algorithm. In the first approach, this should be a //centralized plan repair algorithm//.
The main result of the meeting is basically realization that this problem should be seen just as a single piece of a larger puzzle. In particular, the workplan on this track should be as follows:
# develop the first solution to the centralized planning problem
# then we can try to develop a distributed solution to the problem, i.e., distributed re-planning without a centralized element
# another very interesting open issue to study in parallel with (2) is the relationship between quality/optimality of the original MA plan generated by a pre-planner and the complexity of the plan repair algorithm. This issue requires redefinition of the concept of //plan optimality// to reflect optimality w.r.t.
## dynamics/entropy of the environment, as well as
## implied complexity of plan repair in the case of failure.
# then subsequently, we could extend the study of (3) to the distributed case. There are trade-offs also between centralized solution vs. the distributed one.
The most interesting problem I see there is the question (proposed by MPE): //''what is the cost of simplifying plan repair w.r.t. the quality/computation complexity of the original plan?''//
!! Discussion summary
The design discussion lasted for more than half a day. The main results are the following:
* the TAF2 implementation will be done (?) in the original TAF2 code base, i.e., in the A-Globe context - i.e., not primarily in the A-Lite suite
** this decision is subject to further discussion with JVO
** the main arguments in favor of this decision are:
### DPA gave us an overview of the TAF2 implementation and it seems that it's not such a mess as we previously expected, i.e., the components seem to be well separated - this is a subject further code review
### UAVs and VTOLs already run in the A-Globe code base. To do the devel in A-Lite, we would need to port quite a lot - an overkill
### Disadvantage is that we are giving here up 1) the comfort of debugging and 2) possibility to run a large number of automated tests
**** is there a possibility to push the development in parallel in both worlds? this would solve the two issues
* we made a progress on the stub implementation scenario - see below
!! Project tasks
* we need to implement moving people to have targets to track (PNO: could this be done as cars in the first approach?)
* we need a better implementation of the environment, i.e., what is called SENSOR in AgentFlyl/TAF
!! The resulting todos:
* PNO: clarify the status of MANETs
** MPE: no, MANETs were thrown out of the project. If possible, we could deliver "something" in this direction, but that would be a bonus.
* PNO: investigate a possibility to delegate the VTOL thread
** MPE: generally, we could delegate. But we need to make ''sure'' that it will be delivered. VTOLs are a priority in this project
* PNO: clarify the status of UGVs in the TAF2 project
** MPE: no, no UGVs in TAF2
* TKO: urge the scenario from Roy
** //in devel//
!! Ideas for the stub implementation
* VTOLs task seems to be clear
* MxN tracking - as of now, it's the domain of JVO
* Mixed initiative infocollection:
** an example of a starting scenario for the mixed-task information collection point in the project, we came up with mixture of surveillance and tracking. I.e., a set of planes runs a zig-zag surveillance algorithm over an area through which
a tracked target is moveing. The planes should (proactively) take over the tracking task, but not compromise the surveillance. I.e., there should be a threshold on when to try to delegate the tracking task - in the case nobody will voluntarily take it over. The same could be done for exploration vs. other tasks.
Introduced by Alur, Feder and Henzinger in their paper //The Benefits of relaxing punctuality//, published at PODC'91.
[[link|http://portal.acm.org/citation.cfm?id=227602]]
[[homepage|http://liawww.epfl.ch/People/people.php?username=schumach]]
* in TAF there are no cars, but the mission planning as in TAS should be already present in some form. What we actually want is to start an analysis of the problem in TAF and apply it in the TAS project in some early form. I.e., in TAS there should already be the temporal mission planner employed -> in result, I need to get to this task ''asap''.
* //adversariality// - we need to define the interface of the component and analyze its capabilities and possibilities of application. In result, we need to come up with a concrete application scenario and a structure... Game Theory for adversariality should be treated as a black-box module.
* actually the TAS SW structure can be seen as a sequence of modules:
## situation recognition
## rough strategy planner (could be the game theory 4 adv module - BBO)
## planner/replanner (TKO) + GT4ADV planner (BBO)
## execution/monitoring (PNO?)
The exec module escalates problems to the re-planning module which fixes whatever there is to be fixed and if not, escalates to the strategy planner.
* the guiding abstraction is the dataflow between the modules. strategy planner gets a goal and returns a structure (sequence?) of subgoals. These are fed into the team planner which produces a finer plan which can be executed by the exec machinery (BSM/Jazzyk?)
* note that goals in a mission can be //cooperative// as well as //adversarial// depending on whether they involve solely the blue task force, or include also the adversary
* the resulting decomposition can be into modules coined ''strategic'' + ''tactical'' + ''personal'' planning.
* actually the strategic planner could involve the whole large task force, the tactical planner deals with task-oriented formed teams and at the personal execution level we have the programming language, such as e.g. BSM
* due to teh previous point, in fact, the different planner layers speak different languages in terms of capabilities.
* one of the guiding principles could be also distribution of non-determinism among the planner layers and its kinds.
* how does a mission planner fit into the game?
> Multiple-context systems are those in which a single architecture and core assets must function well in several different environments. Examples include product-line architectures, as well as certain elements of enterprise architectures—especially those that have integration and infrastructure responsibilities. Unlike single-context systems, which resolve one set of forces, multiple-context systems must resolve the forces in each individual context.
An interesting point into the set of MAS motivations. Actually it stresses the role of robustness of solutions in multi-agent systems and agent-oriented programming. For me, this embodies the argument for elaboration tolerance and a need for a principled approach to building systems. //Robustness// is the name of the game!!!
Few quick links:
[[Multiple-Context Systems: A New Frontier in Architecture|http://msdn.microsoft.com/en-us/architecture/ff476942.aspx]]
[[homepage|http://ti.arc.nasa.gov/tech/asr/intelligent-robotics/]]
This came out on May 5th 2010:
[[NASA official outlines plan for next-generation space robots|http://www.computerworld.com/s/article/9176307/NASA_official_outlines_plan_for_next_generation_space_robots]]
It is a note on NASA's plans for building autonomous robots which should support human-centred space missions. A very good read. It leaves an inspiration, and a reference as well, for cognitive robotics vision. Optimistically, I would say, this boosts both: the vision on single agent intelligent systems, as well the mission-planning project. Actually, mission planning for single agent is probably the way to go. I.e., a look towards extensions of MetateM, or stuff alike. Robot gets a mission specified as a (possibly complex) temporal specification and then executes it - optionally in cooperation with other such agents...
Check also [[NASA Intelligent Systems Division]]
http://www.cs.tau.ac.il/~nachumd/papers/Church.pdf
Is there anything like //non-monotonic temporal logics//? Something like NMLTL?
This could be useful for reasoning about goals and their mutual interactions and consistency of sets of goals.
''YES!!!'' there is such a thing by Chitta Baral and Jicheng Zhao. They have a paper [[Non-monotonic Temporal Logics for Goal Specification|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.77.5640&rep=rep1&type=pdf]] published at IJCAI 2007 (?). Very interesting indeed.
And they have one more on this topic: [[Non-monotonic Temporal Logics that Facilitate Elaboration Tolerant Revision of Goals|http://www.public.asu.edu/~cbaral/papers/AAAI13BaralC1.pdf]] published at AAAI 2008.
----
The first paper defines N-LTL a non-monotonic version of LTL, while the second introduces ER-LTL, which can be seen as a variation on the same game. I read carefully only the first one. I only browsed and checked bits and pieces of the second one.
!!! N-LTL
N-LTL is basically LTL extended with two additional syntactic constructs:
# $ [r]\phi $ (weak exception), and
# $ [[r]]\phi $ (strong exception).
While the strong exception should be read as "normally the agent has a goal $\phi$, but whenever $r$ holds, the agents //doesn't want// $\phi$". Weak exception says rather something like "normally, the agent wants $\phi$, but whenever $r$ holds, $\phi$ is not necessary".
The paper then introduces labels to such formulae, i.e., those $r$'s in exceptions are labels validity of which is specified as
\[ \langle r: \varphi \rangle \]
$r$ (a label) is called the //head// of the rule and $\varphi$ (an N-LTL formula) is the //body//. A head can be specified this way multiple times. Labels are taken from a distinguished set of literals, they cannot occur in plain N-LTL formulae outside the square brackets.
Authors then show how a set of such N-LTL formulae (a disjunction) can be compiled in polynomial time to a plain LTL formula. Finally, they show how N-LTL theories can be encoded as logic (ASP?) programs.
In the end, authors also show how to introduce N-CTL* with the same technique. This wasn't that interesting to me.
----
!!! Notes
* this gave made me to realize that in every moment actually an agent has just a single goal which is a disjunction of all the more elementary goals which follow from the goal base $\Gamma$
* authors of this paper definitely do the work on reasoning about goal in a much better way than the ProMAS people do. Here they basically introduce a hard KR technique to reason about goals. Nothing arbitrary... I like this. This kind of stuff is the ultimate machinery I would like to use. Definitely not some ad-hoc goal reasoning algorithm in terms of suspends, inactivates, etc.
* it seems to me that a Jazzyk/BSM KR module which facilitates this could be fairly simple to do with the ASPlugin of Michael (or similar technology like that).
There's a spectrum of programs in agent programming/robotics embodied in dynamic and unstructured enviornments for which the agent does not have all theinfomation and is likely to fail. On one side we could create perfect programs which deal with all sorts of failures and sensor/effector deficiencies. Such programs would be too long and most likely even impossible to write (how can you know about all the problems you might have???). On the other side of the spectrum are programs which deal only with the “positive” situations, i.e. robot's core functionality and do not care for failing. These programs are most likely very short, but imperfect. In APL we need to strike the balance between the two, but I personally believe we should push for the shorter side of the spectrum, rather than the other. I.e. few failure recovering functionalities, which however most of the time work, even for the price that the agent will do some useless stuff. This push for conscisness is actually an attempt to deal with a complexity of the task to program agents in rich environments. An usefull technique introduced in agent oriented programming to deal with this complexity is introduction of non-determinism, i.e. non-deterministic execution of under-specified behaviours. But now we we need to deal with handling the non-determinism. Hence BSM as a tool for dealing with the non-determinism in a practically useful (vertical modularity) and software-engineeringly “sane”/”aware” way. An informal methodological goal is to build whort robust programs, not neccessarily providing always a perfect immediate response. Instead of “always act/respond rationally to a given situation in order to achieve a goal”, we are after “always eventually achieve a goal” only. This is UNDERSPECIFICATION inherent in this type of agent programming.
* non-determinism/short/robust
The stream of works by [[Birna van Riemsdijk]], [[Sebastian Sardina]] and others seems to go in direction of adding ever more complex types of LTL goals to APLs. Yet, they refrain from generalizing to the point of saying that any wff LTL formula can be a goal. I do believe so, but they seem to go in a constructive direction. I do not know why. Actually it seems to me that a particular goal type is a matter of an application designer and he/she can decide in a qualified way what kind of either simple, or extremely complex goals they need. But I believe that for any kind of LTL formula, there probably is an example , where it makes sense as a goal of an agent in that setting.
BTW, what is also interesting, is that papers in this stream on [[unifying framework for reasoning about goals]] they separate the goal dynamics from other reasoning in an APL. Actually, since goals are the key element of BDI-inspired architecture, they simply separate the intentions part from the mechanics...
One of the results of my interaction with CDO (Technion) during his visit in late February 2010 at ATG@CTU was that [[the theoretical work they are doing|Carmel Domshlak & Ronan Brafman: Planning for Loosely Coupled Multi-Agent Systems]] is of great importance to practice. It is not a theoretical work in the sense of proposing theoretical frameworks for doing XYZ. Rather, the type of work is that they analytically study properties of whole //classes// of solutions with certain properties and derive _declarative statements_ about the problems and domains themselves. Not the approaches. This kind of work is far from irrelevant for practice. This is how it should be.
! PDDL resources
[[resources page|http://ipc.informatik.uni-freiburg.de/PddlResources]]
!! Bacchus: The Power of Modeling—a Response to pddl2.1
[[link|http://ipc.informatik.uni-freiburg.de/PddlResources?action=AttachFile&do=get&target=bacchus-jair-2003.pdf]]
* interesting note on pgs 1, 2: //That dichotomy is between work on
“domain-independent” planning and “control-intensive” planning. Just as work on control-
intensive planning tends to ignore the applicability and power of state-of-the-art search
algorithms for planning, work on domain-independent planning tends to ignore the power to
be gained, and the requirements imposed, by domain modeling.//
!! Fox & Long: PDDL2.1 : An Extension to PDDL for Expressing Temporal Planning Domains
[[link|http://ipc.informatik.uni-freiburg.de/PddlResources?action=AttachFile&do=view&target=fox-long-jair-2003.pdf]]
* they summarize works on temporal planning up to 2003. They mention the following pieces:
** Smith & Weld: //Temporal planning with mutual exclusion reasoning//, IJCAI 1999
** Bacchus & Kabanza: //[[Planning for Temporally Extended Goals]]//
** Do * Khambampati: //Sapa: a domain-independent heuristic metric temporal planner//
* PDDL 2.1 features some temporal aspects in introducing actions with durations. In fact, they introduce //durative actions// which only specify conditions at the beginning of the duration interval, at the end of the interval and some invariants for conditions which hold in all states of the duration. However, no other states (combinations, or path specifications) are allowed/made available in the language. In effect, this language is not expressive enough to support complex temporally extended goals.
* another interesting feature in PDDL2.1 is introduction of specifications of continuous resources (such as e.g., time?). A typical example would be an action with unspecified duration which however causes a continuous change in a resource - e.g., fuel amount, or temperature.
* on pg. 84, there are several notes on related work, i.e., works on planning with temporal features. I collected the following notes:
** TGP (Smith & Weld) planner takes a similar approach as described above. I.e., even though actions have durations, all their effects are realized at the end of the duration interval. In consequence durative actions are treated as black box intervals, i.e., inaccessible to interruptions, or intereference.
** Sapa system (Do & Khambhampati) allows annotations of time points with effects. I.e., during an action execution something can happen in e.g., 2nd, or 3rd, etc. time point. This seems to be a richer framework which could be able to express e.g., $\lozenge$, or $\square$ operators...
* finally the authors discuss also some related issues about reasoning about time. They make some interesting notes on two problems - and I should take a look at these:
## the //[[frame problem|http://plato.stanford.edu/entries/frame-problem/]]// in temporal reasoning frameworks, and
## the //divided instant problem//.
TASK: Check whether the USAR domain as done in the RoboCup rescue would have a potential for transferability to the TAS domain.
!!! RoboCup Rescue/Simulation League/Virtual Agents
Rather focused on robotics than teamwork. The teamwork element is heavily there, however the main focus is on sensing/actuating w.r.t. single robot device. Even though there are overlaps, the transferability between the TAS and USAR (as here) domains is rather limited.
[[General Info|http://www.robocuprescue.org/wiki/index.php?title=VRGeneral_Information]]
[[Publications|http://www.robocuprescue.org/wiki/index.php?title=Publications_on_Virtual_Robots_and_USARSim]]
!!! RoboCup Rescue/Simulation League/Agent Competition
The main focus is on coordination, but the potential for transferability to the TAS domain is rather limited. The operational scenario is simply too focused on disaster management.
[[Agent Competition|http://www.robocuprescue.org/wiki/index.php?title=RSL2009#Agent_Competition]]
!!! USARSim platform
Anyway very interesting stuff for cognitive robotics.
__Side note:__ I could go far with going for USARSim simulator. They are far far better off than our Nexuiz thing. My decision was based on rather old information about the RoboCup rescue stuff and related issues.
[[USARSim Supported robots|http://usarsim.sourceforge.net/wiki/index.php/12._Robots]]
! Bookmarks
* [[ARCIC documents|http://www.arcic.army.mil/res_keydocs.htm]]
* ''The Army's Future Force Capstone Concept'' - seems to be THE document of the organisation. It was published as a TRADOC pamphlet No. 525-3-0
** [[from TRADOC|http://www.tradoc.army.mil/tpubs/pams/p525-3-0.pdf]]
** [[draft from elsewhere|http://smallwarsjournal.com/blog/doc/Army%20Capstone%20Concept%20V%202%207.2.pdf]]
! Comments
!! The Army's Future Force Capstone Concept
[[Link|http://www.tradoc.army.mil/tpubs/pams/p525-3-0.pdf]]
''Summary'': //United States Army Training and Doctrine Command (TRADOC) Pamphlet (Pam) 525-3-0 is the Army’s capstone concept - the overarching visualization of how the Army Future Force will participate in joint operations in the period 2015-2024 to achieve full spectrum dominance across the range of military operations. The ideas presented here are fully integrated within the evolving context of our estimates of the future operating environment, joint and Army strategic guidance, and the joint framework. They have emerged as a result of years of research, wargaming, experimentation, and operational lessons learned by the Army, our sister Services, and the joint community. However, they are far from final - they are but a start point for a dynamic, professional dialogue on how best to meet the needs of the Nation together with our partners in the defense community. Their purpose is to shape the Army’s continuing campaign of learning. As the Army tests these ideas - even to the point of failure - we expect them to evolve.//
''pg.26:'' //Even in smaller-scale contingencies and stability operations, the Future Force must include the inherent capability to root out enemy forces in protected sanctuaries throughout the depth and breadth of the area of operations. Failing that outcome, lasting resolution of the conflict will remain in doubt.//
''pg.27:'' //Certainly, stability operations (and irregular warfare in general) will present significantly different operational requirements to the Future Force than processMCO, requiring readiness to perform combat tasks with simultaneous execution of a wide array of non-combat tasks. They place an even higher premium on adaptive leaders, multifunctional units and soldiers, combined in dynamic mission tailoring. Future Force units must have embedded leadership and capability at all levels to integrate and synchronize the actions of joint, interagency, and multinational entities. Force composition must also account for commitment of significant military resources to reconstruction and nation-building. Mission tailoring and modular force structures must enable the rapid combination of capabilities to meet this expanded mission set, without loss of cohesion or effectiveness.//
''pg.34:'' //Pursuit of information superiority with intensity and purpose, from predeployment through final decisive operations, is a key operational task. That pursuit will often require the Future Force to fight for information, particularly when confronting elusive and adaptive enemies in remote locations in which information from technical sources is inaccessible or incomplete. The force must also be prepared at any time to adapt operational plans and tactical methods to imperfect situational understanding.//
''pg.34:'' //As a space-empowered force, the Future Force will routinely exploit the constellation of military and civilian space platforms for persistent surveillance, reconnaissance, communications, early warning, positioning, timing, navigation, weather/environmental monitoring, missile modernizingdefense, and access to the global information grid.//
''pg.36:'' //
* Develop a multiechelon collaborative information environment (CIE);
* Fuse sensors both horizontally and vertically within an interdependent joint network, relying on capabilities that provide persistent ISR;
* Field single and multipurpose unmanned aerial vehicles at appropriate C2 echelons, in accordance with the most effective exploitation of common airspace;
* Integrate an agile, ubiquitous communications network from ‘space to mud’;
* Enable battle command on the move without degradation;
* Continue to explore effects-based planning as a means of improving the military decision making process.
//
''pg.36:'' //The potential operational benefits of these advances will be profound. Distributing battle command capabilities among multiple distributed nodes and enabling multiechelon collaborative planning from joint to tactical levels will eliminate much of the sequentiality in today’s planning and allow streamlining the military decision making process. Planning in concert, commanders and staffs at successive echelons will have a clearer, common understanding of intent and a fuller appreciation of the implications of planning decisions across units and formations. Expanded situational understanding and multiechelon collaboration will facilitate the use of mission orders and expand span of control, enabling greater decentralization and simultaneity. Access to the CIE will enable subordinate commanders to self-synchronize their actions during operations and make incremental adjustments in response to chconductinganging conditions. Tactical commanders will be able routinely to employ joint effects at lower tactical levels to help conclude tactical actions more rapidly. The sum of these advances will enable commanders to anticipate more reliably and apply force more precisely and effectively, simultaneously shaping the future battle while conducting current operations, across the spectrum of operations.//
> ''Rapidly changing operational conditions!!!!!!!''
''pg.37:'' //The network will provide the means for forces at all levels to: achieve situational understanding; establish, maintain, and distribute a COP; create the commander-centric C2 environment described above, and operate within a noncontiguous battlefield framework.//
''pg.38:'' //Given the complexities of the future operating environment, Army force structure must be versatile and modular - a hybrid mix of capabilities that can be flexibly combined to address any contingency. Given the lead times associated with fielding new systems and modernizing older ones, and the varying readiness of both active and RC formations, the Army never has been nor will be a completely homogenous force. Nor is such homogeneity a prerequisite for military success. On the contrary, the very diversity of requirements associated with the current and future operating environment argues against it. Given that diversity, hybrid forces with differing characteristics and capabilities constitute a strength rather than a weakness, provided the force overall does not lack essential capabilities and the mix is balanced to meet the range of expected contingencies.//
> This is an extremely important note. However, it is not clear what are the time-span constraints of such heterogeneity and modularity. I.e., do forces re-configure during an operation in a matter of minutes, hours, or days? This is crucial for scenarios in focus. The longer the time span, the weaker is the reliance on automatic/autonomous systems and the re-configuration can be done in HQ by commanders. In fact, the question at this point is, what kind of scenarios require //immediate// (i.e., in terms of minutes) reconfiguration.
''pg.44:'' //... complex informational terrain is the multiple sources or transmission paths for communications, data, or information - including news media. A force operating in complex informational terrain will not have the ability to control information flow. Once again, this is most common in heavily urbanized terrain, where all sides in a conflict may use the same mobile phone systems or satellites and gain tactical information from news media operating throughout the same physical area.//
''pg.52:'' //''Brigade Combat Team'' (BCT)// is becoming the core organizational unit of the Army.
''pg.53:'' //''Force pooling''// - some answers to the point raised above on the time-span of re-configuration. The important resulting note here is that they meant rather long-term coalition formation, i.e., composing a special-purpose brigade level units which then execute operations through longer periods of time.
!! Army Robotics Strategy White Paper
[[Link|http://www.arcic.army.mil/Key%20Documents/RoboticsStrategyWhitePaper_19Mar09.pdf]]
The document discusses use of robotic systems in military missions. For the context of project the relevant objectives of robotic systems are those in the area of engineering, i.e., tasks E1-E6:
* E1 - Conduct terrain recon for trafficability and location of barriers/obstacles/mines
* E2 - Overcome and report obstacles
* E3 - Conduct breach operations
* E4 - Move and emplace materiel, construct obstacles, establish security
* E5 - Mark, record and report obstacles
* E6 - Conduct firefighting operations
The other are too focused on HW robotics.
A very interesting text full of useful bits and pieces:
[[http://danielwilkerson.com/effective-management.html]]
On-line handbook on scientific writing:
http://www.ecf.toronto.edu/~writing/handbook.html
A Few Rules from "A Handbook for Scholars":
http://www.cs.uu.nl/docs/tandt/html/Scholars/
http://www.cs.uu.nl/docs/tandt/ps/scholars.ps
Common errors in technical writing:
http://www.ece.ucdavis.edu/~jowens/commonerrors.html
How not to write an abstract:
http://www.lightbluetouchpaper.org/2007/03/14/how-not-to-write-an-abstract/
Effective electronic scientific publishing:
http://www.cl.cam.ac.uk/~mgk25/publ-tips/
Using BibTeX with [[Lyx|http://www.lyx.org/]]:
http://wiki.lyx.org/BibTeX/BibTeX
>-- notes from the meeting are using regular, //italic// and ''bold'' styles,
>-- @@highlighted notes are my own interpretations@@ and ideas stemming from the meeting
!! Example scenario(s)
A lot of talk was revolving around kind of a scenario (working id = RIL?) in which there are three companies deployed in an urban area. The deployed units are equipped with small-sized UAVs and UGVs. At certain point an intelligence comes in about an adversary safe house, and now the deployed units should
# coordinate in order to set up a perimeter surveillance mission around the house
# surround the area
# //try to identify and distinguish behaviours which are suspicious from operation-unassociated behaviours// - the example scenario would be to spot running person/people emerging from a house and trying to figure out whether their activity is connected to the operation we are currently executing, or whether they might be unrelated civilians who only happen to run
** this would require a kind of //temporal behaviour analysis// - @@a very interesting topic for itself@@
Roy mentioned several times that the difficulties/new issues/open issues they are facing are more about executing humanitarian operations involving tasks such as
* food distribution
* checkpoints control
* medical help/assistance
* disaster management
* infrastructure reconstructions and building
* sewage treatment(?)
* setting up and running jails
* etc.
One of the main new challenges in the new type of conflicts is that the Army is more and more often acting as a police force, rather than a conventional military force.
@@It seems that they could be after mixed //police//+//military// operations, or perhaps such in which (local) missions are ''switching'' depending on the current context@@.
* UAVs are suitable for spotting //unexpected events// and //tracking//, while UGVs are useful for //close-point// operations
A very interesting operation scenario might be to //track a moving target by UAVs and when it enters a UAV-inaccessible area, UGVs should take over the tracking mission// - later possibly handing over back.
@@
* ''this is an extremely interesting scenario. I think we should give it a though, or even two. It seems simple enough, yet requires a possibly complex coordination technique. I can even easily imagine re-use of the goal delegation methods (see the paper by TKO&JVO)''
@@
* an interesting note in this context was that perhaps use of movement/behaviour-predictiion techniques might make sense, since untrained people tend not to do unexpected things. E.g., when entering a forest (group of trees) and thus leaving the sight of a UAV, they tend to run straight so the UAV/UGV can rely on that and expect the person to emerge on the other side of the forest - if it's small enough.
* they also consider scenarios such as
## chasing people out of a building/area
## destroying the building/area - that could be e.g., a part of the telecom, or commlink infrastructure.
!!! Modular team composition
If modularity would be needed we would look at teams involving e.g., an infrared sensor, a camera, a range finding device and a chemical sensor mounted on UAV, UAV, UGV and VTOL vehicles respectively.
* if we are looking at coordination issues, we are probably looking at longer term operations using UGSs where short incidents happen (possibly a number) with use of small UAVs and UGVs where all have just short operational time span and short operational range.
@@
* ''Roy promised to send us a more Army relevant scenario -- the RIL(?) story. It seems to be one of the official training scenarios of the Army, or something like that.''
@@
!! Notes on UAVs
# //note on an UAV wiggling// - this way it's possible to take a look from a side, or increase the range of the camera sensor. You can think about looking into holes, under roofs, trees, etc.
** allegedly they start to use it (think about using it?)
@@
** how it really happens obviously depends on the size of the UAV. I would guess, this is certainly useful for small-sized UAVs, rather than bigger ones, such as the Predator.
@@
* UAVs have problems when a person is under a tree or fairly small obstacles. So when a UAV flies over, a person can easily walk away unspotted. Even small trees and obstacles are problems.
* imagery-taking technology on nowadays' UAVs have great resolution, i.e., they can easily read a license plate from about 1/2 mile height
** therefore it doesn't make sense for UAVs to operate in low altitudes. Typically they fly several hundreds of meters high.
** there are almost no disadvantages of flying high. The resolution is still fine.
@@
*** this makes the problem of occlusions for such a class of UAVs basically irrelevant - with the height, the problem of occlusions diminishes
@@
** in these cases clouds and fog are a bit of a problem so UAVs must fly lower altitudes in such cases. However, there are sensors which can handle fairly well even such situations.
We can realistically consider basically 2 types of UAVs used in tactical missions
# large things such as Predator or alike. Usually they are about a size of a Cesna aircraft, i.e., a 2-3 seater airplane.
** usually they are well equipped with sensors and computers. Often they have an on-board deployed ''server'' (see note on servers elsewhere in this memo).
** you usually need low number of these, typically 2-3 for handling a mid-size city.
** they operate in high altitudes.
# smaller aircrafts which are hand-launched.
** these are mostly glider-like devices.
** a soldier starts the engine and throws the poor thing in the air.
** such a UAV has only a simple radio-link to a ground station, typically being inside a Humvee vehicle. It does not require a line-of-sight communication, it has a radio with a limited range. The ground station than serves also as a server (see a note elsewhere).
@@
** for such aircrafts operating at low altitudes, //handling of occlusions makes a lot of sense//.
** exactly the task of handing over a target tracking between such small devices seems to make quite some sense.
@@
Just a side note: people often shoot at UAVs and VTOLs, but usually there are no losses. But again, this is probably due to the fact that they are typically operated in high altitudes so out of reach of casual shooters with small guns.
!! Notes on UGVs
* they are essentially almost never equipped with more sophisticated sensors than a camera.
** @@yet, it's rather conceivable that the possibility to have there also anything what can be a UGS mounted on the UGV seems to be plausible - if the sensor is fast, i.e., does not need //prolonged measurement periods// and does not require //training// @@
* UGVs are often used in indoor environments, such as //bazaars//, //large halls//, //caves//, etc. They can also be used to peek through windows, or behind corners (arm mounted camera)
** currently they often use heavily armored soldiers with a head/helmet-mounted camera for such tasks
* to loose a UGV is OK, to loose a human is bad, bad
* UGVs are essentially useless in open areas, i.e., landscapes such as in Afghanistan. UAVs are the crux here
* UGVs are useful in urban areas
* we are considering actually quite small UGVs, up to about 1m high. Operational time span might be around 4 hours (Packbot?)
!! Notes on VTOL (helicopters)
* capable of static hanging in the air, thus suitable for surveillance of intersections, building corners and alike
* perching capability, again usable as statically mounted sensors as above
* typically they are //too loud and noisy// - you always know they are there
** therefore they better operate in high altitudes
** another (less interesting) operation scenario is at lower altitudes when the targets know that they are being watched (e.g., they can even see the troops around)
* typically a device about 1m high
* operation time span is about 1 hour
!! Unattended Ground Sensors
Nowadays, they have (and regularly deploy) technology for //seeing through walls//. Mostly this is based on //infrared// and //acoustic// sensors. He also s project - shooter localizationpoke about technology using a kind of //low frequency Doppler radar//. Such technologies allow them to take even rudimentary images through walls. Often such sensors require time to operate (the Doppler thing) so they usually take the form of a sensor attached to a wall.
!!! Acoustic/seismic sensors technology
They seem to have very advanced technology for very effective seismic/acoustic sensors:
* they can detect activity in the range of than 2-3 miles
* they can be used to sense activities behind obstacles, such as //seeing through walls//. Even with a relatively high degree of spatial precision.
* a field of seismic sensors can pretty well detect signatures of different objects, such as animals, humans, cars of different types, etc. The physical picture they can calculate is very accurate.
* they can be deployed for example around jails - a typical task in modern-type conflicts.
* these sensors must be //trained// for operations
** //the downside:// training periods are often too long, i.e., days, weeks, months(?)
* UGSs can be also used for detecting tunnels which adversaries often build in order to avoid over-ground sensors or solid obstacles.
@@
* this reminds me of the work done by Brano and the team at Vanderbilt:
** [[PinPtr|http://w3.isis.vanderbilt.edu/projects/nest/applications.html]]
** [[RIPS|http://www.isis.vanderbilt.edu/Projects/rips/]]
@@
* generally UGSs are preferred devices because of low //operational costs// and //low bandwidth//
@@
** use of such UGS goes in direction of operations which last longer time spans
@@
!! Army operational/decision making structures vs. modularity vs. teamwork issues
The larger the asset/piece of equipment is, the higher position entity in the chain of command //owns// it. E.g., large UAVs are //owned// and //managed// on the //brigade//, or even the //division// level. Even more specialised equipment, such as the Predator UAV aircrafts are owned by the Air Force, thus almost inaccessible by normal Army units without passing through the //Core// command (the highest level of escalation). Basically any decision about a use/share of the equipment //must// go through the level on which it is being owned. //No direct requests would work!// And obviously the higher level of escalation is enforced, the more difficult and more time-consuming will it be to get it through. Basically nobody does such things. Smaller pieces are owned by platoons. But these are always very simple devices -- @@the point seems to be that they should be lightweight, easy to operate and finally not complicated in terms of delivered information/data complexity@@
@@
* from this it's clear that the //modularity// we spoke about happens on the level of brigades and alike units basically before the operation. It is pre-planned from behind a desk. Direct modularity of teams on the ground during an operation is ''not an option''. As Ray said ''even if you build something in this direction, nobody will want to see it''. I.e., ''THEY NEVER WANT TO SHARE ASSETS AND BIG PIECES OF EQUIPMENT''.
* this basically means that we should concentrate on coordination in terms of already established teams which should do something together/reach a joint goal/cooperate, etc.
@@
A side note: of course smaller units coordinate and help each other. But all that is based on personal decisions of officers, it is not institutionalized.
@@
* it might be interesting to optimize on the necessary level of escalation for sharing resources request. Requests for big equipment are extremely costly (they go through the core command).
@@
!! Network infrastructure
Interestingly, they have there also issues touching the network infrastructure issues. There seems to be an interplay between troops, //smart// equipment (UAVs, UGVs, USGs, VTOLs, etc.) and the network. The main points:
* there are //battle command servers// deployed around the theater.
@@
** it seems they are often associated with a platoon and a set of pieces of equipment...
@@
* the unit launches a UAV (hand-launched thingy) @@, or perhaps a UGV, or VTOL@@
* the vehicle communicates directly and //exclusively// with the ground station with a server
* the server provides a subscription-based service (publish-&-subscribe) providing the data from the associated sensors, i.e., the UAV/UGV, etc.
* in principle, the data stream can be almost //real-time//!!!
@@
* do they have some kind of service discovery functionality there? What if I would like to see data from the sensors around me. How do I find those sensors and their associated servers?
@@
* the recurring question nowadays in the army is that of the network infrastructure and commlinks.
** they are using already a fairly OK network (kind of an Army Wireless Radio)
** it's OK, but still the bandwidth is an issue - @@i.e., you shape a kB/s and you made an excellent contribution!@@
!! Switching between infrastructure vs. combat operational mode
Another interesting scenario is to have a number of UAVs over an area, which are actually securing a communication infrastructure for the units on the ground. But in the case of need, some of them might become surveillance devices and their tasks could be taken over by the remaining fleet members. After completing the local mission, they might get back to their original tasks.
* they would like to try to do it dynamically (???)
* however, the side note is that UAVs don't usually talk to each other
** somehow all this is a part of the above mentioned RIL scenario...
@@
* Again this reminds me very much of the target-tracking-handover operation described somewhere above. It is about switching the functionality (changing goals/contexts) of a single agent in the context of a coordination task.
@@
!!! Utility of information
This is a very interesting issue Roy mentioned. Basically it is about the trade-off between the quality of information you want and the information-type which is optimal for you as a reply. The three types of information involved could be
# text info
# imagery
# video stream
Now if you want to know, for example, whether a courtyard is empty, in the positive case only a text message would suffice. Perhaps in the negative one, you should get an image. The system has to be able to optimize its functionality on what the requester actually needs, but this is probably based on his intentions. This whole leads into a kind of //understanding of intentions//. In other words, the topic could be described as ''optimization of the communication infrastructure w.r.t., the data which is being pushed over it'', or something like that (???).
!! Assorted notes
; Reidentifiability of targets
: they go for simple features, i.e., clothes (color, perhaps a style), hat (yes/no). If possible they would try to take a look at the face of the person, but that happens rarely.
@@
* Perhaps a side fly-by of a UAV could help? I guess it's useless and too complex anyway.
@@
; platforms and sensors
: it might be useful sometimes to differentiate between proper sensors and platforms on which these are mounted.
@@
* I am not really sure whether this is so useful in reductionist scenarios as we go for...
@@
; TIGER (?)- a DARPA local intelligence support system
: crowdsourcing in the Army at work, a //georeference wiki//. The system adds to the patrol short report mechanism. Simply they input all their short reports about any incident occurring in an area into the system and make it available to everybody else. Perhaps even NGOs and foreign/local army/police units could contribute and use the system. A huge lot of //local intelligence// is collected in such a way.
@@
*I remember reading about something like this. Most probably in [[Die Zeit|http://www.zeit.de/]], but I am not sure...
@@
@@
* perhaps we could ask a question such as ''provided a mission description, what kind of combination of sensors is suitable for that?'' -- we could try to experimentally find the answers.
@@
@@
* I like the point that actually it is not possible to use any kind of equipment which is hanging around in the theater. The fact that I can get the info from the device, but I cannot control it is actually ''great'' - we get //incomplete information// and //device autonomy// for free. We do not have to elaborate about how to make an artificial story around them. We get it because of the design of such missions.
@@
!! Some notes on the TAS [[Scenario proposal draft]]
!!!! Dynamic information
The scenario is rather OK in that it involves //dynamic information//. I.e., the information to collect is itself dynamic as well and has to be seeked and tracked. The core issue is that the team has more work (information to collect) than it can easily handle. I.e., m2n tracking and changes in the environment.
!!! Environment vs. the player
Another point is that the environment plays against the team/task force. This is perhaps not necessary as far as the environment is dynamic. Dynamics of an environment can be seen as an enemy player most of the time. That's because it's not really necessary that the adversary plays against the player, but most of the time the fact that it plays in a way which (sometimes accidentally) obstructs the players activities is enough.
* MPE meeting
* DeepA final report reading, notes
* installation of the office desktop (half a day)
* finishing the installation of the desktop
* data consolidation
* meeting with MPE+MJA - TAF2
* studying/choosing a laptop (T400)
* e-mails - CLZ, ATG
* discussion with VLY, BBO, MJA
* ATG seminar T. Pevny/Steganography
* meeting with TKO, MJA
!!!Starting a new job at ATG@CTU.CZ.
* short intro meeting with [[Michal Pechoucek]] and some group members
* administration
* seminar: final report of the Tactical AgentFly project.
* about 3hrs e-mail, AgentContest stuff and Clausthal issues.
* morning: 8:30 meeting with Michal Pechoucek
* before noon: meeting - Tactical AgentFly 2(MP, MJ, AK, XX) - [[minutes|TAF2-20091016]]
* afternoon: administration, about 2hrs e-mail, CLZ stuff, ATG technical issues (e-mail, Wiki, etc.)
* morning - administration@FEL
* TAF study
* studying ATG projects on the website -> resulted in the DeepA meeting
* DeepA meeting with VL (2-3hrs)
* further discussions with VL & BB
* AgentContest issues - correspondence
* morning: administration (insurance, cards, keys, etc.)
* afternoon: DeepA discussions with VLY, RVA, MJA
** gathered quite some insights into the project internals, their needs, positions and issues.
** mostly discussed the purpose of and issues in //modeling and adversaries// in the project. In particular issues, such as
*** is it better to model adversaries in an open box vs. closed box manner? I.e., as reactive plans, or as declarative formulations of the pre-/post-conditions of their operators
*** modeling on the level of atomic actions aggregated into compound operators vs. treating solely macro (compound) operators
* about 2hrs: formulating a draft of the AgentContest steering committee charter
* TAF2 reviewing the paper in the morning
* AgentContest Steering Committee charter preparation (cca 1hr)
* ProMAS'10 preparation
* communication with WJA on strategic logics, etc.
* TiddlyWiki adaptations and some restructuring
* discussions
* TAF2 final report - expanding on the notes
* TAF2 reviewing/note taking
* [[ATG - notes on the website]]
Morning:
* AgentContest steering committee administration
* ProMAS'10 workshop proposal review + administration
* [[DeepA - AAMAS'09 paper]] - reading
Afternoon:
* [[DeepA - AAMAS'09 paper]] - reading, summarizing the brief review/comments
* clarifications/discussion with VLY on the paper
* TAF meeting with MJA
* DeepA discussions
The following is my reaction to the issues raised by MJA against the note [[Getting deeper into the scenario - reformulation]].
! MJA's comments
# ''//heterogeneity// between aerial and ground units should be stressed more:'' Seemingly, as of now the only difference between UAVs and UGVs is the ability of the ground units to repel civilians. MJA would add detection and disengagement of explosive devices, reconnaissance of buildings (interior) or occluded areas
# ''//repelling// of civilians is not appropriate idea for a military/defense oriented scenario:'' This could be OK for police missions and operations towards suppressing crowd dynamics in adversarial situations.
# ''the //loop-feedback// in the scenario should be avoided:'' feedback requires implementation of reactions to it, moreover reasoning about it, which is 1) complex issue itself, and 2) off-topic here. As the loop feedback feature was meant the point that UGVs influence behaviour of crowds, which in turn influence the behaviour of the task force (convoy)
# ''obscure role of the //limited communication//:'' what is it good for?
# ''//area coverage// suggestion:'' It would be nice to include dealing with the trade-off between poor surveillance coverage of a large area and a "high-quality" surveillance coverage of a smaller areas (e.g., in such it's not possible to install an explosive device).
# ''//research focus// issue:'' It's not clear what are the diferences between the research focus of the development team members (TKO vs. PNO)
! Responses (assorted order as it fits me)
In my opinion, the main issues raised are those of //4. communication//, //3. loop feedback// and //1. heterogeneity//.
!! 1. Limited communication
The role of the limited communication is to //separate concerns// and //foster autonomy// of the individual teams. In result this allows us to:
# clearly claim what are the contributions in highlighting features of the functionality of the individual teams
# possibly experiment with switching the technological/scientific background and the infrastructure above which the individual teams are built
# as a consequence of the previous point, it allows us to scale the development in the individual teams separately. I.e., we could treat performance (w.r.t., the hypothetical objective sub-mission success/support function) as a configurable variable of the simulation. I.e., we could take a particular configuration of the convoy and UGVs and evaluate it against various versions of teh UAV team ranging from non-existent, through poorly performing to a very efficient one.
//I strongly believe the design method I used is right.// I.e., to 1) decompose the scenario into a number of encapsulated autonomous units (teams) and subsequently 2) specify the communication interfaces between them and 2a) strive for minimal interfaces between the functional units. In consequence, this method allows us to sort out what is important in the scenario and what is not, throw away all useless stuff ("balast") and reach its //minimal version// - which is what we want, right? Minimality is good(TM) because it allows us to 1) explain the merits of achievements in focus and 2) minimize development effort invested and thus 3) focus on research problems.
!! 2. Loop feedback & repelling
I am not sure about this one yet. I //feel// that in order to make a MAS scenario challenging the environment //should// be dynamic. Dynamic in this special case would mean that
# the information we are collecting changes over time, laying
# the information we are acting upon changes over time, and
# the speed and magnitude of the change should be overwhelming in that the rate of change is //significantly// higher than the capabilities of the MAS in question.adversarial
In this scenario, that information is "provided/formed" by civilians and their activity. Now of course that does not defend the argument about the feedback part (i.e., UGVs repelling civilians).
!!!!! Civillians to the task force part of the loop
The movements of civilians are interesting in that crowds of civilians form //dynamic// and at the same time //believable// obstacles in the map. So there is a good reason to track and monitor these obstacles and observe 1) where they form, 2) where they are moving to and 3) where they disappear.
!!!!! Task force to civilians part of the loop
Honestly, this is the weaker part of my argument, I guess. It seems to me that civilians acting so that they unintentionally obstruct the mission is somewhat //believable//. Their role in the scenario would be useless otherwise. At the same time crowds of civilians seem to me more believable than let's say potholes dynamically appearing and disappearing on the map. To make even that believable we would need a force to be able to counter-act, e.g., let's say UGVs fixing the craters after mines, etc. And there you go with a loop-style feedback agaagainstin.
Simply I feel that the information the task force acts upon (positions of crowds) should be somehow //crucial// for the decision making on our (convoy's/task force's) side.
!! 3. Heterogeneity
I believe we should keep ourselves on the ground here and go for a //minimal scenario// which involves a need to coordinate. This scenario includes heterogeneity as a //weak// requirement for coordination in that
# UAVs are significantly faster that UGVs, thus can track more targets at the same time
# UAVs cannot protect/guard the convoy, i.e., counter-act the civilian activity
# moreover, in the //Variant 2// UGVs have information which UAVs do not have, i.e., the UGV-team is higher in the command chain than the UAV-team. This variant enforces heterogeneity.
In general I feel that MJA's objections in this point lead to making a better story out of the scenario, but do not contribute to the overall complexity/difficulty of the scenario itself. How do explosives/reconnaissance of building interior/alike make the problem more challenging? I even feel that they would cause more technical work without a benefit on the level of challenge we are facing and will present in the demo. See also my comment on scenario minimality on the response to #1.
!! 4. Area coverage
This element certainly is included somehow. There is a direct relationship between the //number of tracked targets// on one side and //quality of the global operational picture// on the other. At the beginning of the mission it makes sense for the UAV team to explore the whole area, especially the parts around the planned route. Later in the mission when the number of tracked targets increases towards the limit/above the capabilities of the UAV team, they would have to spent most of the time tracking targets instead of doing surveillance/exploration of abandoned areas, even though they are along the planned routes. Here is an interesting point: we can vary the civilian activity and experiment with reaching the limit of capabilities of the UAV team (w.r.t., its size).
To the point of impossibility of installing explosive devices: but this would introduce the loop-feedback you are criticizing, wouldn't it?
!! 5. Research focus
We leave this more or less open for now. The general idea would be for PNO to go for enabling robust software engineering methods for implementation of the individual teams (either, UGVs or UAVs, or even both for better evaluation) and TKO's focus would be more on the functionality of the team members/teams, i.e., tasks involving their planning, reactions to unexpected events, etc.
... and concludes that, like good jazz, the best of people in any discipline is born from an environment of controlled freedom.
[[The Trousers of Reality - book review|http://books.slashdot.org/story/10/01/04/1437240/The-Trousers-of-Reality]]
//The following note about coordination in decentralized MAS is a result of reflections on debates in the TAS project in the first two weeks of December 2009.//
It seems that there are (at least) two kinds of multi-agent coordination which we could sort according to the object/artifact it is oriented towards:
# ''resource-oriented coordination''
# ''communication-oriented coordination''
!! 1. Resource-oriented coordination
It stems from lack of //resources//, or better ''//capabilities//'' necessary for solving a particular goal. A number of agents then can decide to form a team which should be //jointly// capable of reaching/achieving/bringing about the joint team goal. The core problem here is //team formation//, or perhaps //coalition formation// when we would speak about larger entities, such as teams of teams. The intuition is that this leads to problems such as //reasoning about sets of capabilities//.
!! 2. Communication-oriented coordination
It stems mainly from //incomplete information//. The intuition is that is is mainly about exchange of plans in order to coordinate towards a ''//joint action//''. In this setting the team structure is assumed to be fixed and the goal is to reach an //agreement// about the particularities of the joint action. This leads to ''//protocols//''.
!!! Note on communication
We are speaking here about a purposeful communication (i.e., beyond signaling) which assumes that the interaction initiatior wants to eventually receive a reply from the receiver and at the same time the communication content is a subject of negotiation/agreement reaching process - i.e., not just a plain information exchange. We are assuming here other than exclusively //INFORM// message types.
In fact, the case #1 is partly also subsumed by the case #2. That's because team building only makes sense when the team members do not have mutually complete information about each-others' capabilities.
!! Operationalization of LTL goals without a planner
What I would like to end up with is a proof that //given a model, for every valid LTL formula, there exists a BSM program implementing it//. I.e., BSM is kind of //complete// w.r.t. LTL. Most probably BSM is also kind of //sound// w.r.t. LTL. I.e., for every BSM program $P$ and an initial state $\sigma$, there is an LTL formula characterizing $P$. Actually, we showed that in our paper on //code patterns//.
Just a side note: most probably BSM is not sound in this sense w.r.t. the whole DCTL* due to the possibility to express the existential quantifier by $\langle P \rangle \varphi$.
The proof will probably have to be done through DCTL*, or the //process logic//.
----
!!! BSM completeness w.r.t. LTL
!!!! Some observations
Let's summarize LTL operators:
* $\mathcal{A},\lambda\models\varphi_{1}\land\varphi_{2}$ iff $\mathcal{A},\lambda\models\varphi_{1}$ and $\mathcal{A},\lambda\models\varphi_{2}$;
* $\mathcal{A},\lambda\models\bigcirc\varphi$ iff $\mathcal{A},\lambda[1..\infty]\models\varphi$;
* $\mathcal{A},\lambda\models\varphi_{1}\mathcal{U}\varphi_{2}$ iff there exists $i\ge0$, such that $\mathcal{A},\lambda[i..\infty]\models\varphi_{2}$, and $\mathcal{A},\lambda[j..\infty]\models\varphi_{1}$ for every $0\le j<i$;
* $\mathcal{A},\lambda\models\varphi_{1}\mathcal{C}\varphi_{2}$ iff there exists $i\ge0$, such that $\mathcal{A},\lambda[0..i]\models\varphi_{1}$ and $\mathcal{A},\lambda[i..\infty]\models\varphi_{2}$.
''Starting assumption:''
We assume that the programmer provides us with a collection of atomic behaviours (actions) $\tau_1\ldots\tau_n$, each annotated by a DL formula of the type $[\tau_i]\varphi_i$, where $\varphi_i$ is a propositional formula. In DCTL*, this can be expressed by $[\tau_i^*]\bigcirc\varphi_i$.
Let's analyze the situation. We have three basic cases how $\varphi_i$ can look like. In the following we assume that $\psi,\psi^\prime$ are plain propositional formulae not including any logical connectives.
* $\varphi_i = \psi$ - immediately we have $[\tau_i]\varphi_i \Rightarrow [\tau_i^*]\square\varphi_i$ (from the second state on).
* $\varphi_i = \psi \wedge \psi^\prime$ - we have that $[\tau_i](\psi\wedge\psi^\prime) \Rightarrow ([\tau_i^*]\square\psi)\wedge([\tau_i^*]\square\psi^\prime)$.
* $\varphi_i = \psi \vee \psi^\prime$ - finally we have that $[\tau_i](\psi\vee\psi^\prime) \Rightarrow ([\tau_i^*]\lozenge\psi)\wedge([\tau_i^*]\lozenge\psi^\prime)$.
Besides that we also straightforwardly from DCTL* annotations stuff (the Code Patterns paper) have that:
* $([\tau_1]\phi_1)\wedge([\tau_2]\phi_2) \Rightarrow [(\tau_1 ; \tau_2)^*] ((\lozenge\phi_1) \vee (\lozenge\phi_2))$, and
* $([\tau_1]\phi_1)\wedge([\tau_2]\phi_2) \Rightarrow [\tau_1 , \tau_2] (\bigcirc\phi_1) \wedge (\bigcirc\bigcirc\phi_2)$.
//Note:// to be able to show the above, we need an axiomatization of DCTL* (or the process logic), I guess.
//Note:// Here we need to be more general. Hopefully it won't lead to loss of generality... Be careful about that...
----
!!!! The theorem
//Note:// We need to assume some safe environment, i.e., that the environment is not acting against us. I would even propose to assume, that actions never fail, i.e., the annotations are always true.
//Note:// Do we need to assume that the system starts from a certain state? Doesn't matter, if I prove the general cases, the specific cases will work as well when restricted to start from the limited state. Perhaps convenience of articulating the proof will decide later...
@@
> //''Definition:''// Let $P={p_1,\ldots,p_n}$ be a finite set of propositional variables, annotations. We say that the set of LTL wff's $\mathcal{LTL}^P$ constructed using propositional connectives $\wedge,\vee,\neg$ and LTL modalities $\bigcirc,\mathcal{U},\mathcal{C},\lozenge,\square$ is induced by the primitive annotations $P$.
@@
@@
> //''Theorem I:''// Let $P={p_1,\ldots,p_n}$ be a set of annotations and $\mathcal{LTL}^P$ be the set of LTL wff's induced by $P$. Let also $\tau_1\ldots\tau_n$ be a set of agent's basic capabilities/behaviours characterized by PDL formulae $[\tau_i]p_i$ for every $i\in[1\ldots n]$. For every LTL formula $\phi\in\mathcal{LTL}^P$, there exists a BSM mental state transformer $\tau_\phi$, s.t., $[\tau_\phi]\phi$.
@@
Note that we allow $\tau_i$ to be a behaviour, not necessarily an atomic action. Yet, as we are not going to deconstruct these $tau_i$'s, w.l.o.g., we can treat them as atomic actions.
@@
> //''Theorem II:''// Let $\mathcal{P}$ be a BSM program. Furthermore let's assume the same as in the Thm.I. Now for every LTL formula $\phi\in\mathcal{LTL}^P$, there exists a BSM mst $\tau$, s.t., $\tau$ contains $\mathcal{P}$ and $[\tau_\phi^*]\phi$.
@@
//Note:// define what does it mean that one mst contains another one. Actually it can be defined so that $\tau$ is inductively constructed from $\mathcal{P}$ by composing it with a series of other mst's.
//Note:// actually the Thm.II provides a basis for [[elaboration tolerance|Elaboration Tolerance]] and compositionality of BSM programs...
Additionally, we can formulate the opposite of the Theorem I. The two together should show soundness and completeness of BSM w.r.t. LTL. Note however, that it is slightly limited (as I guess now when I did not prove those things yet) (@@???@@).
@@
> //''Theorem III:''// Let's have the same set of assumptions as in the Thm.I. Then, for every BSM program $\mathcal{P}$ constructed as a composition of mst's $\tau_1,\ldots,\tau_n$, there is an LTL formula $\phi$, s.t., $[\mathcal{P}]\phi$ holds (in the assumed model).
@@
!!!! The proofs
........................................
!!! WORKING HERE !!!
........................................
!!!!! Proof of the Theorem I
> //Note:// we can only show that the system is //complete// only w.r.t. to the theory constructible by logical connectives and LTL modalities from the set of formulae $\varphi_1\ldots\varphi_n$!
!!!!! Proof of the Theorem II
----
''NOTE:'' //I believe the main problems will be connected with the negation. In consequence probably also with the "until" and "chop" operators $\mathcal{U}$ and $\mathcal{C}$..//
''NOTE:'' //BTW, what is the exact definition of $\square$ in DCTL*??? Is it based on ''jumps'' over iterations of mst, or the thing just holds all teh time. If the second is true, then I have a bit of a problem and DCTL* has to be fixed... - although the thesis stuff is alright I guess...//
/%
!info
|Name|OpenAllTiddlers|
|Source|http://www.TiddlyTools.com/#OpenAllTiddlers|
|Version|2.0.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|transclusion|
|Description|create a link to open ALL tiddlers in the document|
Usage:
<<<
{{{
<<tiddler OpenAllTiddlers>>
<<tiddler OpenAllTiddlers with: label>>
}}}
<<<
Example
<<<
{{{<<tiddler OpenAllTiddlers with: "click me">>}}}
<<tiddler OpenAllTiddlers##show with: "click me">>
<<<
!end
!show
<html><nowiki><a href='javascript:;' onclick="
var tids=store.getTiddlers();
if (confirm('Show all %0 tiddlers?'.format([tids.length]))) {
var titles=[];
for (var t=0;t<tid.length; t++)
titles.push(tiddlers[t].title);
story.closeAllTiddlers();
story.displayTiddlers(null,titles);
}
return false;
">open all...</a></html>
!end
%/<<tiddler {{var src='OpenAllTiddlers'; src+(tiddler&&tiddler.title==src?'##info':'##show')}}
with: [[$1]]>>
/%
!info
|Name|OpenTaggedTiddlers|
|Source|http://www.TiddlyTools.com/#OpenTaggedTiddlers|
|Version|2.0.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|transclusion|
|Description|create a link to open a set of tagged tiddlers with a single click|
Usage:
<<<
{{{
<<tiddler OpenTaggedTiddlers with: label tagToMatch sortBy reverse close limit>>
}}}
*''label''<br>is the text of the link
*''tagToMatch''<br>is a single tag value to be matched. Note: when MatchTagsPlugin is installed, you can also use a boolean tag expression, enclosed in "..."
*''sortBy'' (optional)<br>a tiddler fieldname, (default="title", use "modified" or "created" for tiddler dates)
*''reverse'' (optional)<br>display order for the tiddlers (i.e., descending vs. ascending)
*''close'' (optional)<br>closes all open tiddlers before opening the tagged tiddlers
*''limit'' (optional)<br>maximum number of tiddlers to be opened
Note: use "" as placeholders when omitting optional parameters
<<<
Example
<<<
{{{<<tiddler OpenTaggedTiddlers##show with: "click me..." sample title reverse "" 3>>}}}
<<tiddler OpenTaggedTiddlers##show with: "click me..." sample title reverse "" 3>>
<<<
!end
!show
<html><nowiki><a href='javascript:;' onclick="
var list=[];
var match='$2';
var sortBy='$3'; if ((sortBy=='$'+'3')||(sortBy=='')) sortBy='title';
var filter='[tag[%0]][sort[%1]]'.format([match,sortBy]);
var tids=store.filterTiddlers(filter);
if ('$4'=='reverse') tids=tids.reverse();
if ('$5'=='close') story.closeAllTiddlers();
var limit=('$6'!='$'+'6')?parseInt('$6'):tids.length;
for (var t=0;t<tids.length && t<limit;t++) list.push(tids[t].title);
if (confirm('Show %0 tiddlers tagged with \x27%1\x27?'.format([tids.length,match]))) {
var here=story.findContainingTiddler(place);
story.displayTiddlers(here,list);
if (here && list.length) { // scroll to top of newly displayed tiddlers
var cmd='window.scrollTo(0,'+(here.offsetTop+here.offsetHeight)+')';
var delay=config.options.chkAnimate?config.animDuration+100:0;
setTimeout(cmd,delay);
}
}
return false;
">$1</a></html>
!end
%/<<tiddler {{var src='OpenTaggedTiddlers'; src+(tiddler&&tiddler.title==src?'##info':'##show')}}
with: [[$1]] [[$2]] [[$3]] [[$4]] [[$5]] [[$6]]>>
/%
!info
|Name|OpenTiddlers|
|Source|http://www.TiddlyTools.com/#OpenTiddlers|
|Version|2.0.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|transclusion|
|Description|command link to open multiple tiddlers with a single click|
Usage:
<<<
in tiddler content:
{{{
<<tiddler OpenTiddlers with: label
"tiddler tiddler [[tiddler with spaces]] tiddler..." template>>
}}}
note: ''template'' is optional and defaults to ViewTemplate
<<<
!end
!show
<html><nowiki><a href='javascript:;' onclick='
var tidlist="$2";
if ("$3"!="$"+"3") var template="$3";
story.displayTiddlers(story.findContainingTiddler(place),tidlist.readBracketedList(),template);
return false;
'>$1</a></html>
!end
%/<<tiddler {{'OpenTiddlers##'+("$1"=='$'+'1'?'info':'show')}}
with: [[$1]] {{"$2"}} [[$3]]>>
<<option txtUserName>>
<<option chkSaveBackups>> Save scrapbooks backups
<<option chkAutoSave>> Auto save the scrapbook
<<option chkRegExpSearch>> Use regular expressions in the search
<<option chkCaseSensitiveSearch>> Search should be case sensitive
<<option chkAnimate>> Enable tiddler opening/closing animations
<<option chkInsertTabs>> Use tab key to insert tab characters instead of jumping to next field
[[AdvancedOptions]] [[Trash]]
<!--{{{-->
<div class='header'>
<div class='gradient' macro='gradient vert #FF8614 #DA4A0D '>
<div class='rssbanner'>
<a href="http://mentalstate.aronde.net/rss.xml">
<img src="./rss-icon.png" width="50px" alt="Follow the RSS feed"/>
</a>
</div>
<div class='titleLine' >
<!--span class='searchBar' macro='search'></span-->
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<span class='searchBar' macro='search'></span>
<div id='topMenu' refresh='content' tiddler='MainMenu'>
</div>
</div>
</div>
<div id='controls' refresh='content' tiddler='SideBarOptions'></div>
<div id='bodywrapper'>
<div id='sidebar'>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlersBar' refresh='none' ondblclick='config.macros.tiddlersBar.onTiddlersBarAction(event)'></div>
<div id='tiddlerDisplay'></div>
</div>
<div id='contentFooter' refresh='content' tiddler='contentFooter'></div>
</div>
<!--}}}-->
[[Gal A. Kaminka, Dan Erusalimchik, and Sarit Kraus. Adaptive Multi-Robot Coordination: A New Perspective. In Proceedings of the AAMAS 2009 workshop on Adaptive and Learning Agents (ALA), 2009|http://u.cs.biu.ac.il/~galk/Publications/b2hd-ala09.html]]
* they promise to present a reward function (Effectiveness Index, EI), that reduces time and resources spent coordinating, and maximizes the time between conflicts that require coordination. It does this by measuring the resource-spending velocity.
* right-of-way priorities
* territorial separation
* role-based priorities
* it is accepted that no method is always the best and that all methods reach a point where //adding// robots to the group (i.e., increasing the density of robots in space) //reduces// overall productivity
* several methods were proposed for //adaptive coordination switching// - unfortunately, while their empirical success is evident, none of these methods have been analytically proven to work, nor understood in the context of existing formal work on multi-robot learning and adaptation.
* the key idea in EI is time and effort spent coordinating and maximize the time between ''conflicts that require coordination''. They measure here the //resource spending velocity//
** this is quite interesting: ''coordination is enforced because of conflicts''
** they promise that EI is //domain independent//
* they mention Rosenfeld et al.'s work on //Combined Coordination Cost// (CCC)
* it's meant so that the value of the objective function steers the adaptation mechanism switching
* Vaughan et al. have presented the method of //aggression// for reducing //interference// in distributed robot teams
* ''mutlilateral coordination prevents and resolves conflicts among robots in a multi-robot system''. Such conflicts can emerge as results for shared resources or as a result of violation of joint decisions by team members.
* coordination algorithms == protocols
* whenever a robot's operation is interrupted by a //conflict event// (a conflict, or a seeming conflict with another robot), the robot triggers a coordination algorithm to resolve it
* the main goal of a coordination algorithm is to reach a (joint) decision that allows the members to continue their primary activity.
\[\mathit{EI_{i,j}}=\frac{\mathit{ACC}_{i,j}(\alpha)}{I^{\alpha}_{i,j}(\alpha)+I^{p}_{i,j}(\alpha)} = \frac{I^\alpha_{i,j}(\alpha)+C^C_{i,j}(\alpha)}{I^\alpha_{i,j}(\alpha)+I^p_{i,j}(\alpha)}\]
where $C^C_{i,j}(\alpha)$ is the cost of applying the coordination algorithm $\alpha$ during the //active// interval $[c_{i,j},t_{i,j})$ and the //passive// interval $[t_{i,j},c_{i,j+1})$ -- coordination cost during the passive interval is by definition $0$ anyway. $\mathit{ACC}$ is the //active coordination cost//. It's a function for a robot $i$ and method $\alpha$ at time $c_{i,j}$ that considers the calculation of coordination cost.
* frequent coordination is expensive. Thus, in an ideal case coordination should lead to prolonged periods of primary activity. Frequent coordination requires cheaper coordination methods.
* the paper however seems to treat coordination as a distributed algorithm, rather than as a communication of information about e.g., shared plans, or joint goals, etc.
@@Pinar Yolum and Munindar P. Singh: //Commitment Machines//, in Meyer and Tambe (eds.): Intelligent Agents VIII, LNAI 2333, pp. 235-247, 2002, Springer - [[link|http://www.springerlink.com/content/b552rflfkvjptnkn/?p=5a6521676a534243a76b130798b30e02&pi=7]]@@
!! Abstract
The paper proposes encoding of communication protocols in terms of //Commitment Machines//. These are sets of rules which encode a protocol in terms of social commitments. The bulk of the paper is dedicated to translation of CMs to deterministic FSMs and authors also provide a proof of soundness and completeness of //the translation///.
!! Commitment machines
* one of the main motivations is to //shorten// protocol specifications, i.e., //unlike in an FSM, the transitions between the states are not explicitly specified//.
* another benefit is also that some transitions in a protocol can be //skipped//. E.g., A can say B that he will help, even though B did not necessarily ask for it first.
* the main idea is to specify protocols in terms of interactions between commitments. The core construct is the form
\[ C_x(p \rightsquigarrow r) \]
($C$ is an operator of a committment, $x$ is an agent identifier and $p,r$ are //meanings//)
The intended semantics is that making $p$ true retracts the commitment $C_x(p\rightsquigarrow r)$ and asserts/enacts a new commitment $C_x(r)$. Now provided we have a state of the protocol specified as a set of currently active meanings (formulae), agents do actions, which change the meanings by what the current set of social commitments is changed. This goes on until terminal meanings are reached, i.e., some of the //final// state formulae can be derived from the current state/meaning.
In result, we have a set of rules describing a protocol, which
# is executable by itself
# can be reasoned about by logic/rule based systems
# can be relatively easily compiled into lower level machines, such as FSMs.
!! Assorted notes
; Speech Acts
: //communication is a form of an action//
Typically a //social commitment// can be modeled by two sides, a //creditor// and //debtor// and the subject of the commitment, i.e.,
a condition facilitating whether the commitment was fulfilled, or not.
<<<
@@
Now it is questionable how to model commitments towards a team in the case when there's no team leader/manager. Obviously solutions lie in recognizing a //organisational structure// involved, i.e., responsibility hierarchy, or a chain of command, or alike. There are of course levels of decentralization. In the extreme, there would be only public commitments, i.e., such for which there's no explicit creditor/enforcer of the commitment, but rather agents //voluntarily// stick to their social commitments.
@@
<<<
* protocols are not only about explicit communication (speech) acts, but general behavioural patterns
** a speech act is a an action as well
** by the same token, transitions in protocols can be also induced by //plain actions// (e.g., wave a hand)
* the crux content of explicit (subjective) coordination machinery are //social commitments//
* these commitments typically includes two parties: //a debtor// and //a creditor//.
** now the issue is, how to model situations when a debtor committed to a team, or a group of agents. Who is the creditor then? @@This might be a general problem of approaches which are based on two parties as the atomic case, i.e., //producer-consumer//@@
/***
|''Name:''|PasswordOptionPlugin|
|''Description:''|Extends TiddlyWiki options with non encrypted password option.|
|''Version:''|1.0.2|
|''Date:''|Apr 19, 2007|
|''Source:''|http://tiddlywiki.bidix.info/#PasswordOptionPlugin|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''~CoreVersion:''|2.2.0 (Beta 5)|
***/
//{{{
version.extensions.PasswordOptionPlugin = {
major: 1, minor: 0, revision: 2,
date: new Date("Apr 19, 2007"),
source: 'http://tiddlywiki.bidix.info/#PasswordOptionPlugin',
author: 'BidiX (BidiX (at) bidix (dot) info',
license: '[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D]]',
coreVersion: '2.2.0 (Beta 5)'
};
config.macros.option.passwordCheckboxLabel = "Save this password on this computer";
config.macros.option.passwordInputType = "password"; // password | text
setStylesheet(".pasOptionInput {width: 11em;}\n","passwordInputTypeStyle");
merge(config.macros.option.types, {
'pas': {
elementType: "input",
valueField: "value",
eventName: "onkeyup",
className: "pasOptionInput",
typeValue: config.macros.option.passwordInputType,
create: function(place,type,opt,className,desc) {
// password field
config.macros.option.genericCreate(place,'pas',opt,className,desc);
// checkbox linked with this password "save this password on this computer"
config.macros.option.genericCreate(place,'chk','chk'+opt,className,desc);
// text savePasswordCheckboxLabel
place.appendChild(document.createTextNode(config.macros.option.passwordCheckboxLabel));
},
onChange: config.macros.option.genericOnChange
}
});
merge(config.optionHandlers['chk'], {
get: function(name) {
// is there an option linked with this chk ?
var opt = name.substr(3);
if (config.options[opt])
saveOptionCookie(opt);
return config.options[name] ? "true" : "false";
}
});
merge(config.optionHandlers, {
'pas': {
get: function(name) {
if (config.options["chk"+name]) {
return encodeCookie(config.options[name].toString());
} else {
return "";
}
},
set: function(name,value) {config.options[name] = decodeCookie(value);}
}
});
// need to reload options to load passwordOptions
loadOptionsCookie();
/*
if (!config.options['pasPassword'])
config.options['pasPassword'] = '';
merge(config.optionsDesc,{
pasPassword: "Test password"
});
*/
//}}}
Abstract: Prolog affords concise, elegant, and clean solutions for many interesting problems, but is not immune to the software engineering challenges of large-scale application development. Code modularization, using modules or objects, is a key feature to keep projects manageable. Because most literature, instruction, and practice focus exclusively on object-oriented languages derived from imperative languages, objects are perceived as alien to logic programming while modules are considered a natural fit. Logtalk is an object-oriented logic programming language that can use most Prolog implementations as a back-end compiler. Logtalk objects are about code encapsulation and reuse, creating natural solutions for a wide range of problems that would be awkward to solve using modules. This talk will begin with the Logtalk design goals, followed by a tutorial on Logtalk programming and application examples. The talk will end with the problems and benefits of developing Logtalk as a portable Prolog application.
!! Mission
@@//I seek to conduct the highest possible quality work on the edge between the basic and applied research and thus contribute to the state of the art in the field of multi-agent systems.//@@
!! The frame
I am a postdoctoral research fellow, currently affiliated with Agent Technology Center (ATG) of Czech Technical University. In concordance to the [[European Charter for Researchers|http://europa.eu/eracareers/pdf/am509774CEE_EN_E4.pdf]], especially the note on treating postdoctoral fellows, in the following I outline a draft formulation of the objectives of my training period at ATG. In particular, I am i) setting up a time frame within which I aim at making the next step in my development towards reaching professional maturity, ii) formulating the objectives of the step and iii) sketching the methodological guidelines I propose to follow in order to successfully reach the objectives.
!! Objectives
In the following I briefly summarize the primary long, as well as short-term objectives and choices I see in my future academic life.
!!! Long-/mid-term aim (4-5 years)
@@Reach a position of professional (academic) maturity, i.e., eligibility for an equivalent of the [[habilitation|http://de.wikipedia.org/wiki/Habilitation]]@@
!!! Mid-/Short-term aim (2-3 years)
; Professional maturity
: Significantly increase the impact of my research work, i.e., both past, as well as the immediately forthcoming (current).
In particular this amounts to reaching (theoretical) eligibility for an equivalent of the [[Juniorprofessur|http://de.wikipedia.org/wiki/Juniorprofessur]] (in the German system). This aim should be taken as a milestone in the personal development, i.e., at the end of the 2nd and during the 3rd year it should become clear whether I reached the goal, or not. In the case of a negative evaluation, I should consider an alternative, perhaps an industrial, path...
; Research scope
: Broaden my field of expertise in an organic way, i.e., not make a radical switch to another field, but rather allow my past experience to grow and thus expand to neighbouring areas.
This means that in the 2-3 years horizon, I should become an integrated member of at least one additional AAMAS sub-community.
; Project management
: Enrich the current and gain new research project management skills. In particular with the aim to gain experience with proposing, management and financial issues of projects leading to functional engineering prototype deliverables.
As an evaluation milestone, in the horizon of 2 years, I should be able to independently formulate a competitive project proposal for a mid-sized applied research project (cca 2 years/cca 50-100k EUR heavy endeavour).
----
In particular, the path towards this aim involves in the context of my past work (single-agent topics, BSM, patterns, DCTL*, etc.) the following steps:
* wrap up the past work on BSM & patterns and publish it as a //journal publication// (possibly more). Subgoals include
** exploration of the relationship to //proper reactive planning// techniques
** evolve the concept of //commitment-oriented programming// forward towards independent mature results
* conduct research towards exploring the //limits// of the technique - this fits well the experimental work within ATG.
On the forthcoming work front, this amount to
* broadening one's perspective towards //social aspects// of MAS, i.e., coordination, cooperation and collaboration
** here ATG environment is essential and is the means to get to this goal
!! Methodology of work towards mid-/short-term objectives
In terms of work-style and methodology, I want to engage in project(s) driven by ''long-term visions'' with primarily ''theoretical objectives'' (i.e., scientific insights). The motivation is the definition of research as //a process of conception or creation of new knowledge//, i.e., natural-sciences point of view. Yet, in order to keep the feet on the ground, the research ''must'' be rooted in applications and should be driven by applications //beneficial to the society//. These, however, ''must not'' occupy the most important part of this intellectual endeavour and should serve as a means for grounding the research.
!!! Publishing
At the current stage of my professional evolution, I recognize a //a lack of high-impact publications// in my work. From outside, this might be due to either i) there are no significant results to be published from my previous work, or ii) I did not dedicate enough time and effort to try to publish the insights I gained in the previous period. The only way to find out is to tackle the latter issue and collect feedback from peers. Finally, since I am ''not'' after publication //en masse//, the future strategy should aim at increasing efforts towards //results with high-impact//. That means, that subjectively, I would like to focus on few topics and attempt to reach //quality// and //significant// results, rather than a large number of smaller results.
//Bacchus and Kabanza: Planning for Temproally Extended Goals//
[[link|http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.7847]]
The basic paper on planning with temporal logics. Authors introduce a representation formalism for temporally extended goals. Subsequently, they provide a planning algorithm which produces plans satisfying those goals w.r.t. the provided background/control knowledge in terms of temporal constraints.
!! Knowledge representation
The KR formalism for goals is [[Metric Interval Temporal Logic]] (MITL). It is a logic in which validity of temporal formulae is evaluated on intervals, i.e., segments of paths labeled by timestamps. In fact they use real numbers as timestamps, but then provide a kind of discretization of time. Each state on a path is mapped to a timepoint. Additionally, it is allowed for time to stall. This way they model concurrency.
What is interesting is how this plays with those ideas around [[process logic]] and DCTL*. Similarly to MITL, in DCTL* we evaluate temporal formulae on path segments, however defined by program to be executed. There definitely are inter-relationships and congruence of ideas.
Another interesting point are references to reactive planning. Allegedly, Kabanza previously worked on (and seemingly successfully) on generation of reactive plans for temporal goals. This is actually exactly where the recent note [[On relationship between LTL vs. BSM]] is leading towards.
!! Planning algorithm
In the core of the planning algorithm is a //progression formula//. I.e., a function which labels states with temporal formulae which should hold in them. If we start from the initial state, it is labeled by the input goal. The state to which it expands are labelled (according to their timestamps) by modifications (reactiveprogressions) of the parent goal formula so that gradually the formula is simplified as purely propositional formulae (//atemporal// formulae) are checked w.r.t. the state the label corresponds to. By doing this for sufficiently long, the goal formula either simplifies to ''TRUE'', or ''FALSE''. In the first case, it's clear that the goal was satisfied and the algorithm found a plan (backtrace the actions which led to this state). If the latter is the case, the whole branch can be pruned...
----
!!! Misc
As a result, this paper points to some interesting pieces of reference which I should check as well:
* Kabanza: Synthesis of reactive plans for multi-path environments
* Wilkins: Practical planning
config.macros.listTags = { text: "Hello" };
config.macros.listTags.handler = function(place,macroName,params)
{
var tagged = store.getTaggedTiddlers(params[0]);
var ul = createTiddlyElement(place,"ul",null,null,"");
for(var r=0;r<tagged.length;r++)
{
var li = createTiddlyElement(ul,"li",null,null,"");
createTiddlyLink(li,tagged[r].title,true);
}
}
/***
|Name|Plugin: jsMath|
|Created by|BobMcElrath|
|Email|my first name at my last name dot org|
|Location|http://bob.mcelrath.org/tiddlyjsmath.html|
|Version|1.5.1|
|Requires|[[TiddlyWiki|http://www.tiddlywiki.com]] ≥ 2.0.3, [[jsMath|http://www.math.union.edu/~dpvc/jsMath/]] ≥ 3.0|
!Description
LaTeX is the world standard for specifying, typesetting, and communicating mathematics among scientists, engineers, and mathematicians. For more information about LaTeX itself, visit the [[LaTeX Project|http://www.latex-project.org/]]. This plugin typesets math using [[jsMath|http://www.math.union.edu/~dpvc/jsMath/]], which is an implementation of the TeX math rules and typesetting in javascript, for your browser. Notice the small button in the lower right corner which opens its control panel.
!Installation
In addition to this plugin, you must also [[install jsMath|http://www.math.union.edu/~dpvc/jsMath/download/jsMath.html]] on the same server as your TiddlyWiki html file. If you're using TiddlyWiki without a web server, then the jsMath directory must be placed in the same location as the TiddlyWiki html file.
I also recommend modifying your StyleSheet use serif fonts that are slightly larger than normal, so that the math matches surrounding text, and \\small fonts are not unreadable (as in exponents and subscripts).
{{{
.viewer {
line-height: 125%;
font-family: serif;
font-size: 12pt;
}
}}}
If you had used a previous version of [[Plugin: jsMath]], it is no longer necessary to edit the main tiddlywiki.html file to add the jsMath <script> tag. [[Plugin: jsMath]] now uses ajax to load jsMath.
!History
* 11-Nov-05, version 1.0, Initial release
* 22-Jan-06, version 1.1, updated for ~TW2.0, tested with jsMath 3.1, editing tiddlywiki.html by hand is no longer necessary.
* 24-Jan-06, version 1.2, fixes for Safari, Konqueror
* 27-Jan-06, version 1.3, improved error handling, detect if ajax was already defined (used by ZiddlyWiki)
* 12-Jul-06, version 1.4, fixed problem with not finding image fonts
* 26-Feb-07, version 1.5, fixed problem with Mozilla "unterminated character class".
* 27-Feb-07, version 1.5.1, Runs compatibly with TW 2.1.0+, by Bram Chen
!Examples
|!Source|!Output|h
|{{{The variable $x$ is real.}}}|The variable $x$ is real.|
|{{{The variable \(y\) is complex.}}}|The variable \(y\) is complex.|
|{{{This \[\int_a^b x = \frac{1}{2}(b^2-a^2)\] is an easy integral.}}}|This \[\int_a^b x = \frac{1}{2}(b^2-a^2)\] is an easy integral.|
|{{{This $$\int_a^b \sin x = -(\cos b - \cos a)$$ is another easy integral.}}}|This $$\int_a^b \sin x = -(\cos b - \cos a)$$ is another easy integral.|
|{{{Block formatted equations may also use the 'equation' environment \begin{equation} \int \tan x = -\ln \cos x \end{equation} }}}|Block formatted equations may also use the 'equation' environment \begin{equation} \int \tan x = -\ln \cos x \end{equation}|
|{{{Equation arrays are also supported \begin{eqnarray} a &=& b \\ c &=& d \end{eqnarray} }}}|Equation arrays are also supported \begin{eqnarray} a &=& b \\ c &=& d \end{eqnarray} |
|{{{I spent \$7.38 on lunch.}}}|I spent \$7.38 on lunch.|
|{{{I had to insert a backslash (\\) into my document}}}|I had to insert a backslash (\\) into my document|
!Code
***/
//{{{
// AJAX code adapted from http://timmorgan.org/mini
// This is already loaded by ziddlywiki...
if(typeof(window["ajax"]) == "undefined") {
ajax = {
x: function(){try{return new ActiveXObject('Msxml2.XMLHTTP')}catch(e){try{return new ActiveXObject('Microsoft.XMLHTTP')}catch(e){return new XMLHttpRequest()}}},
gets: function(url){var x=ajax.x();x.open('GET',url,false);x.send(null);return x.responseText}
}
}
// Load jsMath
jsMath = {
Font: {Message: function () {}},
Setup: {inited: 1}, // don't run jsMath.Setup.Body() yet
Autoload: {root: new String(document.location).replace(/[^\/]*$/,'jsMath/')} // URL to jsMath directory, change if necessary
};
var jsMathstr;
try {
jsMathstr = ajax.gets(jsMath.Autoload.root+"jsMath.js");
} catch(e) {
alert("jsMath was not found: you must place the 'jsMath' directory in the same place as this file. "
+"The error was:\n"+e.name+": "+e.message);
throw(e); // abort eval
}
try {
window.eval(jsMathstr);
} catch(e) {
alert("jsMath failed to load. The error was:\n"+e.name + ": " + e.message + " on line " + e.lineNumber);
}
jsMath.Setup.inited=0; // allow jsMath.Setup.Body() to run again
// Define wikifers for latex
config.formatterHelpers.mathFormatHelper = function(w) {
var e = document.createElement(this.element);
e.className = this.className;
var endRegExp = new RegExp(this.terminator, "mg");
endRegExp.lastIndex = w.matchStart+w.matchLength;
var matched = endRegExp.exec(w.source);
if(matched) {
var txt = w.source.substr(w.matchStart+w.matchLength,
matched.index-w.matchStart-w.matchLength);
if(this.keepdelim) {
txt = w.source.substr(w.matchStart, matched.index+matched[0].length-w.matchStart);
}
e.appendChild(document.createTextNode(txt));
w.output.appendChild(e);
w.nextMatch = endRegExp.lastIndex;
}
}
config.formatters.push({
name: "displayMath1",
match: "\\\$\\\$",
terminator: "\\\$\\\$\\n?", // 2.0 compatability
termRegExp: "\\\$\\\$\\n?",
element: "div",
className: "math",
handler: config.formatterHelpers.mathFormatHelper
});
config.formatters.push({
name: "inlineMath1",
match: "\\\$",
terminator: "\\\$", // 2.0 compatability
termRegExp: "\\\$",
element: "span",
className: "math",
handler: config.formatterHelpers.mathFormatHelper
});
var backslashformatters = new Array(0);
backslashformatters.push({
name: "inlineMath2",
match: "\\\\\\\(",
terminator: "\\\\\\\)", // 2.0 compatability
termRegExp: "\\\\\\\)",
element: "span",
className: "math",
handler: config.formatterHelpers.mathFormatHelper
});
backslashformatters.push({
name: "displayMath2",
match: "\\\\\\\[",
terminator: "\\\\\\\]\\n?", // 2.0 compatability
termRegExp: "\\\\\\\]\\n?",
element: "div",
className: "math",
handler: config.formatterHelpers.mathFormatHelper
});
backslashformatters.push({
name: "displayMath3",
match: "\\\\begin\\{equation\\}",
terminator: "\\\\end\\{equation\\}\\n?", // 2.0 compatability
termRegExp: "\\\\end\\{equation\\}\\n?",
element: "div",
className: "math",
handler: config.formatterHelpers.mathFormatHelper
});
// These can be nested. e.g. \begin{equation} \begin{array}{ccc} \begin{array}{ccc} ...
backslashformatters.push({
name: "displayMath4",
match: "\\\\begin\\{eqnarray\\}",
terminator: "\\\\end\\{eqnarray\\}\\n?", // 2.0 compatability
termRegExp: "\\\\end\\{eqnarray\\}\\n?",
element: "div",
className: "math",
keepdelim: true,
handler: config.formatterHelpers.mathFormatHelper
});
// The escape must come between backslash formatters and regular ones.
// So any latex-like \commands must be added to the beginning of
// backslashformatters here.
backslashformatters.push({
name: "escape",
match: "\\\\.",
handler: function(w) {
w.output.appendChild(document.createTextNode(w.source.substr(w.matchStart+1,1)));
w.nextMatch = w.matchStart+2;
}
});
config.formatters=backslashformatters.concat(config.formatters);
window.wikify = function(source,output,highlightRegExp,tiddler)
{
if(source && source != "") {
if(version.major == 2 && version.minor > 0) {
var wikifier = new Wikifier(source,getParser(tiddler),highlightRegExp,tiddler);
wikifier.subWikifyUnterm(output);
} else {
var wikifier = new Wikifier(source,formatter,highlightRegExp,tiddler);
wikifier.subWikify(output,null);
}
jsMath.ProcessBeforeShowing();
}
}
jsMath.Extension.Require('AMSmath');
jsMath.Extension.Require('AMSsymbols');
//}}}
A //Java// based connector to [[Unreal Tournament]] 2004.
http://artemis.ms.mff.cuni.cz/pogamut/tiki-index.php
* People from MFF@CUNI, Prague (Cyril Brom et al.)
Coordination tasks in the TAS project:
# tracking handover = task delegation
# guarding the convoy - movement in a formation in an urban environment = joint action
What we do here is merely pure //task allocation//:
* no shared resources are considered (except for the time which is treated as an implicit resource)
** agents are assumed to be autonomous in their allocation usage, i.e., we assume that they are self-sustainable w.r.t. resources
* we assume a //flat// and //dynamic// organisational structure
* no one individual has sufficient competence and information to solve the entire problem (refer to [[Jennings, 1993|Jennings: Coordination Techniques for Distributed Artificial Intelligence]])
* we deal with //strong// goal dependencies here. Rather, I would say we deal with //task dependencies//.
** moreover, since we deal with a (almost-)flat structure, we cannot plan in advance, but rather have to escape to //Just-In-Time// goal/task dependency resolution.
* the joint goal decomposition can be assumed implicit, i.e., all agents know how to decompose goal. Just they do not possess enough capabilities to perform the behaviour(s) individually
** we can assume an HTN style decomposition and everybody knows the basic decomposition down to capabilities. But only the agent who can perform the sub-goal knows the decomposition to actions/tasks.
*** this immediately leads to an idea that in BSM, we can treat high-level goals as macros which are atomic from teamwork point of view, but compound from individual point of view - ''INTERESTING IDEA!''
*** this directly leads to implementation in the spirit of //Commitment-Oriented Programming//
* we can assume //implicit social conventions//, i.e., a single type which everybody adheres to. This simplifies peer-predictability of team members.
** implementations of social commitment seem to be of the same kind (from the AOP point of view) as individual commitments, except that they are much more parametrized (middleware, etc.)
* in the equation ''Coordination = Commitments + Conventions + Social Conventions + Local Reasoning'', we have:
# social commitments are heterogeneous and break down to individually implemented behaviours
# conventions are a matter of individual agents, no social focus is implied as far as "eventually G holds" is ensured
# social conventions should be implicit and publicly known
# local reasoning is heterogeneous and a matter of individual agents - up to the communication language
* we have a //functional// and a //spatial// organizational structure
* generally, open heterogeneous systems are prevalently flat and do not feature deep structures - consequence of entering/leaving arbitrarily - perhaps this is one of the main distinguishing features of these systems
This is an elaboration on ideas for potential research vectors/applied AI techniques which could be explored within the TAS project scenario.
!! Convoy unit
Easy prey here. The functionality of the convoy is not in the focus of this project.
* A* style of planning/re-planning
!! UGV team - scout unit
This could be the most interesting part of the game. A sketch would go along the following ideas:
* A* style of route planning/re-planning - possibly including regular ground vehicle physics handling (solved in U-Scout)
* //movement in a formation//
* //optimal area coverage//, possibly taking into account
## obstacles (urban area)
## movement in connected by line-of-sight formations
* //bidding strategies// - autonomous and distributed decision making about who goes for which destination - could have something to do with the re-use of the work done on commitment/decommitment by TKO/JVO in the U-Scout project
* possibly //coallition formation// towards building up sub-teams consisting of multiple UGVs and UAVs
* //communication protocols in the team// - open/shared with UAVs
* //coordination strategy (teamwork)// - open/shared with UAVs - note, that this is not equal to the particular algorithm of MxN tracking, what could be also solved is the approach to information exchange in the team. This can be done in a general way, i.e., exchange of goals and corresponding plans
* //engineering teamwork// - open/shared with UAVs - towards a re-usable method(ology) for programming robust teamwork
* ...
!! UAV team - surveillance unit
The functionality here is basically prescribed. In the core of the implementation strategy should be the research vectors directly stemming from the TAF project and re-using most of its functionalities. In particular:
* global area exploration - solved in TAF
* global area surveillance - solved in TAF
* local area re-exploration and surveillance - solved in TAF
* single target tracking - partially solved in TAF
* //multiple-target tracking (aka MxN tracking)// - open
* //communication protocols in the team// - open/shared with UGVs
* //coordination strategy (teamwork)// - open/shared with UGVs
* //engineering teamwork// - open/shared with UGVs
!! Tactical AgentFly II/AgentScout II research project bundle
<<matchTags "#%0 (%2)<br>^^%5^^" "\n" sort:-modified [[ Prj: TAS AND NOT project]]>>
Lin Padgham sent the paper on //learning// probabilities for behaviour execution. This is an interesting avenue for extending the PBSM framework.
* ''check the paper!!!''
<<<
Hi [[Koen|Koen Hindriks]] and Peter,
here is the latest version of our work on using probabilistic context conditions for BDI, and learning these.
It is not actually published yet - we need to do a bit more work on the evaluation aspects and have some more
+experimentation and analysis in process. So please don't circulate it any further.
We have discussed that moving to a probabilistic representation regarding context conditions would be
+advantageous for various things as well as learning, so would certainly be interested in potential
+collaboration around this issue.
Regards,
Lin
<<<
A development process that involves any amount of tedium will eventually be done poorly or not at all.
//Matt Blodgett's First Law of Software Development//
A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering.
//Freeman Dyson//
In theory there is no difference between theory and practice. In practice there is.
//Yogi Berra//
Good judgment comes from experience, and experience comes from bad judgment.
//Fred Brooks//
Taken from [[embedded.com|http://www.embedded.com/221901489?cid=NL_embedded]]
//OS is an open-source, meta-operating system for your robot. It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers. ROS is similar in some respects to 'robot frameworks,' such as Player, YARP, Orocos, CARMEN, Orca, MOOS, and Microsoft Robotics Studio.
The ROS runtime "graph" is a peer-to-peer network of processes that are loosely coupled using the ROS communication infrastructure. ROS implements several different styles of communication, including synchronous RPC-style communication over services, asynchronous streaming of data over topics, and storage of data on a Parameter Server. These are explained in greater detail in our Conceptual Overview.
ROS is not a realtime framework, though it is possible to integrate ROS with realtime code. The Willow Garage PR2 robot uses a system called pr2_etherCAT, which transports ROS messages in and out of a realtime process. ROS also has seamless integration with the Orocos Real-time Toolkit. //
-- [[http://www.ros.org/wiki/]]
See also [[Willow Garrage]]
An agent should be
# autonomous
# proactive
# reactive
I strongly believe that the whole game around APLs is about computational model of reactivity, i.e. managing a kind of non-determinism and parallelism.
Sources:
* the [[TEAMCORE|http://teamcore.usc.edu/]]'s website on [[Machinetta|http://teamcore.usc.edu/doc/Machinetta/]].
* Paper by Paul Scerri, David V. Pynadath, Nathan Schurr, Alessandro Farinelli, Sudeep Gandhe and Milind Tambe: [[Team Oriented Programming and Proxy Agents: The Next Generation|http://www.cs.cmu.edu/~pscerri/papers/ProMASBook.pdf]]
The //proxy approach// to programming teamwork is basically based on the idea that there is a //separate// platform running the teamwork components (proxies) of agents which are //separated// and //outsourced// from the main agent code. These proxies are connected with main agents' intelligence components through an open commlink and take care of all the relevant teamwork activities. Each proxy implements
# a coordination strategy w.r.t. other proxies and
# a commlink with the "owner" agent
Otherwise there are //teamwork-oriented programs// (TOP) specified within the teamwork platform which direct and regulate the teamwork details, i.e., specify the team goals and regulate role assignment(?), etc.
Possibly there can be more of these platforms and they can even be distributed (the add-on of Machinetta to the original STEAM/TEAMCORE systems - ???).
!! Quick personal notes:
* it seems to me that such systems must always be rather brittle in that the team can then implement just a single TOP and teams cannot be automagically formed/dissolved.
** moreover, the autonomy of agents is here rather limited in that the agent is not able to autonomously change its mind regarding the teamwork during the execution of a TOP. In the case of adaptive/learning agents, this might pose a serious limitation.
* on the other hand, it allows to program and more importantly debug teamwork functionality in a centralized and probably also more concise manner.
* another problem of this approach is that it //does not// support good software engineering. I.e., the team must be implemented by a single body (a programmer/team). This does not facilitate code re-use by 3rd party developers, nor leaves the MAS open w.r.t. newly coming heterogeneous agents possibly implemented by independent 3rd party developers.
/***
|Name|RearrangeTiddlersPlugin|
|Source|http://www.TiddlyTools.com/#RearrangeTiddlersPlugin|
|Version|2.0.0|
|Author|Eric Shulman|
|OriginalAuthor|Joe Raii|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides|Story.prototype.refreshTiddler|
|Description|drag tiddlers by title to re-order story column display|
adapted from: http://www.cs.utexas.edu/~joeraii/dragn/#Draggable
changes by ELS:
* hijack refreshTiddler() instead of overridding createTiddler()
* find title element by className instead of elementID
* set cursor style via code instead of stylesheet
* set tooltip help text
* set tiddler "position:relative" when starting drag event, restore saved value when drag ends
* update 2006.08.07: use getElementsByTagName("*") to find title element, even when it is 'buried' deep in tiddler DOM elements (due to custom template usage)
* update 2007.03.01: use apply() to invoke hijacked core function
* update 2008.01.13: only hijack core function once. (allows for dynamic loading of plugin via bookmarklet)
* update 2008.10.19: added onclick popup menu with 'move to top' and 'move to bottom' commands
***/
//{{{
if (Story.prototype.rearrangeTiddlersHijack_refreshTiddler===undefined) {
Story.prototype.rearrangeTiddlersHijack_refreshTiddler = Story.prototype.refreshTiddler;
Story.prototype.refreshTiddler = function(title,template)
{
this.rearrangeTiddlersHijack_refreshTiddler.apply(this,arguments);
var theTiddler = document.getElementById(this.idPrefix + title); if (!theTiddler) return;
var theHandle;
var children=theTiddler.getElementsByTagName("*");
for (var i=0; i<children.length; i++) if (hasClass(children[i],"title")) { theHandle=children[i]; break; }
if (!theHandle) return theTiddler;
Drag.init(theHandle, theTiddler, 0, 0, null, null);
theHandle.style.cursor="move";
theHandle.title="drag title to re-arrange tiddlers, click for more options..."
theTiddler.onDrag = function(x,y,myElem) {
if (this.style.position!="relative")
{ this.savedstyle=this.style.position; this.style.position="relative"; }
y = myElem.offsetTop;
var next = myElem.nextSibling;
var prev = myElem.previousSibling;
if (next && y + myElem.offsetHeight > next.offsetTop + next.offsetHeight/2) {
myElem.parentNode.removeChild(myElem);
next.parentNode.insertBefore(myElem, next.nextSibling);//elems[pos+1]);
myElem.style["top"] = -next.offsetHeight/2+"px";
}
if (prev && y < prev.offsetTop + prev.offsetHeight/2) {
myElem.parentNode.removeChild(myElem);
prev.parentNode.insertBefore(myElem, prev);
myElem.style["top"] = prev.offsetHeight/2+"px";
}
};
theTiddler.onDragEnd = function(x,y,myElem) {
myElem.style["top"] = "0px";
if (this.savedstyle!=undefined)
this.style.position=this.savedstyle;
};
theHandle.onclick=function(ev) {
ev=ev||window.event;
var p=Popup.create(this); if (!p) return;
var b=createTiddlyButton(createTiddlyElement(p,"li"),
"\u25B2 move to top of column ","move this tiddler to the top of the story column",
function() {
var t=story.getTiddler(this.getAttribute("tid"));
t.parentNode.insertBefore(t,t.parentNode.firstChild); // move to top of column
window.scrollTo(0,ensureVisible(t));
return false;
});
b.setAttribute("tid",title);
var b=createTiddlyButton(createTiddlyElement(p,"li"),
"\u25BC move to bottom of column ","move this tiddler to the bottom of the story column",
function() {
var t=story.getTiddler(this.getAttribute("tid"));
t.parentNode.insertBefore(t,null); // move to bottom of column
window.scrollTo(0,ensureVisible(t));
return false;
});
b.setAttribute("tid",title);
Popup.show(p,false);
ev.cancelBubble=true; if (ev.stopPropagation) ev.stopPropagation(); return(false);
};
return theTiddler;
}
}
/**************************************************
* dom-drag.js
* 09.25.2001
* www.youngpup.net
**************************************************
* 10.28.2001 - fixed minor bug where events
* sometimes fired off the handle, not the root.
**************************************************/
var Drag = {
obj:null,
init:
function(o, oRoot, minX, maxX, minY, maxY) {
o.onmousedown = Drag.start;
o.root = oRoot && oRoot != null ? oRoot : o ;
if (isNaN(parseInt(o.root.style.left))) o.root.style.left="0px";
if (isNaN(parseInt(o.root.style.top))) o.root.style.top="0px";
o.minX = typeof minX != 'undefined' ? minX : null;
o.minY = typeof minY != 'undefined' ? minY : null;
o.maxX = typeof maxX != 'undefined' ? maxX : null;
o.maxY = typeof maxY != 'undefined' ? maxY : null;
o.root.onDragStart = new Function();
o.root.onDragEnd = new Function();
o.root.onDrag = new Function();
},
start:
function(e) {
var o = Drag.obj = this;
e = Drag.fixE(e);
var y = parseInt(o.root.style.top);
var x = parseInt(o.root.style.left);
o.root.onDragStart(x, y, Drag.obj.root);
o.lastMouseX = e.clientX;
o.lastMouseY = e.clientY;
if (o.minX != null) o.minMouseX = e.clientX - x + o.minX;
if (o.maxX != null) o.maxMouseX = o.minMouseX + o.maxX - o.minX;
if (o.minY != null) o.minMouseY = e.clientY - y + o.minY;
if (o.maxY != null) o.maxMouseY = o.minMouseY + o.maxY - o.minY;
document.onmousemove = Drag.drag;
document.onmouseup = Drag.end;
Drag.obj.root.style["z-index"] = "10";
return false;
},
drag:
function(e) {
e = Drag.fixE(e);
var o = Drag.obj;
var ey = e.clientY;
var ex = e.clientX;
var y = parseInt(o.root.style.top);
var x = parseInt(o.root.style.left);
var nx, ny;
if (o.minX != null) ex = Math.max(ex, o.minMouseX);
if (o.maxX != null) ex = Math.min(ex, o.maxMouseX);
if (o.minY != null) ey = Math.max(ey, o.minMouseY);
if (o.maxY != null) ey = Math.min(ey, o.maxMouseY);
nx = x + (ex - o.lastMouseX);
ny = y + (ey - o.lastMouseY);
Drag.obj.root.style["left"] = nx + "px";
Drag.obj.root.style["top"] = ny + "px";
Drag.obj.lastMouseX = ex;
Drag.obj.lastMouseY = ey;
Drag.obj.root.onDrag(nx, ny, Drag.obj.root);
return false;
},
end:
function() {
document.onmousemove = null;
document.onmouseup = null;
Drag.obj.root.style["z-index"] = "0";
Drag.obj.root.onDragEnd(parseInt(Drag.obj.root.style["left"]), parseInt(Drag.obj.root.style["top"]), Drag.obj.root);
Drag.obj = null;
},
fixE:
function(e) {
if (typeof e == 'undefined') e = window.event;
if (typeof e.layerX == 'undefined') e.layerX = e.offsetX;
if (typeof e.layerY == 'undefined') e.layerY = e.offsetY;
return e;
}
};
//}}}
/***
|Name|RecentChangesPlugin|
|Source|http://www.TiddlyTools.com/#RecentChangesPlugin|
|Version|2.1.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|display droplist of recently changed tiddlers with goto, edit, and preview buttons|
!!!!!Usage
<<<
The {{{<<recentChanges>>}}} macro displays a droplist of all tiddlers that have been changed within the last N days (default=10 days).
<<<
!!!!!Examples
<<<
{{smallform{
{{{<<recentChanges>>}}}
><<recentChanges>>
or
{{{<<recentChanges #ofdays summary>>}}}
>where:
>* #ofdays specifies the time limit for list changed tiddlers. Use 0 (zero) to list all tiddlers in the document
>* "summary" is a keyword that outputs only the summary text (without the droplist or buttons)
>{{{<<recentChanges 14 summary>>}}}
><<recentChanges 14 summary>>
or
{{{<<recentChanges #ofdays previewheight previewclass>>}}}
>where:
>* #ofdays specifies the time limit for list changed tiddlers. Use 0 (zero) to list all tiddlers in the document
>* previewheight is a CSS height measurement and sets the FIXED height of the tiddler preview area (default is 15em)
>* previewclass is any CSS classname, and can be used to apply custom styles to the preview area (default is to use the standard 'viewer' class)
>{{{<<recentChanges 14 10em groupbox>>}}}
><<recentChanges 14 10em groupbox>>
}}}
<<<
!!!!!Revisions
<<<
2008.07.01 [2.1.0] added optional "summary" keyword for simply text output
2008.05.01 [2.0.1] fixup for titles with double-quotes
2007.07.26 [2.0.0] re-written as plugin
2006.10.02 [1.0.0] initial release (as inline script ShowRecentChanges)
<<<
!!!!!Code
***/
//{{{
version.extensions.RecentChangesPlugin= {major: 2, minor: 1, revision: 0, date: new Date(2008,7,1)};
config.shadowTiddlers.RecentChanges="<<recentChanges>>";
config.macros.recentChanges = {
layout: '<form><!--\
--><select size=1 name="list" style="width:69.5%" \
onchange=" \
this.form.goto.disabled=this.form.edit.disabled=this.form.preview.disabled=!this.value.length; \
var target=this.parentNode.parentNode.nextSibling; removeChildren(target); \
if (!this.value.length) \
{ target.style.display=\'none\'; this.form.preview.value=\'preview\'; } \
else if (target.style.display==\'block\') { \
wikify(\'<\'+\'<tiddler [[\'+this.value+\']]>\'+\'>\',target); \
target.style.display=\'block\'; \
this.form.preview.value=\'done\'; \
} \
"><!--\
-->%options%<!--\
--></select><!--\
--><input type="button" name="goto" value="goto" disabled title="view selected tiddler" style="width:10%" \
onclick="var target=this.parentNode.parentNode.nextSibling; removeChildren(target); \
target.style.display=\'none\'; this.form.preview.value=\'preview\'; \
story.displayTiddler(story.findContainingTiddler(this),this.form.list.value); \
"><!--\
--><input type="button" name="edit" value="edit" disabled title="edit selected tiddler" style="width:10%" \
onclick="var target=this.parentNode.parentNode.nextSibling; removeChildren(target); \
target.style.display=\'none\'; this.form.preview.value=\'preview\'; \
story.displayTiddler(story.findContainingTiddler(this),this.form.list.value,DEFAULT_EDIT_TEMPLATE); \
"><!--\
--><input type="button" name="preview" value="preview" disabled title="show/hide tiddler preview" style="width:10%" \
onclick="var target=this.parentNode.parentNode.nextSibling; \
if (this.value==\'preview\') { \
removeChildren(target); \
wikify(\'<\'+\'<tiddler [[\'+this.form.list.value+\']]>\'+\'>\',target); \
target.style.display=this.form.list.value.length?\'block\':\'none\'; this.value=\'done\'; \
} else { \
removeChildren(target); \
target.style.display=\'none\'; this.value=\'preview\'; \
} \
"><!--\
--></form>',
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var days=10; if (!isNaN(params[0])) days=parseInt(params[0]); // time limit in days (use 0 for all tiddlers)
var summary=params[1]&¶ms[1].toLowerCase()=="summary"; if (summary) params.shift();
var height='15em'; if (params[1]) height=params[1]; // preview area fixed height
var previewclass='viewer'; if (params[2]) previewclass=params[2]; // preview area CSS class
var tiddlers=store.getTiddlers('modified','excludeLists').reverse();
var count=tiddlers.length;
if (days) {
var timelimit=(new Date()).getTime()-86400000*days;
for (var count=0; count<tiddlers.length && tiddlers[count].modified>timelimit; count++);
}
var s=count+' tiddlers have changed since ';
s+=new Date(timelimit).formatString("DDD, MMM DDth YYYY 0hh:0mm");
s+=' ('+days+' days ago)';
if (summary)
{ wikify(s,place); return; }
var opts='<option value="">'+s+'</option>';
for (var i=0; i<count; i++) { var t=tiddlers[i];
opts+='<option value="'+t.title.replace(/"/g,""")+'">';
opts+=t.modified.formatString('YYYY.0MM.0DD 0hh:0mm')+' - '+t.title;
opts+='</option>';
}
createTiddlyElement(place,"div").innerHTML=this.layout.replace(/%options%/,opts);
var preview=createTiddlyElement(place,"div",null,previewclass);
preview.style.display='none';
preview.style.whiteSpace='normal';
preview.style.overflow='auto';
preview.style.height=height;
}
}
//}}}
/***
''Name:'' ReferencesPlugin
''Author:'' Garrett Lisi
''Description:'' Places a comma separated list of referring notes at the bottom of each note -- replacing the "references" command bar button.
''Installation:'' Copy this note, change the [[StyleSheet]] to set the references class style, and add a line in the [[ViewTemplate]].
''Code:''
***/
/*{{{*/
config.macros.references = {};
config.macros.references.handler = function(place,macroName,params,wikifier,paramString,note)
{
var references = store.getReferringNotes(note.title);
if(references.length>0)
{
// createTiddlyText(place,"\xAB ");
createTiddlyLink(place,references[0].title,true);
}
for(var r=1; r<references.length; r++)
if(references[r].title != note.title)
{
createTiddlyText(place,", ");
createTiddlyLink(place,references[r].title,true);
}
}
/*}}}*/
!!! Personal research
* [[GACR: call for funding post-doc projects|http://civetta.gacr.cas.cz/wordpress/?p=521]]
** typical deadline: May of a calendar year
!!! Germany
* [[GACR+DFG: Bilateral cooperation with Germany|http://www.gacr.cz/cz/bilat-01uvod.htm]], [[DFG|http://www.dfg.de/dfg_profil/im_internationalen_kontext/internationale_partner/Tschechische_Republik/index.html]]
** typical deadline: May of a calendar year
** research projects, mobility
* [[MSMT+DAAD|http://www.msmt.cz/mezinarodni-vztahy/spolkova-republika-nemecko-1]], [[BMBF/DAAD|http://www.bmbf.de/foerderungen/2198.php]], [[programme details|http://www.avcr.cz/data/zho/aktuality/A-2009-02-27_ppp_daad.pdf]]
** mobility
!!! Slovakia
* [[MSMT+MSSR|http://www.msmt.cz/mezinarodni-vztahy/slovensko]]
!!! Open tasks:
* the thesis summary journal paper
** the BSM framework summary
** DCTL* logic/possibly a [[process logic]] variant of the framework
** relationship to BDI
** relationship to the original reactive planning
* explore the [[GTD vs. BDI]] idea
* explore the idea [[Note on goal types in APLs]]
* check the idea on [[Active goals in a BSM]]
http://news.bbc.co.uk/2/hi/technology/8172739.stm
Excerpt:
A team of fire-fighting robots has been unveiled by defence contractor QinetiQ at a demonstration in London.
The display showcased a quartet of robots aimed at tackling the particular risk of fires involving cylinders of the industrial gas acetylene.
The robots range from a nimble, stair-climbing reconnaissance unit to a diesel-powered robot with a large claw.
''Argument for (behavioural) robotics people in favor of agent oriented programming:''
As the field of robotics is moving from single robot systems and low level control to multi-robotics and coordinated action of robots, the communication and in turn processing of complex symbolic information comes to the forefront of the interest in cognitive robotics as well (again after a move towards sub-symbolic methods). [[Behavioural State Machines]] is a control architecture for non-critical cognitive agents (aka cognitive robots).
* the ultimate goal is to create autonomous intelligent and social robots.
* the field of robotics can be seen as divided into two different main streams of research:
** ''bottom-up'': currently the more successful one which leads to creating embodied robots. Here they try to come up with approaches which produce more and more complex robotics systems and sets of their capabilities. We can see this field as generating skills for robots - capabilities/atomic behaviours. They try to program the body of a robot here. Here reactivity rules and is much better than anything else. Even POMDPs are of such kind - just with some pre-planning phase.
** ''top-down'': this is more like the agent oriented programming. Here we try to program the brian of the robot. Includes approaches such as planning, KRR, etc. This currently does not lead to real robots - most of the time. And if so, the agents created here are extremely simplistic and trivial - almost ridiculous. However it allows for high level reasoning and communication which is vital for the ultimate goal...
What we need are synergistic approaches enabling joining of the two. BSM approach is such a thing... This is the field of hybrid approaches.
* Till now, often we saw hybrid approaches which tried to add reactivity into otherwise deliberative approaches. BSM is different. It goes for a primarily reactive approach and adds deliberation to it as a second class citizen.
* 3-tiered architecture provides layers of hybridization and from time to time passes control to deliberative layers. BSM is always reactive, it exploits deliberation.
* So the distinguishing feature of BSM approach is that it gives full control to reactive computational model and exploits deliberation only...
''IMPORTANT THOUGHT''
Roles can be also seen as collections of commitments specifications. Now it becomes clear that instead of //enacting// a role, or a particular commitment within it (or outside of any role!!!) is spontaneous,instead of being explicit as with other frameworks!!!
@@ [[Sasha Ossowski]]: //Co-ordination in Artificial Agent Societies: Social Structures and Its Implications for Autonomous Problem-Solving Agents//, LNAI 1535, 1999
-- [[link|http://www.springer.com/computer/artificial/book/978-3-540-65495-7]]@@
* especially the chapter //3. Disitributed Artificial Intelligence// seems to be relevant as a survey of coordination technologies in AI (as of 1999 of course)
[[homepage|http://www.ia.urjc.es/cms/en/sossowski]]
|Name|SaveFromWebPluginInfo|
|Source|http://www.TiddlyTools.com/#SaveFromWebPlugin|
|Documentation|http://www.TiddlyTools.com/#SaveFromWebPluginInfo|
|Version|1.3.1|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|documentation|
|Requires||
|Overrides||
|Description|documentation for SaveFromWebPlugin|
Normally, when you are viewing a TiddlyWiki document over the web (i.e., not via {{{file://}}}) and you select the "save changes" (or "save to disk") command, an error message is displayed: //__"You need to save this TiddlyWiki to a file before you can save changes."__// This plugin extends the use of {{{<<saveChanges>>}}} so that when you are viewing and/or editing a remote TiddlyWiki document, instead of receiving this somewhat confusing and unhelpful message, you can still click the "save changes" (or "save to disk") command to ''store a copy of the remote document directly onto your local filesystem'', //including any unsaved tiddler changes/additions you have made while working on-line.//
!!!!!Usage
<<<
When you select <<saveChanges>> while viewing a remote document (i.e., a URL starting with http: rather than file:), the plugin first ''retrieves the TiddlyWiki core source code from the original document'' file stored on the remote server. Then, it ''combines that core source with the tiddlers'' contained in the currently loaded document, ''including any changes you have made.''
While the next step //should// be to simply write the merged core+tiddler data directly to your hard drive, certain JavaScript features, such as reading/writing directly to the local filesystem, require expanded "cross-domain" privileges that are normally restricted for use only with ''signed'' scripts. Although some browsers will let you grant filesystem permissions to a remotely-loaded script, this usually involves either a series of popup confirmation messages or manually re-configuring (and/or disabling) your browser's built-in security protections, which often include settings and options that most users find difficult to understand and inconvenient to access.
To avoid these security complications, the "save from web" processing requires just a few additional steps to prepare the modified document and deliver it to your browser: rather than writing the document data directly to the local filesystem, the plugin ''sends the merged core+tiddler data to a small companion script installed on the remote server'' (see savefromweb.php, below). This simple "reflector" script then immediately ''downloads the new document data back to the browser'', which prompts you to either open the downloaded document for viewing or save it to your local hard drive. Once the document has been stored on your filesystem, you can open that copy in your browser and work offline with full access to all TiddlyWiki features.
Important note for users of Internet Explorer's Popup Blocker feature...
>{{block{
//The default security settings of IE's "Popup Blocker" feature will warn you whenever an attempt is made to download a file in response to a scripted action such as the internal javascript processing performed by SaveFromWebPlugin. However, if you then click IE's yellow warning message and select the 'download this file...' menu command, this will also cause IE to attempt a 'page transition' away from the currently loaded TiddlyWiki document... but, because there are unsaved changes in the document, you will first receive a confirmation message, allowing you to cancel the page transition. Regrettably, this also prevents the download from succeeding. Unfortunately, if you permit the page transition to occur, then your TiddlyWiki document is immediately reloaded and all the unsaved tiddler changes are discarded... and the download still fails to complete!//
''__To permit SaveFromWebPlugin to function properly with Internet Explorer, you will need to adjust the "download" security setting...__''
#From the ''Tools > Internet Options > Security'' tab,
#Select the "Internet" security zone (or what ever zone you are using to view the remote document)
#Press the "Custom level..." button
#In the "Settings" listbox, scroll to the "Downloads" section
#''ENABLE "automatic prompting for downloads"''(the first setting in the section)
#Press OK to accept the new settings.
}}}
<<<
!!!!!Configuration
> see [[SaveFromWebConfig]]
!!!!! Server script installation
<<<
On your web server, in the same directory as your published document, create a file called ''{{{savefromweb.php}}}'', containing the following PHP server-side script. //(note: you can actually give this script any name you like, and place it at //any// URL, even one that is on a different domain from the document you are saving. However, to do so you must specify the server-side script location using the plugin's configuration settings//
//{{{
<?php
// savefromweb.php
// Author: Eric L. Shulman / ELS Design Studios
// Source: http://www.TiddlyTools.com/savefromweb.php
// License: http://www.TiddlyTools.com/#LegalStatements
// Usage: install the php script on the server in the same directory as your TiddlyWiki document(s)
// This script acts as a 'reflector', so that any contents sent to it (via form POST) will
// be sent back to the browser as a binary file. The browser then prompts you to
// save the content to a local file. Because this process uses the browser's built-in
// download-and-save/open handler, it does not require security permissions to access
// the local filesystem.
$args=$_POST;
header('Pragma: private');
header('Cache-control: private, must-revalidate');
header('Content-type: application/binary; charset="UTF-8"');
header('Content-disposition: attachment; filename="'.$args['filename'].'"');
$c=$args['contents'];
$c=str_replace("\\'","'",$c); // decode single-quotes
$c=str_replace("\\\"","\"",$c); // decode double-quotes
$c=str_replace("\\\\","\\",$c); // decode backslashes
$c=str_replace("\r\n","\n",$c); // change CRLF to LF
print $c;
?>
//}}}
<<<
!!!!!Direct filesystem access (browser security permissions)
<<<
Although sending the merged document data from browser to server and back again allows it to be saved to your filesystem without requiring you to extensively re-configure your browser's built-in security protections, it also increases the overall processing time because the document's data is actually being transmitted //three// times: it is first retrieved from the remote server to get the TiddlyWiki core source; then, after merging with the updated tiddler data, it is sent back to the server, which immediately 'reflects' it back to the browser for final handling by the built-in "file download" interface.
However, ''if you are accessing a "trusted site"'' (perhaps on a server within a secure private network), depending upon the specific options provided by your browser, ''you may be able to eliminate the round-trip processing by authorizing the appropriate filesystem security permissions in your browser''. When filesystem access has been permitted, instead of making the round trip with the merged core+tiddler data, the plugin will directly prompt you for a destination path/file, using your computer's "native" path/file selection interface, and then write new the TiddlyWiki document data directly to the indicated location on your local file system.
FireFox users: please see [[FAQ_BrowserSecurity]] for information on configuring your browser to permit remote filesystem access from trusted sites
<<<
!!!!!Revisions
<<<
2008.09.29 [1.3.1] in saveFromWeb(), do NOT convert UTF8 to Unicode when merging retrieved source for submission to server-side reflector script. Fixes mangling of international characters and symbols.
2008.01.08 [*.*.*] plugin size reduction: documentation moved to SaveFromWebPluginInfo
2007.08.08 [1.3.0] added caching of the downloaded TW core source code so it only has to be retrieved once.
2007.08.08 [1.2.5] Added option to 'pre-fetch' the TW core so background download-and-cache is performed each time the document is loaded. added option to try using direct filesystem access (with permissions) to bypass the round-trip through the server-side reflector script if the connection to the network is dropped after the document was loaded into the browser. If permissions are not granted, fallback to use the server-side reflector script.
2007.08.07 [1.2.0] removed 'download only' optimization. The round-trip takes longer, but permits the reflector script to be located ANYWHERE on the net, at ANY valid URL, instead of having to use the same server location as the remote document.
2007.07.27 [1.1.1] new documentation and code cleanup
2007.07.26 [1.1.0] re-wrote to support savefromweb.php remote "reflector" script. Allows use of browser's native download dialog to receive file as a fallback alternative to using local filesystem I/O (which would require additional security permissions)
2007.06.27 [1.0.1] in saveFromWeb(), pass content from server through convertUnicodeToUTF8() before writing to file.
2007.06.26 [1.0.0] initial release
<<<
!! The problem
//Formulate a scenario integrating TAF2 and U-Scout domains (aka TAS) which would provide a basis for research in ''coordination''.//
!! Requirements on the research methodology
# //transferability:// any problem we'll go into shouldn't be application domain specific, but rather it should be transferable to other (related) domains as well. This amounts to formulation of a dual //control problem// (as in control group) which gives us feedback on the quality of our solutions.
** a good candidate for the TAS domain seems to be the USAR (Urban Search and Rescue) domain. The problem tackled there seem to have relevance in the TAS domain - or generally in urban military operations scenarios.
# //evaluation:// the evaluation should be sound w.r.t., generality of the research problem. This has to do with transferability (above).
** the scenario should be "parametrizable" and to properly evaluate it we should run a number of experiments with a range of input configurations.
# //minimality:// the scenario should be no-nonsense minimalistic one. I.e., whatever can be thrown out without sacrificing the identified research problems should go away.
!! The scenario
!!! Basis
__INPUT:__
# map of roads in the theatre
# number of positioned ground troops (convoy)
# number of positioned ground scout units (UGVs)
# number of positioned aerial surveillance/tracking units (UAVs)
# number of positioned ground adversary units (civilians)
# number of positioned evacuees (VIPs)
# position on the map (base)
__GOAL:__
The task of the task force consisting of the convoy, UGVs and UAVs is to evacuate the VIPs from the operational theatre and transport them to the base.
__SUBTASKS:__
* the convoy units are capable of performing the task of extraction and transportation. They decide about the direction in which they move and they move together as a single unit (postransferablesibly they could split - would it be ever necessary?)
* the task of civilians is to obstruct the task force in achieving their task. By a simple presence of a crowd (e.g., >10 civilian units) on a road, this might become blocked for the convoy.
* UGVs have the capability to perceive the environment in the line of sight (perhaps limited to a certain) and they can secure an area by their simple presence. In the case of need UGV could have the capability to track a target by following it.
* UAVs have the capability to explore an area and track targets.
* VIPs are slowly randomly moving as well. They are attracted by the convoy only when in the line of sight. Their initial position is not precisely known to the task force, just a segment of their most probable position. Thus the reconnaissance have to find them first and later track them.
__IMPLEMENTATION DETAILS:__
* civilians vs. convoy units: civilians are attracted to the convoy units in a correlation with the convoy units in sight. The relationship might be implemented as a potential field.
* UGVs vs. civilians: civilians are repelled by a UGV. The relationship might be implemented as a potential field.
* civilians vs. civilians: they should perform a kind of flocking/swarming behaproblem (viour. Again, could be implemented as a potential field.
__SCENARIO SKETCH:__
The convoy decides where to go and plans its own way. It relays this information to UGVs and UAVs which 1) explore the area to which the convoy is to move in the close future (UAVs, UGVs) and 2) secure the area by repelling the civilians from the roads along which the convoy will move (UGVs). This could be done by capturing the strategically important points around the road by UGV units and their subsequent continuous repositioning while the convoy moves. The chain of command is therefore: convoy -> UGVs/UAVs -> UAVs. The hierarchy of information escalation/reporting is: UAVs --> UGVs --> convoy.
the
The reconnaissance units identify potential hot-spots in the area and track them (crowds) in order to plan ahead the routes. Important are the hot-spots close to the planned routes, with a declining level of importance with the distance. Upon their identification they report the problems up the information reporting (escalation) hierarchy what might finally result in changing the planned route. In order to make the task interesting/difficult, there should be significantly more crowds/hot-spots than the task force tracking capability (mainly UAVs + part of UGVs).
a kind of
__MEASURE OF SUCCESS:__
(rather weak thoughts here)
# //system robustness// - there is an inspiring concept of "intelligence" in complex systems science where it is defined as "system robustness" against human actors. I.e., the system intelligence is related to the number of basic units which can obstruct the system functionality.
** i.e., we aim for coordination mechanisms which are robust against possibly large number of adversaries.
# //achieving the goal// under varying input conditions. I.e., different terrains, differing number of civilian units, etc.
** this is rather binary. Somehow seems to have something to do with the previous point.
__ASSORTED NOTES:__
* it seems more robust to keep the security corridor around ttransferablehe convoy as convex as possible. Less convex, or non-convex shapes are prone to being broken and isolated by the civilians - problem!
!! Relationship to prior ATG work
# re-use of the algorithms by TKO/JVO on ground scout reconnaissance and convoy moving
# re-use of the work on TAF, i.e. area surveillance
# re-use of and towards improving of the work on target tracking
# //basis for integration with the (future) work on M2N tracking// by JVO - even with both aerial and ground variants (BTW any coordination on such tracking should cover both by a single approach - //a good dual control problem!!!//).
# potentially re-use of the work by TKO/JVO on patterns of "commitment handling" - delegation, dropping a commitment, etc.
!! Relationship to related domains
* the problem of moving in a (ideally convex) formation in a hostile/difficult is also explored in USAR area
* it also seems to have something to do with the problem of building and maintaining an ad-hoc Wi-Fi communication network in a certain area. The perimeter of UGV "security" and the need to keep the covered area continuous and ideally convex very much resembles the task of maintaining a reliable network. In this case the network is even moving...
* from the point of view of the UAVs, a slight complication when the VIP positions are completely unknown to the task force would amount to a variant of the water-disaster search operation - large + possibly complex area, difficult to victims...
!! Potential vectors of research topics
(very rough initial thoughts)
# programming teamwork (my own personal interest) with using experience from the past work, see also #1 in the short-term plan
** a basis for future development and study of code patterns for teamwork (the Marie-Curie style sub-project)
** yet another evaluation case study for the BSM/Jazzyk framework
# movement in a formation(?)
# building up a field ad-hoc communication network
# M2N tracking
# communication/negotiation protocols in teamwork in the setup such as the one described
# team formation? - very much future oriented...
!! Short-term plan proposal and questions to be resolved soon
# todo: re-implement the BSM/Jazzyk language in Java and provide integration with the ATG software stack
# todo: re-implement (parts) of the current TAF2/U-Scout (???) agents in the resulting language
** in the case of success, this work could also have a longer term impact on other projects.
# todo: further work out the details of the scenario
# todo/decide: propose an evaluation framework for the scenario and the research problems identified
# decide: what are the things which have to be done in the TAF2/U-Scout scenarios which enable this kind of scenario?
# decide: what would be the communication protocols and communication middleware used in the project?
!! The problem
This note addresses the following question:
<<<
@@//How to usefully integrate adversarial planning into TAS coordination scenarios? (in at attractive manner)//@@
<<<
!! The scenario idea
The following proposal can be seen as a modification of the old [[convoy guarding scenario|Scenario proposal draft]] proposal. The core idea is to turn the convoy into an adversary of the protecting UGVs (they were anyway very much independent from it and its internal intentions). Now we have a smart mobile target, be it a civilian, or a UGV moving through an urban terrain and actively trying to escape the hunters/trackers. The task of the blue team is to keep in touch with the target and every now and then (can be configurable through the C2C interface) take a snapshot of the target using different sensors. This loosely corresponds to trying to take a picture of the same target from above (position), as well as from a side (identification), or possibly using another sensors (e.g., a hypothetical UGV-mounted mobile acoustic sensor). Simply, the tracking team has to maintain a formation around the target, even when it enters inaccessible areas, etc.
This story now integrates 3 main elements wished in the TAS project:
# //smart target// algorithms employed by the red unit (the target),
# //coordination// in terms of repeated synchronized //joint action// implemented by the blue team (tracker), and finally
# //adversarial reasoning// implemented on the blue team's side to deal with situations when the target is temporarily lost, or escapes to areas inaccessible to some of the team members.
!! Abstraction
The problem can be re-formulated as a //hide-and-seek// game. Take a heterogeneous mobile team of sensors, a mobile smart target and an area inaccessible to the team. The area is relatively large and has several entrances of varying width. Upon the target's entering of the area, the problem is to predict the behaviour/movements of the target so that the team can take strategically important positions near the area escape routes and depending on the adversary model (the target) maximize the chance of capturing the target.
In this game, we can then run different configurations (of teams and the area) and employ various models of adversarial reasoning.
!! Resulting notes
* [[A quick side note on extremal cases in adversarial reasoning]]
{{valignTop{
| ''<<tag [[To Do]] "Pending tasks">>'' | ''<<tag Done "Completed tasks">>'' |
|<<matchTags {{"<<tiddler CheckboxToggleTag with: Done [[To Do]] %0\>\> %0"}} "\n" To Do>>|<<matchTags {{"<<tiddler CheckboxToggleTag with: Done [[To Do]] %0\>\> %0"}} "\n" Done>>|
}}}
A collection of manuals on how to to science and related activities.
!! General research methodology
<<tiddler [[How to: general research methodology]]>>
!! PhD research/thesis
<<tiddler [[How to: PhD]]>>
!! Writing good research papers
<<tiddler [[How to: write papers]]>>
!! Designing a talk/slides
<<tiddler [[How to: talks]]>>
!! Grant proposals
<<tiddler [[How to: research grants]]>>
!! Peer review process
<<tiddler [[How to: peer review]]>>
* [[How to: general research methodology]]
* [[How to: PhD]]
* [[How to: write papers]]
* [[How to: talks]]
* [[How to: research grants]]
* [[How to: peer review]]
Vannevar Bush;s report to Pres. F.D. Roosvelt. The basic principles for policies on research and science.
http://www.nsf.gov/od/lpa/nsf50/vbush1945.htm
!! CLIMA-X
!!! Post-proceedings preparation
* --check the list of submissions--
* --what's deadline?--
* organize the reviewing process
* what are the requirements from Springer on the submission format?
!! ProMAS'10
* website@agents - asap!
* CfP
!! Review for Fundamentae Informatica
* right before Christmas 2009
!! JAAMAS
* review deadline 30.11.2009
Multiagent Systems
Algorithmic, Game-Theoretic, and Logical Foundations
Yoav Shoham
Stanford University
Kevin Leyton-Brown
University of British Columbia
Cambridge University Press, 2009
[[link|http://www.masfoundations.org/]]
----
Interestingly, stuff on single-agent things, such as BDI is missing. Also, from the ToC it seems that the work on strategic/coalition logics (temporal modal logics) is kind of missing, or underrepresented (not explicitly mentioned in the ToC). This is strange. It seems as if the book was providing a more US-centric view on MAS (as seen by AAMAS developments). Does this mean that perhaps these, rather European threads of work, are viewed as irrelevant by the authors? Or perhaps out of scope? Strange. Perhaps I should browse the book...
It might be interesting to analyze possible convergences of the MANET (mobile ad-hoc networks) project/workpackage within the TAF2 project and the scenario we proposed in the [[Scenario proposal draft]] and follow-ups. The feature in which that UGVs should repel civilians in some radius very much resembles covering the area with a signal. Moreover, in behaviours protecting the convoy it makes a lot of sense to keep the covered area around the convoy compact (ideally even convex) with the convoy near the centre of the covered area. So the final task of the UGV team could be ''continuously building and maintain a MANET around the convoy'' and thus secure its communication with other units in the operations theatre.
<<newTiddler>><<permaview>><<collapseAll>><<closeAll>><<slider chkSliderOptionsPanel OptionsPanel '»' 'Change options'>>
<<tabs txtMainTab "Contents" 'Hierarchy of tags and content' TabContents "Timeline" "Timeline" TabTimeline "All" "All tiddlers" TabAll "Tags" "All tags" TabTags "More" "More lists" TabMore>>
/***
This CSS by DaveBirss.
***/
/*{{{*/
.tabSelected {
background: #fff;
}
.tabUnselected {
background: #eee;
}
#sidebar {
color: #000;
background: transparent;
}
#sidebarOptions {
background: #fff;
}
#sidebarOptions input {
border: 1px solid #ccc;
}
#sidebarOptions input:hover, #sidebarOptions input:active, #sidebarOptions input:focus {
border: 1px solid #000;
}
#sidebarOptions .button {
color: #999;
}
#sidebarOptions .button:hover {
color: #000;
background: #fff;
border-color:white;
}
#sidebarOptions .button:active {
color: #000;
background: #fff;
}
#sidebarOptions .sliderPanel {
background: transparent;
}
#sidebarOptions .sliderPanel A {
color: #999;
}
#sidebarOptions .sliderPanel A:hover {
color: #000;
background: #fff;
}
#sidebarOptions .sliderPanel A:active {
color: #000;
background: #fff;
}
.sidebarSubHeading {
color: #000;
}
#sidebarTabs {`
background: #fff
}
#sidebarTabs .tabSelected {
color: #000;
background: #fff;
border-top: solid 1px #ccc;
border-left: solid 1px #ccc;
border-right: solid 1px #ccc;
border-bottom: none;
}
#sidebarTabs .tabUnselected {
color: #999;
background: #eee;
border-top: solid 1px #ccc;
border-left: solid 1px #ccc;
border-right: solid 1px #ccc;
border-bottom: none;
}
#sidebarTabs .tabContents {
background: #fff;
}
#sidebarTabs .txtMoreTab .tabSelected {
background: #fff;
}
#sidebarTabs .txtMoreTab .tabUnselected {
background: #eee;
}
#sidebarTabs .txtMoreTab .tabContents {
background: #fff;
}
#sidebarTabs .tabContents .tiddlyLink {
color: #999;
border:none;
}
#sidebarTabs .tabContents .tiddlyLink:hover {
background: #fff;
color: #000;
border:none;
}
#sidebarTabs .tabContents {
color: #000;
}
#sidebarTabs .button {
color: #666;
}
#sidebarTabs .tabContents .button:hover {
color: #000;
background: #fff;
}
#sidebar {color:#999;}
/*}}}*/
//Open Research Scrapbook// <html>
<span style="font-size: small;color: silver;">(<a href="http://peter.aronde.net/" style="font-size: small;color: silver;">Peter Novák</a>)</span></html>
http://mentalstate.aronde.net/
* rich 3D simulated environments - [[Croquet]]
* perhaps integrate [[Jazzyk]] with Smalltalk ([[Squeak]]) - this would allow easy and very high level application domain independent interaction model
* another option is to implement [[Jazzyk]] in [[Squeak]]
!!Notes:
- also [[Marie Curie Intra-European Fellowship]]
/***
''Inspired by [[TiddlyPom|http://www.warwick.ac.uk/~tuspam/tiddlypom.html]]''
|Name|SplashScreenPlugin|
|Created by|SaqImtiaz|
|Location|http://tw.lewcid.org/#SplashScreenPlugin|
|Version|0.21 |
|Requires|~TW2.08+|
!Description:
Provides a simple splash screen that is visible while the TW is loading.
!Installation
Copy the source text of this tiddler to your TW in a new tiddler, tag it with systemConfig and save and reload. The SplashScreen will now be installed and will be visible the next time you reload your TW.
!Customizing
Once the SplashScreen has been installed and you have reloaded your TW, the splash screen html will be present in the MarkupPreHead tiddler. You can edit it and customize to your needs.
!History
* 20-07-06 : version 0.21, modified to hide contentWrapper while SplashScreen is displayed.
* 26-06-06 : version 0.2, first release
!Code
***/
//{{{
window.old_lewcid_splash_restart=window.restart;
window.restart = function()
{ if (document.getElementById("SplashScreen"))
document.getElementById("SplashScreen").style.display = "none";
if (document.getElementById("contentWrapper"))
document.getElementById("contentWrapper").style.display = "block";
window.old_lewcid_splash_restart();
if (splashScreenInstall)
{if(config.options.chkAutoSave)
{saveChanges();}
displayMessage("TW SplashScreen has been installed, please save and refresh your TW.");
}
}
var oldText = store.getTiddlerText("MarkupPreHead");
if (oldText.indexOf("SplashScreen")==-1)
{var siteTitle = store.getTiddlerText("SiteTitle");
var splasher='\n\n<style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;"><b>'+siteTitle +'</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>';
if (! store.tiddlerExists("MarkupPreHead"))
{var myTiddler = store.createTiddler("MarkupPreHead");}
else
{var myTiddler = store.getTiddler("MarkupPreHead");}
myTiddler.set(myTiddler.title,oldText+splasher,config.options.txtUserName,null,null);
store.setDirty(true);
var splashScreenInstall = true;
}
//}}}
Smalltalk
Homepage: http://www.squeak.org/
SWiki: http://wiki.squeak.org/squeak/
http://www.dbai.tuwien.ac.at/staff/woltran/
[[SideBarWG]]
#topMen br {display:none;}
/***
!Top Menu Styles
***/
/*{{{*/
#topMenu br {display:none; }
#topMenu {
/* float:left; */
background: #000 ; color:silver;padding: 1em 1em;
}
#controls{
text-align: left;
font-style: italic;
color:silver;
padding-right: 0.7em;
padding-left: 0.75em;
padding-bottom: 0.5em;
width: 100%;
}
#controls .button {
padding-left:5px;
padding-right: 5px;
padding-top: 5px;
padding-bottom: 3px;
margin: 1px;Styles
background: white;
color: #ff8614;
border: solid 1px silver;
}
#controls .button:hover {
color: white;
background: #ff8614;
}
/*}}}*/
/***
!General
***/
/*{{{*/
body {
background: #444;Styles
margin: 0 auto;
}
#contentWrapper{
background: #fff;
border: 0;
margin: 0 1em;
padding:0;
}
/*}}}*/
/***
!Header rules
***/Styles
/*{{{*/
.titleLine{
margin: 34px 3em 0em 0em;
margin-left:1.7em;
margin-bottom: 28px;
margin-top: 10px;
padding: 0;
text-align: left;
color: #fff;
}
.rssbanner {
float: right;
margin-top: 20px;
}
.siteTitle {
font-size: 3em;
font-weight: bold;
color: #eee;
}
.siteSubtitle {
font-size: 1.5em;
display: block;
margin: .5em auto 1em;
color: #eee;
}
.gradient {margin: 0 auto;}
.header {
background: #fff;
margin: 0 0em;
padding:0 12px;
}
/*}}}*/
/***
!Display Area
***/
/*{{{*/
#bodywrapper {margin:0 12px; padding:0;background:#fff; height:1%}
#displayArea{
margin: 0em 0em 0em 19em;
text-align: left;
}
.tiddler {:
padding: 1em 1em 0em 0em;
}
h1,h2,h3,h4,h5 { color: #000; background: transparent; padding-bottom:2px; border-bottom: 1px dotted #666; }
/*.title {color:black; font-size:1.8em; border-bottom:1px solid #333; padding-bottom:0.3px;}*/
.title {color:black; font-size:3em; border-bottom:1px solid #333; padding-bottom:0.3px;}
.subtitle { font-size:90%; color:#ccc; padding-left:0.25em; margin-top:0.1em; }
.shadow .title {
color: #aaa;
}
.tagClear{
clear: none;
}
* html .viewer pre {
margin-left: 0em;
}
* html .editor textarea, * html .editor input {
width: 98%;
}
.tiddler {margin-bottom:1em; padding-bottom:0em;}
span .toolbar {float: right;}
.toolbar .button {color:#bbb; border:none;}
.toolbar .button:hover, .toolbar .highlight, .toolbar .marked, .toolbar a.button:active {background:transparent; color:#111; border:none; text-decoration:underline;}
#sidebar .highlight, #sidebar .marked {background:transparent;}
.references {
color: grey;
}
.tagging, .tagged {
border: 1px solid #eee;
background-color: #F7F7F7;
}
.selected .tagging, .selected .tagged {
background-color: #eee;
border: 1px solid #bbb;
}
.tagging .listTitle, .tagged .listTitle {
color: #bbb;
}
.selected .tagging .listTitle, .selected .tagged .listTitle {
color: #222;
}
.tagging .button:hover, .tagged .button:hover {
border: none; background:transparent; text-decoration:underline; color:#000;
}
.tagging .button, .tagged .button {
color:#aaa;
}
.selected .tagging .button, .selected .tagged .button {
color:#000;
}
.viewer blockquote {
border-left: 3px solid #000;
}
.viewer pre, .viewer code {
border: 1px dashed #ccc;
background: #eee;}
.viewer hr {
border: 0;
border-top: solid 1px #333;
margin: 0 8em;
color: #333;
}
.highlight, .marked {background:transparent; color:#111; border:none; text-decoration:underline;}
.viewer .highlight, .viewer .marked {text-decoration:none;}
#sidebarTabs .highlight, #sidebarTabs .marked {color:#000; text-decoration:none;}
#sidebarTabs .tabContents ul{
margin-left: .7em;
overflow: hidden;}
.tabSelected {
color: #000;
background: #fff;
border-top: solid 1px #ccc;
border-left: solid 1px #ccc;
border-right: solid 1px #ccc;
border-bottom: none;
}
.viewer .tabSelected:hover{color:#000;}
.viewer .tabSelected {font-weight:bold;}
.tabUnselected {
color: #999;
background: #eee;
border-top: solid 1px #ccc;
border-left: solid 1px #ccc;
border-right: solid 1px #ccc;
border-bottom: solid 1px #ccc;
padding-bottom:1px;
}
.tabContents {
background: #fff;
color: #000;
}
/*}}}*/
/***
!!!Tables
***/
/*{{{*/
.viewer table {
border: 1px solid #000;
}
.viewer th, thead td {
background: #000;
border: 1px solid #000;
color: #fff;
}
.viewer td, .viewer tr {
border: 1px solid #111; padding:4px;
}
/*}}}*/
/***
!!!Editor area
***/
/*{{{*/
.editor input, .editor textarea {
border: 1px solid #ccc;
}
.editor {padding-top:0.3em;}
.editor textarea:focus, .editor input:focus {
border: 1px solid #333;
}
/*}}}*/
/***
!Sidebar
***/
/*{{{*/
#sidebar{
position:relative;
float:left;
margin-bottom:1em;
/*display:inline;*/
width: 18em;
}
#sidebarOptions .sliderPanel {
background: #eee; border:1px solid #ccc;
}
/*}}}*/
/***
!Body Footer rules
***/
/*{{{*/
#contentFooter {
text-align: center;
clear: both;
color:#fff;
background: #000;
padding: 1em 2em;
font-weight:bold;
}
/*}}}*/
/***
!Link Styles
***/
/*{{{*/
a{
color: #000;
}
a:hover{
color: #FF6600;
background:#fff;
}
.button {
color: #000;
border: 1px solid #fff;
}
.button:hover {
color: #fff;
background: #ff8614;
border-color: #000;
}
.button:active {
color: #fff;
background: #ff8614;
border: 1px solid #000;
}
.tiddlyLink {border-bottom: 1px dotted #000;}
.tiddlyLink:hover {border-bottom: 1px dotted #FF6600;}
.titleLine a {border-bottom: 1px dotted #FF9900;}
.titleLine a:hover {border-bottom: 1px dotted #fff;}
.siteTitle a, .siteSubtitle a{
color: #fff;
}
.viewer .button {border: 1px solid #ff8614; font-weight:bold;}
/*.viewer .button:hover, .viewer .marked, .viewer .highlight{background:#ff8614; color:#fff; font-weight:bold; border: 1px solid #000;} */
.viewer .button:hover, .viewer .highlight {background:#ff8614; color:#fff; font-weight:bold; border: 1px solid #000;}
.viewer .marked {color:#ff8614;}
#topMenu .button, #topMenu .tiddlyLink {
margin-left:0.5em; margin-right:0.5em;
padding-left:3px; padding-right:3px;
color:white; font-weight:bold;
}
#topMenu .button:hover, #topMenu .tiddlyLink:hover { background:#000; color:#FF8814}
#topMenu a{border:none;}
/*}}}*/
/***
!Message Area /%=================================================%/
***/
/*{{{*/
#messageArea {
border: 4px dotted #ff8614;
background: #000;
color: #fff;
font-size:90%;
}
#messageArea .button {
padding: 0.2em;
color: #000;
background: #fff;
text-decoration:none;
font-weight:bold;
border:1px solid #000;
}
#messageArea a {color:#fff;}
#messageArea a:hover {color:#ff8614; background:transparent;}
#messageArea .button:hover {background: #FF8614; color:#fff; border:1px solid #fff; }
/*}}}*/
/***
!Popup /%=================================================%/
***/
/*{{{*/
.popup {
background: #ff8814;
border: 1px solid #333;
}
.popup hr {
color: #333;
background: #333;
border-bottom: 1px;
}
.popup li.disabled {
color: #333;
}
.popup li a, .popup li a:visited {
color: #eee;
border: none;
}
.popup li a:hover {
background: #ff8614;
color: #fff;
border: none;
text-decoration:underline;
}
.searchBar {float:right; font-size:1em; padding: 0.75em;}
.searchBar .button {display: block; border:none; text-color:#ccc;}
.searchBar .button:hover{border:none; color:#eee;}
.searchBar a {color: white;}
.searchBar input{
border: 1px inset #000; background:#EFDFD1; width:10em; margin:0;
}
.searchBar input:focus {
border: 1px inset #000; background:#fff;
}
*html .titleLine {margin-right:1.3em;}
*html .searchBar .button {margin-left:1.7em;}
.HideSideBarButton {float:right;}
/*}}}*/
.blog h2, .blog h3, .blog h4{
margin:0;
padding:0;
border-bottom:none;
}
.blog {margin-left:1.5em;}
.blog .excerpt {
margin:0;
margin-top:0.3em;
padding: 0;
margin-left:1em;
padding-left:1em;
font-size:90%;
border-left:1px solid #ddd;
}
#tiddlerWhatsNew h1, #tiddlerWhatsNew h2 {border-bottom:none;}
div[tags~="RecentUpdates"], div[tags~="lewcidExtension"] {margin-bottom: 2em;}
#hoverMenu .button, #hoverMenu .tiddlyLink {border:none; font-weight:bold; background:#f37211; color:#fff; padding:0 5px; float:right; margin-bottom:4px;}
#hoverMenu .button:hover, #hoverMenu .tiddlyLink:hover {font-weight:bold; border:none; color:#f37211; background:#000; padding:0 5px; float:right; margin-bottom:4px;}
#topMenu .fontResizer {float:right;}
#topMenu .fontResizer .button{border:1px solid #000;}
#topMenu .fontResizer .button:hover {border:1px solid #f37211; color:#fff;}
#sidebarTabs .txtMainTab .tiddlyLinkExisting {
font-weight: normal;
font-style: normal;
}
#sidebarTabs .txtMoreTab .tiddlyLinkExisting {
font-weight: bold;
font-style: normal;
}
.viewer {
line-height: 125%;
font-family: serif;
font-size: 12pt;
}
.block a{display:block;}
/***
The new SystemConfig feature allows arbitrary JavaScript code to be executed at startup from any note that is tagged with 'systemConfig', one of the new SpecialTags.
***/
/*{{{*/
config.messages.messageClose.text = "\xD7";
config.messages.messageClose.tooltip = "Close this message";
config.views.wikified.defaultText = "";
config.views.wikified.tag.labelTags = "";
config.views.wikified.tag.openTag = "";
config.views.wikified.tag.tooltip = "Show other notes tagged with '%0'";
config.views.editor.tagPrompt = "separated by spaces, using [[double square brackets]] if necessary";
config.commands.closeTiddler.tooltip = "Close this note";
config.commands.closeOthers.tooltip = "Close all others";
config.commands.jump.tooltip = "Jump to another open note";
config.commands.editTiddler.readOnlyText = " ";
config.commands.editTiddler.tooltip = "Edit this note (double click)";
config.commands.references.tooltip = "Notes that link to this one";
config.commands.saveTiddler.readOnlyText = ".";
config.commands.saveTiddler.tooltip = "Save changes";
config.commands.cancelTiddler.tooltip = "Cancel changes";
config.commands.deleteTiddler.tooltip = "Delete this note";
config.macros.timeline.dateFormat = "MMM DD, YYYY";
config.macros.search.prompt = "Search this site";
config.macros.search.successMsg = "%0 notes found matching %1";
config.macros.search.failureMsg = "No notes found matching %0";
config.macros.newTiddler.prompt = "Create a new note";
config.macros.newTiddler.label = "note";
config.macros.newJournal.prompt = "Create a new journal";
config.macros.newJournal.label = "journal";
config.macros.saveChanges.label = "Save";
config.macros.saveChanges.prompt = "Save this whole wiki as an html file";
config.macros.newJournal.prompt = "Create a new note from the current date and time";
config.macros.permaview.prompt = "Make a URL showing all currently displayed notes";
config.numRssItems = 20
/*}}}*/
!! Overall impression
Obviously this is a project which was done towards a concrete goal. It is reflected by the fact that it seems to lack a solid scientific result in terms of a (set of?) falsifiable statements. There are some, but their validity is very limited. My impression is that
# while the overall aim of the project was set up rather clearly, the direction on the lower level issues seems to be rather arbitrary (cf., choice of constraints, such as fixed altitude of UAVs, etc. - mainly a lack of solid evaluation suite, kind of regression tests)
# the project is technologically advanced and very well done (first impression), but I feel a lack of good //significance// for the research field here. The main reasons:
## evaluation is done in quite very limited ways. I.e.,
*** it seems that the project starts from some fairly artificial (unrealistic) assumptions and somehow it seems to be rather "dumbed-down" to become technologically more feasible
*** few scenarios (2?) without a great variance,
*** lack of real-world data, or something similar. What about large cities with tall buildings, mountainous regions, deserts with few long straight roads, coastal regions, etc.
*** I suspect here that serious problems were in a way avoided in the favour of what could be technically implemented in an easier manner
# one of the main problems is that this is obviously a centrally solved problem and not necessarily a MAS task. For that you IMHO need (cf. [[Coordination in MAS - necessary conditions]])
> <<tiddler [[Coordination in MAS - necessary conditions]]>>
## it seems that most of the problems which popped up was already tackled somehow. In that case, //what is the real contribution of this project to the state of the art//? (in the theoretical sense)
* the final report is written in a fairly rough manner. I.e.,
## language is not perfect (minor issue)
## few citations are used. The consequence is that sometimes the report reads as if the project was done in an //ad-hoc manner// and the related work/citations were only added to look better.
## the formal framework description could be better. Often there are unexplained notions, undefined factors/notation, etc.
## although it very useful and a good attempt, it seems to assume some artificial starting assumptions (e.g., perfect sensors, targets are not avoiding the UAVs, etc.)
## most importantly, the report makes several fairly strong statements ("this is better than that", or "that is impossible/inefficient", etc.) without a good support/evidence. The evaluation is also rather week w.r.t. such strong statements
# a lot of attention is dedicated to occlusion handling. But in the mentioned test scenarios it doesn't seem to be of that of a problem. The authors are even explicit about it at certain point (comparison of TSP-based vs. naive zig-zag surveillance algorithms) - increasing the UAV altitude smooths out the problems with occlusion.
!! Ideas & suggestions
* IMHO, this project should seek how to get closer to the [[necessary conditions on MAS coordination|Coordination in MAS - necessary conditions]]
* in this direction, it seems to me that the problem of area //policing// would be rather interesting in this context. I.e., not only surveillance/tracking, but also active participation on the ground actions (defense, combat?). This would actually require heterogeneous teams and perhaps even assume team composition changes on the fly (planes shot down, or replaced, or new incoming support), or even communication failures.
* for evaluation purposes, there is a need for more realistic data, i.e., maps. What about getting useful landscapes from Google Earth? They have even cities with 3D models there. Another idea would be to generate own, but rather heterogeneneous landscapes/cities. What would be especially interesting would be mountainous regions, or perhaps coastal areas, etc.
!! Assorted comments
* they seem to assume //perfect sensors//, the whole situation would be way different with failing/unreliable/noisy sensor equipment, or by an explicit modelling of the sensor resolution
* in scenarios with noisy sensors it would be possible to calculate the //efficacy/performance// of the current surveillance operation w.r.t., the later observed corrections (real coordinates of targets vs. the projected) and accordingly - then a change of altitude of team members can have an influence on the measure.
** high error/loosing the targets too often -> fly higher to see more
** too much noise -> fly lower to see better
*** in higher altitudes the UAVs do not have problems with occlusions, but can harder recognize signatures of the ground targets(?)
* how realistic is to assume scenarios, such as the example map? How realistic is to deploy ~10 UAVs to a village of the size $1.5 \times 1.5$km?
* evaluation on a single map is not really enough. This needs more realistic data and/or a large amount of synthetic test-cases. Otherwise the significance goes down the drain. See also //Ideas & suggestions// above.
* also a danger to the aircrafts themselves could be taken into account. Zig-zag algorithm might be nice, but it's very easily predictable - this makes it vulnerable to attacks from the opponents on the ground, as well as it simplifies surveillance avoidance.
* what kind of //rule engine/technology// is used to control the ground entities?
* communication failure could be modelled. However this goes against the spirit of the project (information collection + immediate transmition to the command&control center)
* why are the waypoint headings chosen as they are? you could choose them in a "tangential" manner (to the smooth arc from $w_{n-1} \ldots w_n \ldots w_{n+1}$ crossing the $w_n$)
* zig-zag algorithm: the turns probably cost a lot in terms of //the covered distance, speed(?)//. The TSP based algorithms certainly do better here, thoughthe zig-zag idea could be imporved further. Besides the already mentioned headings adaptation, there is an observation that the areas covered at turns tend to overlap quite a lot. This //should// be minimized. For example by "bending" the rows... This is an issue when considering large planes and dense rows.
* a proposal for an alternative //success measure// came to my mind: //overall time of area coverage//, i.e., how much time it takes for an UAV to "make a round" This loosely has something to do with the information age, yet optimization for this explicitly would go for 1) fast and fewer plane turns, 2) minimal overlaps of sectors seen during a single round.
* does a speed of flight have something to do with the amount of noise plane sensors receive?
* again, not too much attention seems to be paid to the //ground profile// in the project. Mountainous regions, or dense urban areas with skyscrapers make a difference...
* Fig. 5.17 and elsewhere: what significance does such a comparison have? We are speaking about a single map/test-case... (points to the weakness in validation)
!! Proposals/ideas about new directions
It seems to me that the project has quite a potential to be extended towards studies of MAS coordination. To this end, it is vital to incorporate (at least some of) the core coordination principles ([[Coordination in MAS - necessary conditions]]). The scenarios which came to my mind could include:
!!! 1. Area policing
* I feel that the project scenario lacks enough //autonomy// of the agents within the MAS. In order to enable that, we should add ability to //control/act/decision making// to the agents
* to this end, there are several possible avenues. E.g.,
## allow the UAVs to act (shoot?)
## allow the UAVs to autonomously re-structure the MAS, e.g., in the case of communication failure, loss of a plane, uncertain information (noisy sensors), etc.
## allow interference with other entities in the simulation, e.g., shooting down a plane, call for support, getting it and autonomously incorporating the support (new UAVs) into the running task
* some of the above comments are of course unfeasible w.r.t., the project specification/requirements by the other party (sponsor, client, ...). Therefore I would suggest a scenario of ''//autonomous policing//'' a non-trivial area in an uneasy terrain, e.g., a large area in mountains, or a city, etc.
!!! 2. Intelligent Ground Units
* this is rather obvious and quite creative direction. Simply add whatever intelligence to the ground units, most probably to the enemy targets.
* an example might be joint team goal to defend an urban area, but at the same time avoid, or even counter-attack the UAVs and the "good" ground units (army?)
''TODO: //Expand on the future directions//''
!! Notes
* JVO & TKO are off the project from 28.06.2010 on
* the administrative leadership of teh project is handed over to PNO
* the project ends in September 2010, where we should put together the final report
* the next intermediary report is due at the end of June 2010, i.e., next week
!! Next actions & todo's on the TAF II project
# TAF II intermediary report
** LCH, JVO, TKO: write partial summaries, deadline is 25.06.2010
** PNO: wrap up and complete the report
# Finish the //scenario D//
** DPA is available for 2 weeks in the summer for the project
** content:
*** finish the greedy algorithm ''(TKO)''
*** finish the resource allocation algorithm ''(JVO)''
*** potential fields based algorithm ''(??? - PNO)''
*** clustering based algorithm ''(??? - PNO)''
*** improve the greedy algorithm ''(??? - TKO)''
*** implement some kind of coordination method for the aircrafts ''(!!! PNO !!!)''
# GT/Adver@TAF II ''(VLY+BBO+PNO)''
** we would like to have a bonus content involving some game theory in the TAF II project, i.e., the scenario should: i) be interesting by itself, as well as ii) serve as a preparation platform for the TAS project later this year
** can we re-use some software/methods/etc. from BBO & VLY's work in the past? E.g., DeepA project, or the AgentC project?
# MASPlan@TAF II ''(PNO)''
** we would like to put into the final report some theoretical text/summary about the multi-agent planning problem. This should serve as a preparation for the TAS project, but since the two are considered a bundle, we can mention it in this project as well
# JazzykJVM ''(??? - PNO)''
** what to do with the interpreter? Can we use it for implementation of the people there?
** BTW, this will have some interactions with the //UrbanSim// project as well.
I see quite some engineering efforts and applications in there. However only a little scientific issues tackled (if any). I'd like to see here a bit more focus on ''coordination''.
!!!Coordination:
Coordination, in the AI sense, makes sense only in situations where we are tackling a problem including a strong obstacle disallowing centralized solutions. Such features are e.g., //information distribution// and //heterogeneity// of agents. Without information distribution (incomplete information), we are solving a centralized optimization tasks and heterogeneity is an amplifier. If peers are only copies of myself, I can perfectly predict how they are about to react, hence I am able to calculate the whole solution from the initial state myself - as every team member as well. No communication is needed. And without a kind of communication, there's hardly any coordination...
!! Available notes
<<matchTags "#%0 (%2)<br>^^%5^^" "\n" sort:-modified [[TAF2 AND NOT project]]>>
!!! Meeting minutes: ''brainstorming on [[Tactical AgentFly 2]]''
Three axes of devel:
# helicopter
# seeking the coordination theme in the scenario
# ground characters control - //I have a strong interest on this one//
''Todo'':
<<tiddler [[TAF2-20091016 - todo]]>>
''Notes:''
I need to find a way how get the coordination stuff in here... Ground control seems to be promissing, but I need to go for a more general issues with applications also to the aerial stuff already present.
# meet with TK - intro to code of TAF1, AgentFly, A-Globe, etc.
# read the Final report on TAF1 project
## --get the doc from MJ--
# longer run: find a slot - personal position for future work on TAF2 project
<<matchTags "#%0 (lastmod: %2)<br>^^%5^^" "\n" sort:-created [[(TAF2 OR TAS) AND NOT project]]>>
!! Introduction
Let $\mathcal{A}_\mathit{ag} {}={} \{(a,\phi)\}$, where $a$'s are labels and $\phi$'s are propositional formulae, be a set of specifications of actions in a system. Actions can be seen as STRIPS-like specifications which and can be executed anytime, therefore they do not feature preconditions.
Now let's consider a Kripke model $M$ describing a system involving a single agent and an environment. Let also $\mathcal{A}$ denote the set of all actions and events which can happen in $M$. We can also write that $\mathcal{A}=\mathcal{A}_\mathit{ag} \cup \mathcal{A}_\mathit{env}$. $\mathcal{A}_\mathit{ag}$ denote agent's actions and $\mathcal{A}_\mathit{env}$ denote events which can occur in the environment.
Let us also consider the DCTL* language for speaking about properties of the system.
!! Environment dynamics
One of interesting questions which can be formulated is the following@@
> //How can we characterize/quantify environment dynamics w.r.t. the given agent system?//
@@
In the following I sketch an interesting answer to this question.
Let $(a,\phi)\in {}\mathcal{A}_\mathit{ag}{}$ Let $\omega$ be //the minimal number of iterations of an action $a$ the agent must execute in order to //ensure// that $\phi$ is satisfied in the final possible world//. Formally,
\[ \omega {}={} \min \{ n\in{}\mathbb{N} | \forall (a,\phi)\in{}\mathcal{A}_\mathit{ag}, \sigma\in{} M : M,\sigma {} \models{} [a^n]\lozenge\phi\} \]
If such a minimal $n\in{}\mathbb{N}$ does not exist, we denote $\omega{}={}\infty$.
Now, if we perceive the system $M$ as a "game" between the environment and the agent where the agent tries to establish some proposition while the environment is trying to do exactly the opposite, the number $\omega$ is negatively proportional to the rate of the environment dynamics. We have the following observations:
# if $\omega{}={}0$, the system seems to be trivial in the sense that in all states all the effects of all actions from $\mathcal{A}_\mathit{ag}$ hold.
# if $\omega{}={}1$, the system is deterministic. I.e., the environment is //passive// and agent's actions always succeed. In fact, in this system we can always use //Dynamic Logic// for reasoning about actions, i.e., $[a]{} \phi{} $. In the language of DCTL*, that amounts to $[a]\bigcirc{}\phi$;
# now the higher $\omega$, the more dynamic the environment is. We can actually use $\omega$'s to compare the level of dynamics of various environments.
# if $\omega{}={}\infty$, the system is again rather trivial. In fact, it is hopeless because there is no chance the agent can ensure succeed in such a system. The environment is //extremely dynamic//.
An interesting observation, or rather an intuition is, that the higher the dynamics of the environment, the shorter planning horizon the agent can use. For longer horizons the design becomes ineffective as it can be shown that for longer planning horizons (intentions/commitments), these will always fail.
Actually, we can try to capture the environment dynamics in a dual/complementary way to $\omega$. Let's define the number $\omega^\prime$ as the longest interval on which the agent can ensure validity of $\phi$ for some $a$, s.t. $(a,\phi){}\in{}\mathcal{A}_\mathit{ag}$. Formally,
\[ \omega^\prime{}={}\{ n\in{}\mathbb{N} | \forall (a,\phi)\in{}\mathcal{A}_\mathit{ag},\sigma\in{}M : M,\sigma{}\models{}\square\lozenge{} [a^n]\square{}\phi \} \]
Now this is a rather strange notion, as it is of little use (from a agent-program-specification point of view) when we are able to say something like this about agent's actions. But if we modify it a bit to
\[ \omega^\prime{}={}\{ n\in{}\mathbb{N} | \forall (a,\phi)\in{}\mathcal{A}_\mathit{env},\sigma\in{}M : M,\sigma{}\models{}\square\lozenge{} [a^n]\square{}\phi \} \]
suddenly we arrive to some interesting observations.
If $\omega$ is defined (finite), there must be an action $(a_1,\phi_1){}\in{} \mathcal{A}_\mathit{ag}{} $ for which the $\omega$ is the minimal number of steps to ensure its desired effects. Now necessarily, there must exist a complementary environment event $(a_2,\phi_2){}\in{}\mathcal{A}_\mathit{env}{} $ such that $\phi_1 \wedge \phi_2 \models{} \bot$. Hence, \[ \omega=\omega^\prime \] (plus minus 1?)
Actually, in an environment where the agent does not know the dynamics apriori, it does not really make sense to specify agent's goals as pure maintenance conditions of the pattern $\square{} \phi$. Such goals can never be satisfied. Rather, these should be reformulated as //repair// goals of the pattern $\square {}(\neg\phi {}\rightarrow{} [a^*]\lozenge\phi)$.
''Note:'' In practical settings, the environment dynamics could be estimated by sampling. I.e., execution of arbitrary iterations of some "harmless" actions.
!! Agent specification
Actually the main question I have is @@
> Is there a (fragment of a) logic which captures exactly the specifications of programs which can be constructed as BSM's over a given set of primitive annotated actions?
@@
In other words @@
> What is the set of temporal formulae which can be satisfied as //temporally extended goals// by a BSM constructed from a given set of annotated primitive actions?
@@
Obviously it is not the full LTL, but rather some kind of weird (incomplete) fragment of it. Some of the hints:
* the agent can only achieve positive effects. I.e., unless it has an action which can achieve $\neg\phi$, the agent can by its capabilities only ensure $\phi$. So not all LTL formulae can be constructed.
** given a complex goal, we could construct its //[[negation normal form|LTL normal form]]// and evaluate the propositional formulae behind temporal modalities. If these involve propositions which do not correspond to effects of some specified action, or include a negation which does not explicitly follow from the agent's actions's effects, we can safely say that the agent cannot by its own capabilities bring about that goal.
* the fragment sought after certainly includes all the compositions of the formulae $[a^*]\phi$ (for each action) which correspond to BSM compositions (we can also add a parallel composition?).
* I suspect however that there are more of those... I would like to find a complete fragment/logic...
*<<slider chkSlidertracksF tracksFolder 'tracks (Trk) »' 'research tracks'>>
*<<slider chkSliderprojectsF projectsFolder 'projects (Prj) »' 'my projects'>>
*<<slider chkSliderorganizerF organizerFolder 'organizer »' 'schedules, todos, etc.'>>
*<<slider chkSlidertopicsF topicsFolder 'topics »' 'topics'>>
*<<slider chkSlidermetaF readingFolder 'reading »' 'reviews, read papers and papers to read'>>
*<<slider chkSliderpeopleF peopleFolder 'people »' 'bookmarks to researchers'>>
<hr/>
*<<slider chkSliderfoldersF foldersFolder 'folders »' 'all the site folders'>>
*<<slider chkSlidernotagF notagFolder 'notag »' 'assorted notes'>>
*<<slider chkSlidermetaF metaFolder 'meta »' 'varia/operation of this site'>>
<hr/>
<<tiddler Cloud>>
/***
|''Name:''|TableSortingPlugin|
|''Description:''|Dynamically sort tables by clicking on column headers|
|''Author:''|Saq Imtiaz ( lewcid@gmail.com )|
|''Source:''|http://tw.lewcid.org/#TableSortingPlugin|
|''Code Repository:''|http://tw.lewcid.org/svn/plugins|
|''Version:''|2.02|
|''Date:''|25-01-2008|
|''License:''|[[Creative Commons Attribution-ShareAlike 3.0 License|http://creativecommons.org/licenses/by-sa/3.0/]]|
|''~CoreVersion:''|2.2.3|
!!Usage:
* Make sure your table has a header row
** {{{|Name|Phone Number|Address|h}}}<br> Note the /h/ that denote a header row
* Give the table a class of 'sortable'
** {{{
|sortable|k
|Name|Phone Number|Address|h
}}}<br>Note the /k/ that denotes a class name being assigned to the table.
* To disallow sorting by a column, place {{{<<nosort>>}}} in it's header
* To automatically sort a table by a column, place {{{<<autosort>>}}} in the header for that column
** Or to sort automatically but in reverse order, use {{{<<autosort reverse>>}}}
!!Example:
|sortable|k
|Name |Salary |Extension |Performance |File Size |Start date |h
|ZBloggs, Fred |$12000.00 |1353 |+1.2 |74.2Kb |Aug 19, 2003 21:34:00 |
|ABloggs, Fred |$12000.00 |1353 |1.2 |3350b |09/18/2003 |
|CBloggs, Fred |$12000 |1353 |1.200 |55.2Kb |August 18, 2003 |
|DBloggs, Fred |$12000.00 |1353 |1.2 |2100b |07/18/2003 |
|Bloggs, Fred |$12000.00 |1353 |01.20 |6.156Mb |08/17/2003 05:43 |
|Turvey, Kevin |$191200.00 |2342 |-33 |1b |02/05/1979 |
|Mbogo, Arnold |$32010.12 |2755 |-21.673 |1.2Gb |09/08/1998 |
|Shakespeare, Bill |£122000.00|3211 |6 |33.22Gb |12/11/1961 |
|Shakespeare, Hamlet |£9000 |9005 |-8 |3Gb |01/01/2002 |
|Fitz, Marvin |€3300.30 |5554 |+5 |4Kb |05/22/1995 |
***/
// /%
//!BEGIN-PLUGIN-CODE
config.tableSorting = {
darrow: "\u2193",
uarrow: "\u2191",
getText : function (o) {
var p = o.cells[SORT_INDEX];
return p.innerText || p.textContent || '';
},
sortTable : function (o,rev) {
SORT_INDEX = o.getAttribute("index");
var c = config.tableSorting;
var T = findRelated(o.parentNode,"TABLE");
if(T.tBodies[0].rows.length<=1)
return;
var itm = "";
var i = 0;
while (itm == "" && i < T.tBodies[0].rows.length) {
itm = c.getText(T.tBodies[0].rows[i]).trim();
i++;
}
if (itm == "")
return;
var r = [];
var S = o.getElementsByTagName("span")[0];
c.fn = c.sortAlpha;
if(!isNaN(Date.parse(itm)))
c.fn = c.sortDate;
else if(itm.match(/^[$|£|€|\+|\-]{0,1}\d*\.{0,1}\d+$/))
c.fn = c.sortNumber;
else if(itm.match(/^\d*\.{0,1}\d+[K|M|G]{0,1}b$/))
c.fn = c.sortFile;
for(i=0; i<T.tBodies[0].rows.length; i++) {
r[i]=T.tBodies[0].rows[i];
}
r.sort(c.reSort);
if(S.firstChild.nodeValue==c.darrow || rev) {
r.reverse();
S.firstChild.nodeValue=c.uarrow;
}
else
S.firstChild.nodeValue=c.darrow;
var thead = T.getElementsByTagName('thead')[0];
var headers = thead.rows[thead.rows.length-1].cells;
for(var k=0; k<headers.length; k++) {
if(!hasClass(headers[k],"nosort"))
addClass(headers[k].getElementsByTagName("span")[0],"hidden");
}
removeClass(S,"hidden");
for(i=0; i<r.length; i++) {
T.tBodies[0].appendChild(r[i]);
c.stripe(r[i],i);
for(var j=0; j<r[i].cells.length;j++){
removeClass(r[i].cells[j],"sortedCol");
}
addClass(r[i].cells[SORT_INDEX],"sortedCol");
}
},
stripe : function (e,i){
var cl = ["oddRow","evenRow"];
i&1? cl.reverse() : cl;
removeClass(e,cl[1]);
addClass(e,cl[0]);
},
sortNumber : function(v) {
var x = parseFloat(this.getText(v).replace(/[^0-9.-]/g,''));
return isNaN(x)? 0: x;
},
sortDate : function(v) {
return Date.parse(this.getText(v));
},
sortAlpha : function(v) {
return this.getText(v).toLowerCase();
},
sortFile : function(v) {
var j, q = config.messages.sizeTemplates, s = this.getText(v);
for (var i=0; i<q.length; i++) {
if ((j = s.toLowerCase().indexOf(q[i].template.replace("%0\u00a0","").toLowerCase())) != -1)
return q[i].unit * s.substr(0,j);
}
return parseFloat(s);
},
reSort : function(a,b){
var c = config.tableSorting;
var aa = c.fn(a);
var bb = c.fn(b);
return ((aa==bb)? 0 : ((aa<bb)? -1:1));
}
};
Story.prototype.tSort_refreshTiddler = Story.prototype.refreshTiddler;
Story.prototype.refreshTiddler = function(title,template,force,customFields,defaultText){
var elem = this.tSort_refreshTiddler.apply(this,arguments);
if(elem){
var tables = elem.getElementsByTagName("TABLE");
var c = config.tableSorting;
for(var i=0; i<tables.length; i++){
if(hasClass(tables[i],"sortable")){
var x = null, rev, table = tables[i], thead = table.getElementsByTagName('thead')[0], headers = thead.rows[thead.rows.length-1].cells;
for (var j=0; j<headers.length; j++){
var h = headers[j];
if (hasClass(h,"nosort"))
continue;
h.setAttribute("index",j);
h.onclick = function(){c.sortTable(this); return false;};
h.ondblclick = stopEvent;
if(h.getElementsByTagName("span").length == 0)
createTiddlyElement(h,"span",null,"hidden",c.uarrow);
if(!x && hasClass(h,"autosort")) {
x = j;
rev = hasClass(h,"reverse");
}
}
if(x)
c.sortTable(headers[x],rev);
}
}
}
return elem;
};
setStylesheet("table.sortable span.hidden {visibility:hidden;}\n"+
"table.sortable thead {cursor:pointer;}\n"+
"table.sortable .nosort {cursor:default;}\n"+
"table.sortable td.sortedCol {background:#ffc;}","TableSortingPluginStyles");
function stopEvent(e){
var ev = e? e : window.event;
ev.cancelBubble = true;
if (ev.stopPropagation) ev.stopPropagation();
return false;
}
config.macros.nosort={
handler : function(place){
addClass(place,"nosort");
}
};
config.macros.autosort={
handler : function(place,m,p,w,pS){
addClass(place,"autosort"+" "+pS);
}
};
//!END-PLUGIN-CODE
// %/
/***
|Name|TagCloudPlugin|
|Source|http://www.TiddlyTools.com/#TagCloudPlugin|
|Version|1.6.0|
|Author|Eric Shulman|
|Original Author|Clint Checketts|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|present a 'cloud' of tags (or links) using proportional font display|
!Usage
<<<
{{{
<<cloud type action:... limit:... tag tag tag ...>>
<<cloud type action:... limit:... +TiddlerName>>
<<cloud type action:... limit:... =tagvalue>>
}}}
where:
* //type// is a keyword, one of:
** ''tags'' (default) - displays a cloud of tags, based on frequency of use
** ''links'' - displays a cloud of tiddlers, based on number of links //from// each tiddler
** ''references'' - displays a cloud of tiddlers, based on number of links //to// each tiddler
* ''action:popup'' (default) - clicking a cloud item shows a popup with links to related tiddlers<br>//or//<br> ''action:goto'' - clicking a cloud item immediately opens the tiddler corresponding to that item
* ''limit:N'' (optional) - restricts the cloud display to only show the N most popular tags/links
* ''tag tag tag...'' (or ''title title title'' if ''links''/''references'' is used)<br>shows all tags/links in the document //except// for those listed as macro parameters
* ''+TiddlerName''<br>shows tags/links read from a space-separated, bracketed list stored in a separate tiddler.
* ''=tagvalue'' (//only if type=''tags''//)<br>shows only tags that are themselves tagged with the indicated tag value (i.e., ~TagglyTagging usage)
//note: for backward-compatibility, you can also use the macro {{{<<tagCloud ...>>}}} in place of {{{<<cloud ...>>}}}//
<<<
!Examples
<<<
//all tags excluding<<tag systemConfig>>, <<tag excludeMissing>> and <<tag script>>//
{{{<<cloud systemConfig excludeMissing script>>}}}
{{groupbox{<<cloud systemConfig excludeMissing script>>}}}
//top 10 tags excluding<<tag systemConfig>>, <<tag excludeMissing>> and <<tag script>>//
{{{<<cloud limit:10 systemConfig excludeMissing script>>}}}
{{groupbox{<<cloud limit:10 systemConfig excludeMissing script>>}}}
//tags listed in// [[FavoriteTags]]
{{{<<cloud +FavoriteTags>>}}}
{{groupbox{<<cloud +FavoriteTags>>}}}
//links to tiddlers tagged with 'package'//
{{{<<cloud action:goto =package>>}}}
{{groupbox{<<cloud action:goto =package>>}}}
//top 20 most referenced tiddlers//
{{{<<cloud references limit:20>>}}}
{{groupbox{<<cloud references limit:20>>}}}
//top 20 tiddlers that contain the most links//
{{{<<cloud links limit:20>>}}}
{{groupbox{<<cloud links limit:20>>}}}
<<<
!Revisions
<<<
2009.02.26 [1.6.0] added {{{action:...}}} parameter to apply popup vs. goto action when clicking cloud items
2009.02.05 [1.5.0] added ability to show links or back-links (references) instead of tags and renamed macro to {{{<<cloud>>}}} to reflect more generalized usage.
2008.12.16 [1.4.2] corrected group calculation to prevent 'group=0' error
2008.12.16 [1.4.1] revised tag filtering so excluded tags don't affect calculations
2008.12.15 [1.4.0] added {{{limit:...}}} parameter to restrict the number of tags displayed to the top N most popular
2008.11.15 [1.3.0] added {{{+TiddlerName}}} parameter to include only tags that are listed in the indicated tiddler
2008.09.05 [1.2.0] added '=tagname' parameter to include only tags that are themselves tagged with the specified value (i.e., ~TagglyTagging usage)
2008.07.03 [1.1.0] added 'segments' property to macro object. Extensive code cleanup
<<<
!Code
***/
//{{{
version.extensions.TagCloudPlugin= {major: 1, minor: 6 , revision: 0, date: new Date(2009,2,26)};
//Originally created by Clint Checketts, contributions by Jonny Leroy and Eric Shulman
//Currently maintained and enhanced by Eric Shulman
//}}}
//{{{
config.macros.cloud = {
tagstip: "%1 tiddlers tagged with '%0'",
refslabel: " (%0 references)",
refstip: "%1 tiddlers have links to '%0'",
linkslabel: " (%0 links)",
linkstip: "'%0' has links to %1 other tiddlers",
groups: 9,
init: function() {
config.macros.tagCloud=config.macros.cloud; // for backward-compatibility
config.shadowTiddlers.TagCloud='<<cloud>>';
config.shadowTiddlers.StyleSheetTagCloud=
'/*{{{*/\n'
+'.tagCloud span {line-height: 3.5em; margin:3px;}\n'
+'.tagCloud1{font-size: 80%;}\n'
+'.tagCloud2{font-size: 100%;}\n'
+'.tagCloud3{font-size: 120%;}\n'
+'.tagCloud4{font-size: 140%;}\n'
+'.tagCloud5{font-size: 160%;}\n'
+'.tagCloud6{font-size: 180%;}\n'
+'.tagCloud7{font-size: 200%;}\n'
+'.tagCloud8{font-size: 220%;}\n'
+'.tagCloud9{font-size: 240%;}\n'
+'/*}}}*/\n';
setStylesheet(store.getTiddlerText('StyleSheetTagCloud'),'tagCloudsStyles');
},
getLinks: function(tiddler) { // get list of links to existing tiddlers and shadows
if (!tiddler.linksUpdated) tiddler.changed();
var list=[]; for (var i=0; i<tiddler.links.length; i++) {
var title=tiddler.links[i];
if (store.isShadowTiddler(title)||store.tiddlerExists(title))
list.push(title);
}
return list;
},
handler: function(place,macroName,params) {
// unpack params
var inc=[]; var ex=[]; var limit=0; var action='popup';
var links=(params[0]&¶ms[0].toLowerCase()=='links'); if (links) params.shift();
var refs=(params[0]&¶ms[0].toLowerCase()=='references'); if (refs) params.shift();
if (params[0]&¶ms[0].substr(0,7).toLowerCase()=='action:')
action=params.shift().substr(7).toLowerCase();
if (params[0]&¶ms[0].substr(0,6).toLowerCase()=='limit:')
limit=parseInt(params.shift().substr(6));
if (params.length) {
if (params[0].substr(0,1)=='+') { // get tag list from tiddler
var inc=store.getTiddlerText(params[0].substr(1),'').readBracketedList();
} else if (params[0].substr(0,1)=='=') { // get tag list using tagged tags
var tagged=store.getTaggedTiddlers(params[0].substr(1));
for (var t=0; t<tagged.length; t++) inc.push(tagged[t].title);
} else ex=params; // exclude params
}
// get all items, include/exclude specific items
var items=[];
var list=(links||refs)?store.getTiddlers('title','excludeLists'):store.getTags();
for (var t=0; t<list.length; t++) {
var title=(links||refs)?list[t].title:list[t][0];
if (links) var count=this.getLinks(list[t]).length;
else if (refs) var count=store.getReferringTiddlers(title).length;
else var count=list[t][1];
if ((!inc.length||inc.contains(title))&&(!ex.length||!ex.contains(title)))
items.push({ title:title, count:count });
}
if(!items.length) return;
// sort by decending count, limit results (optional)
items=items.sort(function(a,b){return(a.count==b.count)?0:(a.count>b.count?-1:1);});
while (limit && items.length>limit) items.pop();
// find min/max and group size
var most=items[0].count;
var least=items[items.length-1].count;
var groupSize=(most-least+1)/this.groups;
// sort by title and draw the cloud of items
items=items.sort(function(a,b){return(a.title==b.title)?0:(a.title>b.title?1:-1);});
var cloudWrapper = createTiddlyElement(place,'div',null,'tagCloud',null);
for (var t=0; t<items.length; t++) {
cloudWrapper.appendChild(document.createTextNode(' '));
var group=Math.ceil((items[t].count-least)/groupSize)||1;
var className='tagCloudtag tagCloud'+group;
var tip=refs?this.refstip:links?this.linkstip:this.tagstip;
tip=tip.format([items[t].title,items[t].count]);
if (action=='goto') { // TAG/LINK/REFERENCES GOTO
var btn=createTiddlyLink(cloudWrapper,items[t].title,true,className);
btn.title=tip;
btn.style.fontWeight='normal';
} else if (!links&&!refs) { // TAG POPUP
var btn=createTiddlyButton(cloudWrapper,items[t].title,tip,onClickTag,className);
btn.setAttribute('tag',items[t].title);
} else { // LINK/REFERENCES POPUP
var btn=createTiddlyButton(cloudWrapper,items[t].title,tip,
function(ev) { var e=ev||window.event; var cmt=config.macros.cloud;
var popup = Popup.create(this);
var title = this.getAttribute('tiddler');
var count = this.getAttribute('count');
var refs = this.getAttribute('refs')=='T';
var links = this.getAttribute('links')=='T';
var label = (refs?cmt.refslabel:cmt.linkslabel).format([count]);
createTiddlyLink(popup,title,true);
createTiddlyText(popup,label);
createTiddlyElement(popup,'hr');
if (refs) {
popup.setAttribute('tiddler',title);
config.commands.references.handlePopup(popup,title);
}
if (links) {
var tiddler = store.fetchTiddler(title);
var links=config.macros.cloud.getLinks(tiddler);
for(var i=0;i<links.length;i++)
createTiddlyLink(createTiddlyElement(popup,'li'),
links[i],true);
}
Popup.show();
e.cancelBubble=true; if(e.stopPropagation) e.stopPropagation();
return false;
}, className);
btn.setAttribute('tiddler',items[t].title);
btn.setAttribute('count',items[t].count);
btn.setAttribute('refs',refs?'T':'F');
btn.setAttribute('links',links?'T':'F');
btn.title=tip;
}
}
}
};
//}}}
/***
|Name|TagGridPlugin|
|Source|http://www.TiddlyTools.com/#TagGridPlugin|
|Documentation|http://www.TiddlyTools.com/#TagGridPluginInfo|
|Version|1.7.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|Generate a cross-referenced grid of tiddlers, based on tag values|
!!!!!Documentation
>see [[TagGridPluginInfo]]
!!!!!Revisions
<<<
2008.04.21 [1.7.0] added support for "filter:..." param to exclude tiddlers from grid
2008.01.08 [*.*.*] plugin size reduction: documentation moved to ...Info tiddler
2007.12.04 [*.*.*] update for TW2.3.0: replaced deprecated core functions, regexps, and macros
2007.07.24 [1.6.5] corrected handling for @TiddlerName with excluded tags, so that excluded tags are not actually removed from the @TiddlerName source tiddler.
|please see [[TagGridPluginInfo]] for additional revision details|
2006.10.05 [1.0.0] initial release (converted from prototype inline script)
<<<
!!!!!Code
***/
//{{{
version.extensions.TagGridPlugin= {major: 1, minor: 7, revision: 0, date: new Date(2008,4,21)};
config.macros.tagGrid= {
verbose:false, // display debugging/performance feedback messages
warn:true, // display workload warning message before rendering
threshold:300000, // workload warning threshold (workload=# of comparisons to perform)
handler:
function(place,macroName,params) {
// get columns
var columntags=params.shift(); var cols=[];
if ((!columntags)||(columntags=="all")) // no param (or "all") - use all tags
{ var all=store.getTags(); for (i=0;i<all.length;i++) cols.push(all[i][0]); }
else if (columntags.substr(0,1)=="+") // get tag list from tiddler content
{ var t=store.getTiddlerText(columntags.substr(1)); if (t&&t.length) cols=t.readBracketedList(); }
else if (columntags.substr(0,1)=="@") // get tag list from tiddler tags
{ var t=store.getTiddler(columntags.substr(1)); if (t&&t.tags) for (i=0;i<t.tags.length;i++) cols.push(t.tags[i]); }
else if (columntags.substr(0,1)=="=") // get names of "tagtiddlers" tagged with meta-tag
{ var t=store.getTaggedTiddlers(columntags.substr(1)); for (i=0;i<t.length;i++) cols.push(t[i].title); }
else cols=columntags.readBracketedList();
if (!cols.length) { wikify("~TagGrid: no columns to display\n",place); return; }
// exclude specific column tags
if (params[0]&¶ms[0].substr(0,8)=="exclude:") {
var ex=params.shift().substr(8).readBracketedList();
for (x=0; x<ex.length; x++) {
var i=cols.indexOf(ex[x]);
if (i!=-1) cols.splice(i,1); // remove excluded tags
}
}
// get rows
var rowtags=params.shift(); var rows=[];
if ((!rowtags)||(rowtags=="all")) // no param (or "all") - use all tags
{ var all=store.getTags(); for (i=0;i<all.length;i++) rows.push(all[i][0]); }
else if (rowtags.substr(0,1)=="+") // get tag list from tiddler content
{ var t=store.getTiddlerText(rowtags.substr(1)); if (t&&t.length) rows=t.readBracketedList(); }
else if (rowtags.substr(0,1)=="@") // get tag list from tiddler tags
{ var t=store.getTiddler(rowtags.substr(1)); if (t&&t.tags) for (i=0;i<t.tags.length;i++) rows.push(t.tags[i]); }
else if (rowtags.substr(0,1)=="=") // get names of "tagtiddlers" tagged with meta-tag
{ var t=store.getTaggedTiddlers(rowtags.substr(1)); for (i=0;i<t.length;i++) rows.push(t[i].title); }
else rows=rowtags.readBracketedList();
if (!rows.length) { wikify("~TagGrid: no rows to display\n",place); return; }
// exclude specific row tags
if (params[0]&¶ms[0].substr(0,8)=="exclude:") {
var ex=params.shift().substr(8).readBracketedList();
for (x=0; x<ex.length; x++) {
var i=rows.indexOf(ex[x]);
if (i!=-1) rows.splice(i,1); // remove excluded tags
}
}
// get optional tiddler filter
if (params[0]&¶ms[0].substr(0,7).toUpperCase()=="FILTER:")
var filter=params.shift().substr(7);
// get optional flag keywords and/or color gradient endpoints
var defOpen=false;
var colorAll=false;
var sortRows=false;
var sortColumns=false;
var showInline=false;
var p=params.shift();
while (p) {
switch (p.toUpperCase()) {
case "OPEN":
defOpen=true; break;
case "COLORALL":
colorAll=true; break;
case "SORTROWS":
sortRows=true; break;
case "SORTCOLUMNS":
sortColumns=true; break;
case "INLINE":
showInline=true; break;
default:
if (startcolor==undefined) var startcolor=p;
else if (endcolor==undefined) var endcolor=p;
else alert("unexpected parameter: '"+p+"'");
break;
}
p=params.shift();
}
// get the tiddlers
if (filter&&filter.length)
var tiddlers=store.filterTiddlers(filter);
else
var tiddlers=store.getTiddlers("modified","excludeLists");
// show "workload warning"... get permission to proceed...
if (this.warn) {
var workload=rows.length*cols.length*tiddlers.length;
var warning="Cross-indexing %0 tiddlers in %1 row%3 by %2 column%4...\n(up to %5 comparisons MAY be needed)\n\n";
warning+="This may take a while. It is OK to proceed?";
warning=warning.format([tiddlers.length,rows.length,cols.length,rows.length!=1?"s":"",cols.length!=1?"s":"",workload]);
if (workload>this.threshold&&!confirm(warning)) { wikify("~TagGrid: display cancelled by user\n",place); return; }
}
// sort row and column tags in decending order, by frequency of use
if (sortRows||sortColumns) {
var tags=store.getTags(); var tagcount={}; for (i=0; i<tags.length; i++) tagcount[tags[i][0]]=tags[i][1];
if (sortRows) rows.sort(function(a,b){return (!tagcount[a]||tagcount[a]<tagcount[b])?+1:(tagcount[a]==tagcount[b]?0:-1);});
if (sortColumns) cols.sort(function(a,b){return (!tagcount[a]||tagcount[a]<tagcount[b])?+1:(tagcount[a]==tagcount[b]?0:-1);});
}
// cross-index tiddlers by tags, building lists of tiddler titles into grid[i][j] (sparse array)
var time1=new Date();
var grid=new Array();
var max=0; // track maximum cross-index value
for (var t=0;t<tiddlers.length;t++) { // for each tiddler
for (var i=0;i<tiddlers[t].tags.length;i++) { // for each tag in tiddler
var row=rows.indexOf(tiddlers[t].tags[i]); if (row==-1) continue; // this tag not in rows
if (!grid[row]) grid[row]=new Array(); // create row as needed
for (var j=0;j<tiddlers[t].tags.length;j++) { // for each tag in tiddler
var col=cols.indexOf(tiddlers[t].tags[j]); if (col==-1) continue; // this tag not in columns
if (!grid[row][col]) grid[row][col]=new Array(); // create cell
grid[row][col].push("[["+tiddlers[t].title+"]]"); // add tiddler title to cell
if (max<grid[row][col].length) max=grid[row][col].length; // check for new maximum
}
}
}
// compute gradient color map
if (startcolor && endcolor) {
var digits="0123456789ABCDEF";
function hexToDec(s) // 2-digit conversion
{ return digits.indexOf(s.substr(0,1).toUpperCase())*16+digits.indexOf(s.substr(1,1).toUpperCase()); }
function decToHex(d) // 2-digit conversion
{ return digits.substr(Math.floor(d/16),1)+digits.substr(d%16,1); }
var steps=max;
var startR=hexToDec(startcolor.substr(0,2));
var startG=hexToDec(startcolor.substr(2,2));
var startB=hexToDec(startcolor.substr(4,2));
var endR=hexToDec(endcolor.substr(0,2));
var endG=hexToDec(endcolor.substr(2,2));
var endB=hexToDec(endcolor.substr(4,2));
var rangeR=endR-startR;
var rangeG=endG-startG;
var rangeB=endB-startB;
var stepR=rangeR/steps; if (stepR>0) stepR=Math.floor(stepR); else stepR=Math.ceil(stepR);
var stepG=rangeG/steps; if (stepG>0) stepG=Math.floor(stepG); else stepG=Math.ceil(stepG);
var stepB=rangeB/steps; if (stepB>0) stepB=Math.floor(stepB); else stepB=Math.ceil(stepB);
var colors=[];
colors[0]=startcolor;
for (var i=1; i<steps; i++)
colors[i]=decToHex(startR+stepR*i)+decToHex(startG+stepG*i)+decToHex(startB+stepB*i);
colors[steps-1]=endcolor; // fixup for roundoff error
}
// generate HTML table containing popups (and optional inline links)
var time2=new Date();
var out="<html><table cellpadding='0' cellspacing='0' style='border:0;border-collapse:collapse'>";
// column headings
out+="<tr style='border:0;'><td style='text-align:right;border:0'>";
out+="<a href='' style='font-size:80%;'";
out+=" title='show all column headings'";
out+=" onclick='return config.macros.tagGrid.toggleAllColumns(this,event,"+defOpen+")'>"+(defOpen?"<<<":">>>")+"</a>";
out+="</td>";
for (var i=0;i<cols.length;i++) {
out+="<td style='text-align:center;cursor:pointer;border:0;padding-left:2px;padding-right:2px' ";
out+=" title='show/hide column heading' ";
out+=" onclick='return config.macros.tagGrid.toggleColumn(this,event)'>";
out+="<a href='' title='open tag tiddler'";
if (!defOpen) out+=" style='display:none' ";
out+=" onclick='story.displayTiddler(this,\""+cols[i]+"\");return false'>"+cols[i]+"</a>";
out+="</td>";
}
out+="</tr>";
for (var i=0;i<rows.length;i++) {
// row heading
var rowlink="<a href='' onclick='story.displayTiddler(this,\""+rows[i]+"\");return false'>"+rows[i]+"</a>";
out +="<tr style='border:0'>";
out +="<td style='text-align:right;border:0;padding-right:2px'>"+rowlink+"</td>";
for (var j=0;j<cols.length;j++) {
var content="";
var bgcolor="transparent"; // default empty cell background
if (colors && colorAll) bgcolor="#"+colors[0]; // empty cell background uses startcolor
var bordercolor=""; // default border color (inherits current CSS value)
if (colors) bordercolor="#"+colors[Math.floor(colors.length/2-1)]; // border uses mid-tone color
var linkstyle=""; // use default unless background color is very light or very dark
var cross=(grid[i]&&grid[i][j])?grid[i][j]:null;
var hdr=rows[i]+(rows[i]!=cols[j]?(" + "+cols[j]):"");
if (cross) {
// cross-tagged list of tiddlers (in a popup)
var label="<b>"+cross.length+"</b>";
var tip=hdr;
var list=cross.sort().join(' ').replace(/'/g,"\\'").replace(/"/g,'"');
var handler="return config.macros.tagGrid.popup(this,event,\'"+rows[i]+"\',\'"+cols[j]+"\',\'"+list+"\')";
if (colors) {
var c=colors[cross.length-1];
bgcolor="#"+c;
linkstyle="style='color:#000000 !important'";
// invert link color if background is very light
if (c.substr(0,2)<"60" || c.substr(2,2)<"60" || c.substr(4,2)<"60")
linkstyle="style='color:#FFFFFF !important'";
}
} else {
var label=" - ";
var tip="create a new tiddler tagged with: "+hdr;
var list="";
var handler="var title=config.macros.newTiddler.title;";
handler+="story.displayTiddler(this,title,DEFAULT_EDIT_TEMPLATE);";
handler+="story.setTiddlerTag(title,\'"+rows[i]+"\',+1);";
handler+="story.setTiddlerTag(title,\'"+cols[j]+"\',+1);";
handler+="story.focusTiddler(title,\'text\');return(false);";
}
if (!showInline || !cross)
content+='<a href="javascript:;" '+linkstyle+' onclick="'+handler+'" title="'+tip+'">'+label+'</a>';
if (showInline && cross) {
content+="<div "+linkstyle+"><span style='white-space:nowrap'>";
content+=hdr+" ("+label+")";
content+="</span></div><hr>";
// list tiddler links inline in table cell
for (t=0; t<cross.length; t++) {
var title=cross[t].replace(/\[\[/g,'').replace(/\]\]/g,'');
var handler="story.displayTiddler(null,'"+title+"');return false;"
var tid=store.getTiddler(title);
var author=tid.modifier;
var date=tid.modified.toLocaleString();
var tip=config.messages.tiddlerLinkTooltip.format([title,author,date]);
if (t>0) content+="<br>";
content+='<a href="javascript:;" '+linkstyle+' onclick="'+handler+'" title="'+tip+'">'+title+'</a>';
}
content+="<hr>";
handler="var tids=\'"+list+"\'.readBracketedList();story.displayTiddlers(this,tids); return(false);"
tip="display all tiddlers tagged with: "+hdr;
content+='<a href="javascript:;" '+linkstyle+' onclick="'+handler+'" title="'+tip+'">open all...</a><br>';
handler="var title=config.macros.newTiddler.title;";
handler+="story.displayTiddler(this,title,DEFAULT_EDIT_TEMPLATE);";
handler+="story.setTiddlerTag(title,\'"+rows[i]+"\',+1);";
handler+="story.setTiddlerTag(title,\'"+cols[j]+"\',+1);";
handler+="story.focusTiddler(title,'text'); return(false);"
tip="create a new tiddler tagged with: "+hdr;
content+='<a href="javascript:;" '+linkstyle+' onclick="'+handler+'" title="'+tip+'">new tiddler...</a>';
}
out+="<td style='background-color:"+bgcolor+";border:1px solid "+bordercolor+" !important;text-align:center'>"+content+"</td>";
}
out+="</tr>";
}
out+="</table>";
out+="</html>";
createTiddlyElement(place,"span").innerHTML=out;
var time3=new Date();
if (this.verbose) displayMessage("TagGrid: scan="+(time2-time1)+", generate table="+(time3-time2));
},
popup:
function(here,event,row,col,list) {
var tids=list.replace(/"/g,'"').readBracketedList();
var hdr=row+(row!=col?(" AND "+col):"");
if (tids.length) {
var p=Popup.create(here); if (!p) return;
createTiddlyText(p,hdr);
createTiddlyElement(p,'hr');
for(var t=0; t<tids.length; t++) createTiddlyLink(createTiddlyElement(p,'li'),tids[t],true);
createTiddlyElement(p,'hr');
createTiddlyButton(createTiddlyElement(p,'li'),
"open all...", "display all tiddlers tagged with: "+hdr,
function(){story.displayTiddlers(null,tids); return(false);});
var a=createTiddlyButton(createTiddlyElement(p,'li'),
"new tiddler...", "create a new tiddler tagged with: "+hdr,
function(){
var title=config.macros.newTiddler.title;
story.displayTiddler(this,title,DEFAULT_EDIT_TEMPLATE);
story.setTiddlerTag(title,this.getAttribute("rowtag"),+1);
story.setTiddlerTag(title,this.getAttribute("coltag"),+1);
story.focusTiddler(title,"text");
return(false);
});
a.setAttribute("rowtag",row);
a.setAttribute("coltag",col);
Popup.show();
}
event.cancelBubble = true;
if (event.stopPropagation) event.stopPropagation();
return(false);
},
toggleAllColumns:
function(here,event,defOpen) {
if (here.expanded==undefined) here.expanded=defOpen;
var ex=here.expanded=!here.expanded;
here.innerHTML=ex?"<<<":">>>";
here.title=ex?'hide all column headings':'show all column headings';
var cells=here.parentNode.parentNode.getElementsByTagName("td");
for (i=1; i<cells.length; i++) cells[i].firstChild.style.display=ex?"inline":"none";
event.cancelBubble = true;
if (event.stopPropagation) event.stopPropagation();
return(false);
},
toggleColumn:
function(here,event) {
here.firstChild.style.display=(here.firstChild.style.display=="none")?"inline":"none";
event.cancelBubble = true;
if (event.stopPropagation) event.stopPropagation();
return(false);
}
};
//}}}
/***
|Name|TagGridPluginInfo|
|Source|http://www.TiddlyTools.com/#TagGridPlugin|
|Documentation|http://www.TiddlyTools.com/#TagGridPluginInfo|
|Version|1.7.0|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|documentation|
|Requires||
|Overrides||
|Description|documentation for TagGridPlugin|
!!!!!Usage
<<<
Specify which tags should be used for the columns and rows of the grid to ''see a particular cross-section'' of your document, or use //all// tags to ''get an instant 'birds-eye' overview of your entire document''.
Each grid cell contains a label with the number of tiddlers in that grid cell. Click the number to ''show a popup of cross-indexed tiddler titles''. Grid cells with no matching tiddlers contain a "-" (dash) that can be clicked to ''create new tiddlers automatically pre-tagged with that cell's combination of tags.''
To keep the grid display from getting very wide, the grid tags used as column headings are not initially displayed. ''Click directly above the column to show/hide that heading'', or toggle all column headings at once by clicking the {{{>>>}}} symbol in the upper-left corner of the grid display. Clicking a displayed row/column tag heading opens the tiddler whose title is that tag name.
The macro syntax to include a tag grid in your tiddler content is:
{{{
<<tagGrid "columntags" "exclude:tags" "rowtags" "exclude:tags" "filter:tiddlerfilter" startcolor endcolor open inline colorall sortrows sortcolumns>>
}}}
where:
''rowtags/columntags'' are each:
* a ''quoted'' space-separated lists of tags: {{{"tag1 tag2 [[tag3 with spaces]] tag4 ..."}}}
* //or,// a tiddler name preceded by "+": {{{+TiddlerName}}} where the specified tiddler contains a space-separated list of tags (same format as DefaultTiddlers)
* //or,// a tiddler name preceded by "@": {{{@TiddlerName}}} to use the same tags as those that are tagging the specified tiddler (i.e., the tiddler is a representative example of the kind of tags you are interested in cross-indexing)
* //or,// a tag name preceded by "=": {{{=tagName}}} to use the group of tags that are themselves, in turn, tagged with the indicated tagName (i.e., useful when you have defined a 'meta-tag'/classification system, a.k.a. "~TagglyTagging" techniques)
* //or,// keyword: {{{all}}} (use all tags)
* if only columntags are specified, rows display all tags by default
* if no parameters are provided, both rows and columns display all tags
''exclude:tag tag tag''
* This //optional// parameter can be placed immediately following the columntags and/or rowtags parameter to selectively omit certain tags from the grid row or column headings. You can exclude several tags at once by enclosing the entire parameter in quotes, e.g.: {{{"exclude:tag tag tag"}}}. This parameter is generally only needed to adjust the set of row/column headings that will be applied when using the {{{@TiddlerName}}} syntax. Otherwise, you can simply omit the undesired rows/column headings directly from the specified columntags and/or rowstags parameters.
''"filter:tiddlerfilter"''
* By default, all tiddlers in the document are scanned to determine the contents of the grid cells. The //optional// filter parameter allows you to specify a subset of tiddler to be scanned. The syntax for this parameter is: {{{"filter:[tag[tagname]]"}}}, which will select only tiddlers with the indicated tag. For more advanced selection of tiddlers, you can install [[MatchTagsPlugin]], which extends the {{{[tag[...]]}}} filter syntax to permit use of full boolean expressions, e.g., {{{"filter:[tag[NOT tag1]]"}}} or {{{"filter:[tag[tag1 AND NOT tag2]]"}}} or {{{"filter:[tag[(tag1 AND tag2) OR (tag3 AND NOT tag4)]]"}}}, etc.
''startcolor/endcolor''
* describes a ''color gradient'' where the grid cell background color is calculated as a combination of the starting and ending colors, in proportion to the cell value
* colors are specified using 6-digit hex-coded RGB values (e.g., red="~FF0000", green="00FF00", blue="0000FF")
* the cells with the lowest number use the starting background color
* the cells with the highest number use the ending background color
* if one or both color values are omitted, all cells have //transparent// backgrounds
''open''
* causes the grid column headings to be shown when the grid is initially displayed (you can hide all the column headings using the ⇐ link, or just toggle one heading by clicking //near// the tag text. (Note: clicking //on// the tag text will open the tiddler with the same name as the tag.
''inline''
* by default, cells with cross-indexed tiddlers display the total number of tiddlers in the cell. When this number is clicked, a popup is displayed, containing links to the individual tiddlers in that cell. However, the popup display makes it difficult to compare the contents of two or more cells because only one popup can be displayed at any given time. To address this, you can use the ''inline'' keyword parameter to ''display the grid contents directly in the cells'', without using any popups. While this can make the grid display significantly larger (to fit the text of each cell), it also enables quick comparisons between cells. Inline rendering of the cell contents also makes it possible to print the entire grid contents for easy off-line reporting and analysis.
''colorall''
* by default, cells with no cross-indexed tiddlers have a //transparent// background (e.g., the tiddler's background colors shows through). However, this can create a 'patchwork' appearance to the grid. Add the ''colorall'' keyword parameter to force these 'empty' cells to use the specified startcolor instead of a transparent background.
''sortrows/sortcolumns''
* rowtags and columntags are normally displayed in the order specified in the macro parameters, or in alphabetical order when ''all'' is used to generate the list of tags. Adding the ''sortrows'' and/or ''sortcolumns'' keyword parameters will sort the tags in decending order so that the most frequently used tags are displayed first (i.e., towards the top-left corner).
<<<
!!!!!Examples
<<<
{{{<<tagGrid +FavoriteTags +FavoriteTags eeeeff 3333ff colorall sortrows sortcolumns>>}}}
<<tagGrid +FavoriteTags +FavoriteTags eeeeff 3333ff colorall sortrows sortcolumns>>
<<<
!!!!!Revisions
<<<
2008.04.21 [1.7.0] added support for "filter:..." param to exclude tiddlers from grid
2008.01.08 [*.*.*] plugin size reduction: documentation moved to ...Info tiddler
2007.12.04 [*.*.*] update for TW2.3.0: replaced deprecated core functions, regexps, and macros
2007.07.24 [1.6.5] corrected handling for @TiddlerName with excluded tags, so that excluded tags are not actually removed from the @TiddlerName source tiddler.
2007.07.04 [1.6.4] fix fatal "unterminated string" popup error caused by tiddlers containing double-quotes (now being encoded using """)
2007.03.08 [1.6.3] use global flag to replace ALL single-quotes in tiddler titles (fixes popups where more than one tiddler title had a ' in it)
2007.03.06 [1.6.2] removed debugging alert()s... D'oh!
2007.03.06 [1.6.1] fix handling for excluding tags (was only removing last tag in list)
2007.03.05 [1.6.0] added "exclude:tag tag tag..." parameter handling for both rows and columns
2006.12.20 [1.5.1] fixed bordercolor calculation and CSS so grid correctly uses midtone-color for table cell borders
2006.12.09 [1.5.0] added 'inline' keyword parameter to display tiddler titles directly in grid cells (in addition to popup)
2006.11.03 [1.4.0] changed {{{=TiddlerName}}} param usage to {{{@TiddlerName}}} and added {{{=tagName}}} usage for specifying TagglyTagging "meta-tagged" groups of tag (based on ideas by GregWolff)
2006.11.03 [1.3.3] performance optimization: calculate maximum cross-index value while building grid (eliminates extra calc during colormapping)
2006.10.29 [1.3.2] fixes for IE: in decToHex and hexToDec, use substr() instead array indexing. Also, use {{{>>>}}} and {{{<<<}}} instead of {{{⇒}}} and {{{⇐}}} for 'toggle headings' link text
2006.10.29 [1.3.1] suppress border around table
2006.10.21 [1.3.0] added {{{=TiddlerName}}} and {{{open}}} parameter handling
2006.10.17 [1.2.1] fixed row/column sorting to properly sort undefined tags to the end of the list
2006.10.16 [1.2.0] added optional row/column sorting and improved parameter parsing
2006.10.15 [1.1.0] added features: background gradients, collapsible column headings, eliminated table borders around row/column headings
2006.10.06 [1.0.1] calls to displayTiddler() use 'this' instead of 'null'
2006.10.05 [1.0.0] initial release (converted from prototype inline script)
<<<
/***
|''Name:''|~TaggerPlugin|
|''Version:''|1.0.1 (2006-06-01)|
|''Source:''|http://tw.lewcid.org//#TaggerPlugin|
|''Author:''|SaqImtiaz|
|''Description:''|Provides a drop down listing current tiddler tags, and allowing toggling of tags.|
|''Documentation:''|[[TaggerPluginDocumentation]]|
|''Source Code:''|[[TaggerPluginSource]]|
|''~TiddlyWiki:''|Version 2.0.8 or better|
***/
// /%
config.tagger={defaults:{label:"Tags: ",tooltip:"Manage tiddler tags",taglist:"true",excludeTags:"",notags:"tiddler has no tags",aretags:"current tiddler tags:",toggletext:"add tags:"}};config.macros.tagger={};config.macros.tagger.arrow=(document.all?"▼":"▾");config.macros.tagger.handler=function(_1,_2,_3,_4,_5,_6){var _7=config.tagger.defaults;var _8=_5.parseParams("tagman",null,true);var _9=((_8[0].label)&&(_8[0].label[0])!=".")?_8[0].label[0]+this.arrow:_7.label+this.arrow;var _a=((_8[0].tooltip)&&(_8[0].tooltip[0])!=".")?_8[0].tooltip[0]:_7.tooltip;var _b=((_8[0].taglist)&&(_8[0].taglist[0])!=".")?_8[0].taglist[0]:_7.taglist;var _c=((_8[0].exclude)&&(_8[0].exclude[0])!=".")?(_8[0].exclude[0]).readBracketedList():_7.excludeTags.readBracketedList();if((_8[0].source)&&(_8[0].source[0])!="."){var _d=_8[0].source[0];}if(_d&&!store.getTiddler(_d)){return false;}var _e=function(e){if(!e){var e=window.event;}var _11=Popup.create(this);var _12=store.getTags();var _13=new Array();for(var i=0;i<_12.length;i++){_13.push(_12[i][0]);}if(_d){var _15=store.getTiddler(_d);_13=_15.tags.sort();}var _16=_6.tags.sort();var _17=function(_18,_19,_1a){var sp=createTiddlyElement(createTiddlyElement(_11,"li"),"span",null,"tagger");var _1c=createTiddlyButton(sp,_18,_1a+" '"+_19+"'",taggerOnToggle,"button","toggleButton");_1c.setAttribute("tiddler",_6.title);_1c.setAttribute("tag",_19);insertSpacer(sp);if(window.createTagButton_orig_mptw){createTagButton_orig_mptw(sp,_19)}else{createTagButton(sp,_19);}};createTiddlyElement(_11,"li",null,"listTitle",(_6.tags.length==0?_7.notags:_7.aretags));for(var t=0;t<_16.length;t++){_17("[x]",_16[t],"remove tag ");}createTiddlyElement(createTiddlyElement(_11,"li"),"hr");if(_b!="false"){createTiddlyElement(_11,"li",null,"listTitle",_7.toggletext);for(var i=0;i<_13.length;i++){if(!_6.tags.contains(_13[i])&&!_c.contains(_13[i])){_17("[ ]",_13[i],"add tag ");}}createTiddlyElement(createTiddlyElement(_11,"li"),"hr");}var _1f=createTiddlyButton(createTiddlyElement(_11,"li"),("Create new tag"),null,taggerOnToggle);_1f.setAttribute("tiddler",_6.title);if(_d){_1f.setAttribute("source",_d);}Popup.show(_11,false);e.cancelBubble=true;if(e.stopPropagation){e.stopPropagation();}return (false);};createTiddlyButton(_1,_9,_a,_e,"button","taggerDrpBtn");};window.taggerOnToggle=function(e){var tag=this.getAttribute("tag");var _22=this.getAttribute("tiddler");var _23=store.getTiddler(_22);if(!tag){var _24=prompt("Enter new tag:","");if(_24!=""&&_24!=null){var tag=_24;if(this.getAttribute("source")){var _26=store.getTiddler(this.getAttribute("source"));_26.tags.pushUnique(_24);}}else{return false;}}if(!_23||!_23.tags){store.saveTiddler(_22,_22,"",config.options.txtUserName,new Date(),tag);}else{if(_23.tags.find(tag)==null){_23.tags.push(tag);}else{if(!_24){_23.tags.splice(_23.tags.find(tag),1);}}store.saveTiddler(_23.title,_23.title,_23.text,_23.modifier,_23.modified,_23.tags);}story.refreshTiddler(_22,null,true);if(config.options.chkAutoSave){saveChanges();}return false;};setStylesheet(".tagger a.button {font-weight: bold;display:inline; padding:0px;}\n"+".tagger #toggleButton {padding-left:2px; padding-right:2px; margin-right:1px; font-size:110%;}\n"+"#nestedtagger {background:#2E5ADF; border: 1px solid #0331BF;}\n"+".popup .listTitle {color:#000;}\n"+"","TaggerStyles");window.lewcidTiddlerSwapTag=function(_27,_28,_29){for(var i=0;i<_27.tags.length;i++){if(_27.tags[i]==_28){_27.tags[i]=_29;return true;}}return false;};window.lewcidRenameTag=function(e){var tag=this.getAttribute("tag");var _2d=prompt("Rename tag '"+tag+"' to:",tag);if((_2d==tag)||(_2d==null)){return false;}if(store.tiddlerExists(_2d)){if(confirm(config.messages.overwriteWarning.format([_2d.toString()]))){story.closeTiddler(_2d,false,false);}else{return null;}}tagged=store.getTaggedTiddlers(tag);if(tagged.length!=0){for(var j=0;j<tagged.length;j++){lewcidTiddlerSwapTag(tagged[j],tag,_2d);}}if(store.tiddlerExists(tag)){store.saveTiddler(tag,_2d);}if(document.getElementById("tiddler"+tag)){var _2f=document.getElementById(story.idPrefix+tag);var _30=story.positionTiddler(_2f);var _31=document.getElementById(story.container);story.closeTiddler(tag,false,false);story.createTiddler(_31,_30,_2d,null);story.saveTiddler(_2d);}if(config.options.chkAutoSave){saveChanges();}return false;};window.onClickTag=function(e){if(!e){var e=window.event;}var _34=resolveTarget(e);var _35=(!isNested(_34));if((Popup.stack.length>1)&&(_35==true)){Popup.removeFrom(1);}else{if(Popup.stack.length>0&&_35==false){Popup.removeFrom(0);}}var _36=(_35==false)?"popup":"nestedtagger";var _37=createTiddlyElement(document.body,"ol",_36,"popup",null);Popup.stack.push({root:this,popup:_37});var tag=this.getAttribute("tag");var _39=this.getAttribute("tiddler");if(_37&&tag){var _3a=store.getTaggedTiddlers(tag);var _3b=[];var li,r;for(r=0;r<_3a.length;r++){if(_3a[r].title!=_39){_3b.push(_3a[r].title);}}var _3d=config.views.wikified.tag;if(_3b.length>0){var _3e=createTiddlyButton(createTiddlyElement(_37,"li"),_3d.openAllText.format([tag]),_3d.openAllTooltip,onClickTagOpenAll);_3e.setAttribute("tag",tag);createTiddlyElement(createTiddlyElement(_37,"li"),"hr");for(r=0;r<_3b.length;r++){createTiddlyLink(createTiddlyElement(_37,"li"),_3b[r],true);}}else{createTiddlyText(createTiddlyElement(_37,"li",null,"disabled"),_3d.popupNone.format([tag]));}createTiddlyElement(createTiddlyElement(_37,"li"),"hr");var h=createTiddlyLink(createTiddlyElement(_37,"li"),tag,false);createTiddlyText(h,_3d.openTag.format([tag]));createTiddlyElement(createTiddlyElement(_37,"li"),"hr");var _40=createTiddlyButton(createTiddlyElement(_37,"li"),("Rename tag '"+tag+"'"),null,lewcidRenameTag);_40.setAttribute("tag",tag);}Popup.show(_37,false);e.cancelBubble=true;if(e.stopPropagation){e.stopPropagation();}return (false);};if(!window.isNested){window.isNested=function(e){while(e!=null){var _42=document.getElementById("contentWrapper");if(_42==e){return true;}e=e.parentNode;}return false;};}config.shadowTiddlers.TaggerPluginDocumentation="The documentation is available [[here.|http://tw.lewcid.org/#TaggerPluginDocumentation]]";config.shadowTiddlers.TaggerPluginSource="The uncompressed source code is available [[here.|http://tw.lewcid.org/#TaggerPluginSource]]";
// %/
/***
|''Name:''|TagsTreePlugin|
|''Description:''|Displays tags hierachy as a tree of tagged tiddlers.<br>Can be used to create dynamic outline navigation.|
|''Version:''|1.0.1|
|''Date:''|Jan 04,2008|
|''Source:''|http://visualtw.ouvaton.org/VisualTW.html|
|''Author:''|Pascal Collin|
|''License:''|[[BSD open source license|License]]|
|''~CoreVersion:''|2.1.0|
|''Browser:''|Firefox 2.0; InternetExplorer 6.0|
!Demo
On the plugin [[homepage|http://visualtw.ouvaton.org/VisualTW.html]] :
*Try to tag some <<newTiddler>> with a tag displayed in the menu and edit MainMenu.
*Look at some tags like [[Plugins]] or [[menu]].
!Installation
#import the plugin,
#save and reload,
#optionally, edit TagsTreeStyleSheet.
! Usage
{{{<<tagsTree>>}}} macro accepts the following //optional// parameters.
|!#|!parameter|!description|!by default|
|1|{{{root}}}|Uses {{{root}}} tag as tree root|- In a //tiddler// content or template : uses the tiddler as root tag.<br>- In the //page// content or template (by ex MainMenu) : displays all untagged tags.|
|2|{{{excludeTag}}}|Excludes all such tagged tiddlers from the tree|Uses default excludeLists tag|
|3|{{{level}}}|Expands nodes until level {{{level}}}.<br>Value {{{0}}} hides expand/collapse buttons.|Nodes are collapsed on first level|
|4|{{{depth}}}|Hierachy depth|6 levels depth (H1 to H6 header styles)|
|5|{{{sortField}}}|Alternate sort field. By example : "index".|Sorts tags and tiddlers alphabetically (on their title)|
|6|{{{labelField}}}|Alertnate label field. By example : "label".|Displays tiddler's title|
!Useful addons
*[[FieldsEditorPlugin]] : //create//, //edit//, //view// and //delete// commands in toolbar <<toolbar fields>>.
*[[TaggerPlugin]] : Provides a drop down listing current tiddler tags, and allowing toggling of tags.
!Advanced Users
You can change the global defaults for TagsTreePlugin, like default {{{level}}} value or level styles, by editing or overriding the first config.macros.tagsTree attributes below.
!Code
***/
//{{{
config.macros.tagsTree = {
expand : "+",
collapse : "–",
depth : 6,
level : 1,
sortField : "",
labelField : "",
styles : ["h1","h2","h3","h4","h5","h6"],
trees : {}
}
config.macros.tagsTree.handler = function(place,macroName,params,wikifier,paramString,tiddler)
{
var root = params[0] ? params[0] : (tiddler ? tiddler.title : null);
var excludeTag = params[1] ? params[1] : "excludeTagsTree";
var level = params[2] ? params[2] : config.macros.tagsTree.level;
var depth = params[3] ? params[3] : config.macros.tagsTree.depth;
var sortField = params[4] ? params[4] : config.macros.tagsTree.sortField;
var labelField = params[5] ? params[5] : config.macros.tagsTree.labelField;
var showButtons = (level>0);
var id = config.macros.tagsTree.getId(place);
if (config.macros.tagsTree.trees[id]==undefined) config.macros.tagsTree.trees[id]={};
config.macros.tagsTree.createSubTree(place,id,root,excludeTag,[],level>0 ? level : 1,depth, sortField, labelField,showButtons);
}
config.macros.tagsTree.createSubTree = function(place, id, root, excludeTag, ancestors, level, depth, sortField, labelField,showButtons){
var childNodes = root ? this.getChildNodes(root, ancestors) : this.getRootTags(excludeTag);
var isOpen = (level>0) || (!showButtons);
if (root && this.trees[id][root]!=undefined) isOpen = this.trees[id][root];
if (root && ancestors.length) {
var t = store.getTiddler(root);
if (childNodes.length && depth>0) {
var wrapper = createTiddlyElement(place , this.styles[Math.min(Math.max(ancestors.length,1),6)-1],null,"branch");
if (showButtons) {
b = createTiddlyButton(wrapper, isOpen ? config.macros.tagsTree.collapse : config.macros.tagsTree.expand, null, config.macros.tagsTree.onClick);
b.setAttribute("treeId",id);
b.setAttribute("tiddler",root);
}
createTiddlyText(createTiddlyLink(wrapper, root),t&&labelField ? t.fields[labelField] ? t.fields[labelField] : root : root);
}
else
createTiddlyText(createTiddlyLink(place, root,false,"leaf"),t&&labelField ? t.fields[labelField] ? t.fields[labelField] : root : root);
}
if (childNodes.length && depth) {
var d = createTiddlyElement(place,"div",null,"subtree");
d.style.display= isOpen ? "block" : "none";
if (sortField)
childNodes.sort(function(a, b){
var fa=a.fields[sortField];
var fb=b.fields[sortField];
return (fa==undefined && fb==undefined) ? a.title < b.title ? -1 : a.title > b.title ? 1 : 0 : (fa==undefined && fb!=undefined) ? 1 :(fa!=undefined && fb==undefined) ? -1 : fa < fb ? -1 : fa > fb ? 1 : 0;
})
for (var cpt=0; cpt<childNodes.length; cpt++)
this.createSubTree(d, id, childNodes[cpt].title, excludeTag, ancestors.concat(root), level-1, depth-1, sortField, labelField, showButtons);
}
}
config.macros.tagsTree.onClick = function(e){
var id = this.getAttribute("treeId");
var tiddler = this.getAttribute("tiddler");
var n = this.parentNode.nextSibling;
var isOpen = n.style.display != "none";
if(config.options.chkAnimate && anim && typeof Slider == "function")
anim.startAnimating(new Slider(n,!isOpen,null,"none"));
else
n.style.display = isOpen ? "none" : "block";
this.firstChild.nodeValue = isOpen ? config.macros.tagsTree.expand : config.macros.tagsTree.collapse;
config.macros.tagsTree.trees[id][tiddler]=!isOpen;
return false;
}
config.macros.tagsTree.getChildNodes = function(root ,ancestors){
var childs = store.getTaggedTiddlers(root);
var result = new Array();
for (var cpt=0; cpt<childs.length; cpt++)
if (childs[cpt].title!=root && ancestors.indexOf(childs[cpt].title)==-1) result.push(childs[cpt]);
return result;
}
config.macros.tagsTree.getRootTags = function(excludeTag){
var tags = store.getTags(excludeTag);
tags.sort(function(a,b) {return a[0].toLowerCase() < b[0].toLowerCase() ? -1 : (a[0].toLowerCase() == b[0].toLowerCase() ? 0 : +1);});
var result = new Array();
for (var cpt=0; cpt<tags.length; cpt++) {
var t = store.getTiddler(tags[cpt][0]);
if (!t || t.tags.length==0) result.push(t ? t : {title:tags[cpt][0],fields:{}});
}
return result;
}
config.macros.tagsTree.getId = function(element){
while (!element.id && element.parentNode) element=element.parentNode;
return element.id ? element.id : "<html>";
}
config.shadowTiddlers.TagsTreeStyleSheet = "/*{{{*/\n";
config.shadowTiddlers.TagsTreeStyleSheet +=".leaf, .subtree {display:block; margin-left : 0.5em}\n";
config.shadowTiddlers.TagsTreeStyleSheet +=".subtree {margin-bottom:0.5em}\n";
config.shadowTiddlers.TagsTreeStyleSheet +="#mainMenu {text-align:left}\n";
config.shadowTiddlers.TagsTreeStyleSheet +=".branch .button {border:1px solid #DDD; color:#AAA;font-size:9px;padding:0 2px;margin-right:0.3em;vertical-align:middle;text-align:center;}\n";
config.shadowTiddlers.TagsTreeStyleSheet +="/*}}}*/";
store.addNotification("TagsTreeStyleSheet", refreshStyles);
config.shadowTiddlers.MainMenu="<<tagsTree>>"
config.shadowTiddlers.PageTemplate = config.shadowTiddlers.PageTemplate.replace(/id='mainMenu' refresh='content' /,"id='mainMenu' refresh='content' force='true' ")
//}}}