Balint and Dirk recently circulated opinions on this issue.
((T.Yoshie, 2005 Nov 15))
I think should be thinking about how we extend the data to derived lattice
quantities. Should this be a separate discussion thread as it is open-ended
and only just starting!
(( C. Maynard, 2005-11-15))
OK. let us continue discussions in separate series of Emails.
((T. Yoshie, 2005-11-17))
OK. Let us start that discussion. I should add that both Dirk and
I seem to agree that 'lattice scale' or 'lattice spacing' is an
fairly badly defined concept. However as Dirk said, a from r0a, r1a
or some other concrete observable is much more clearly defined. My
colleagues
in MILC are very keen to do queries on the lattice spacing. Since they
have control over their dataLFNs if we don't extend the schema, they will
encode it there. That is to my mind undesirable. Fundmentally adding
observables is no different from adding actions. I would therefore
recommend that procedures in section F) apply here too.
((B. Joo, 2005-18-11))
I suggest to extent the element <physics> by the optional element
<observables> which has the following sub-structure:
       <observables>
         <elem>
           <type>...</type>
           <val>...</val>
           <err>...</err>
         </elem>
         ...
       </observables>
Comments:
- Initial list of types: ar0, ar1, mv/mps, plaquette
- It would not be possible to query for all configurations with,
       e.g., x fm <= a <= y fm.
- Searching for ensembles with a particular lattice spacing is
       only possible when the researcher accepts, e.g., the definition
       a^phys = (a/r0) r0^phys. In this particular example, the search
       will not match ensembles for which ar0 has not been measured
       even if ar1 has been measured.
((D. Pleiter, 2005 Nov 20))

I agree Dirks proposal. Don't we have to have glossary for observables?
((T. Yoshie, 2005 Nov 21))

This seems reasonable to me. Should we forsee one glossary of the
section <observables> or one for <elem>?
((D. Pleiter, 2005 Nov 21))

I prefer one for each <elem>.
(( T.Yoshie, 2005 Nov 21))

I would recommend that "type" be "name" instead -- but this is just a
nicety.
The initial list of names/types is fine. However, if we have a glossary on
each element
or even just on the whole list, what is wrong with just having a "lattice
spacing"
observable 'a'? It is no more ambiguous than the "<date>" tag in "<code>".
In fact
with a 'glossary' it is much less so. The glossary could even give a full
journal
citation). In this case some kind of "units" tag would be good. ie:
<observables>
    <elem>
      <name>   </name>
      <val>    </val>
      <err>    </err>
      <physical>
        <units>   </units>
      </physical>
      <glossary>  </glossary>
    </elem>
</observables>
where we'd need to agree on unit conventions to allow queries.
Another possibility would be to have:
<observables>
    <elem>
      <name>   </name>
      <val>    </val>
      <err>    </err>
      <physical>
         <MeV_Power>P</MeV_Power>
      </physical>
      <glossary>  </glossary>
    </elem>
</observables>
where we assume that P is an integer and all physical possibilities are
measured in
units of  $MeV^P$. For Lattice Units one could have P=0 or have <physical>
be absent. This encoding is unambiguos but is MeV the most convenient unit
(as opposed to
say GeV)
(( B.Joo, 2005 Nov 21))

As already pointed out by Dirk, lattice spacing is potentially very
dangerous
because it depends on a choise of physical quantiy we take as input (r0,r1,
m_rho etc). Moreover, lattice spacing isn't even a property of ensemble:
we often define lattice spacing from physical quantities at the chiral
limit.
I propose we restrict observables to be dimension-less quantites (r0a, r1a
m_pi/m_rho, m_pi a, m_rho a, etc) which are property of ensemble.
(( T.Yoshie, 2005, Nov 22))