At the meeting, we discussed the standard for model metadata developed at UCSB a few years back as a starting point for discussions about how to document models.
See the description of the standard at
http://www.ncgia.ucsb.edu/projects/metadata/intro/index.html
There is a lot of potentially useful information – and many links (none of which I’ve followed yet) – on this very long page.
Michael
Dan et.al.
Thanks. I realized that this forum and the newly renamed software related version of it cover much of the ground. I had originally thought that this effort was more focussed on publication efforts, e.g. Volker’s work. But in looking over the resources you share, there is definetly a strong meta-model flavor as well.
I have defined a reasonably formal meta-model (based in part on the design, e.g. Context’s, presented by Tom Howe et.al. at Agent 2006) and surrounding tools that I would love to have feedback on over in the other forum.
A very specifc question to answer over the next few months then is, does the proposed meta-model cover the general issues outlined, that is, could you produce the data you need for a metadata instance from what is provided in this Meta-model? If not, what needs to be added?
And of course the really important question – should followup be here or in the other forum?! 
Somehow my earlier post got lost too…hmm.
Dan, et.al.
Thanks for sharing this paper. It is becoming more clear that there is a large amount of overlap between this and the software area – originally I had thought that this kind of metadata would involve publishing issue, such as indexing keyworks, attribution, etc… but taking a look at the paper, it seems to involve a lot of actual model contruciton and behavior issues. (btw, i didn’t see a finsihed specification on that page, but I haven’t read it in depth yet.)
As I posted in the meta-model forum, I have been defining a Meta-Model for ABM (utilizing the Context idea in Tom Howe, et.al. paper at Agent 2006) work which is now feature complete and has a set of supporting tools and realizations. What it needs is input from others. One clear need is for people involved in publication to take a look at the model and determine whether the neccessary metadata can be constructed from it, and if not what needs to be added.
And I guess the meta-discussion question is what meta-forum topic this discussion should take place under? 
Miles et al,
There are indeed a couple of different issues but they are certainly linked.
There are perhaps a couple of levels of metadata. One level is the focus of Volker’s work. That is, how can you describe a model–especially a computer simulation model and ABM–in such a way that it can be understood and potentially replicated (conceptually at least) by others. This is a hallmark of science, as it has been successfully practiced and an important rationale behind the pressure to publish. We lack any sort of standard descriptive language for conveying to other researchers what such a model does and how it does it. It is critical that we achieve this so that we can benefit from (and be credentialed by) the evaluation of peer scientists.
The different but related issue is how can you describe a computer simulation–and especially an ABM–so that other modeling software can understand and replicate it? This probably requires a somewhat different level of metadata, and especially different ways of specifying it. This is equally necessary in order to build on the work of others. Because ABMs are so complex, it is highly desirable to be able to reimplement a successful simulation in another context, rather than having to start coding from scratch–even if you have a “thick description” of the sort that Volker’s standard proscribes. However, this is very difficult if there is no possibility for portability among models. Portability, in turn, requires a data description language (i.e., metadata).
Michael
Yes that is precisely the distinction I wanted to make. In fact, I believe that it is possible to dock the two, at least conceptually. Ideally the – for lack of a better work – Implementable meta-model would be a complete super-set of the Descriptive meta-model. That is, can we always derive the Description from the Implementable? For this, the Descriptive is neccessary but not sufficient in order to create a fully docked model while the Implementable aims to be sufficient as well.
This is more clearly so for the basic structure and parameterization of the model, but I would make the stronger claim that it can also be so for behavior. I will post more description of a behavior meta-model soon so other’s can test just how false that claim is! Seriously, we know that there will always be a set of behavior that cannot be described by any particular model i.e. Frame Problem, but if we sufficiently contrain what we mean by an “ABM” it should be possible.
[Speaking of which, we have now clearly crossed the line into the other forum… :)]
The issue becomes more interesting when we can derive the Implementation form the Implementable. I have a demonstration model of implementations of MetaABM models in both Repast S and Ascape derived automatically from templates. It also produces a very simple HTML representation of the defined meta-model (thanks to Tom H. for the first v of that). Now, two gigantic open issues are
Both of these points would I suppose argue that we should not rely on my belief that it is possible to derive the metadata from a meta-model, but instead they argue that the meta-model would benefit greatly from any attempts to do so.