1. Report from Metadata Working Group ILDG7 (Dec.08,2005) T.Yoshie for MDWG CCS,Tsukuba ILDG6  file format was proposed and approved  QCDml1.1 had been stable ILDG7  propose an update of QCDml improved management part of QCDml marked up new lattice actions  summary of on-going discussions observables, validity of schemata  other issues

2. Management of QCDml1.1QCDml1.1 strategy of QCDml1.1  we record all events of “addition/removal of configurations” to/from the ensemble, using management part of IDs. management revisions archiveHistory elem revisionrevisionActionnumberConfigs  : total number of revisions  : sequential number (= in config XML)  : add/remove of configurations  : #config processed in this revision  includes other info (person, date,…)

3. Management: requirements new requirements: we want to  write an ensemble XML ID when config generation starts  avoid frequent change of ID suppose we add configuration one by one. long list of archiveHistory  store ID written by users to MDC without further changes for QCDml1.1, a tool to generate archiveHistory consistently has to be developed, and the user ID has to be processed by the tool. Good properties we don’t want to change:  #configs belonging to an ensemble can be counted.  replace/remove of configs can be detected by users  modification of ID can be detected by users  a kind of time stamps is recorded change of existing IDs has to be minimal

4. Management: solution (1) ensemble XML  and all ’s in are optional management revisions archiveHistory elem revisionrevisionAction  when one records optional archiveHistory elem’s: refers to a revision of XML ID add: addition of ID to MDC, replace: replace of ID in MDC remove: remove of ID from MDC is removed, i.e. add/remove of configs to/from an ensemble is not recorded in the ensemble XML ID. numberConfigs

5. Management: solution (2) configuration XML  one in archiveHistory (generate) is mandatory  others optional management revisions archiveHistory  when optional archiveHistory elem’s are recorded add/replace/remove refer to either ID or config. elem revision=0 revisionAction = generate includes info. of person, date

6. Management: solution (3) new management parts satisfy “new requirements”. It also keeps old important properties, even if optional elements are not marked up.  write an ensemble XML ID when config generation starts  avoid frequent change of ID Yes, because coupling between ensemble IDs and config IDs was removed  ID written by a user is not changed when it is stored in MCD Yes, if one does not record archiveHistory. One may authomatically update the archiveHistory, when IDs are stoared in MDC.  #configs belonging to an ensemble can be counted. count #config IDs with markovChainURI as a key  replace/remove of configs can to be detected by users when replaced, crcCheckSum and hence config ID will be modified  modification of ID can be detected by users users have to keep copies of ensemble/config IDs  a kind of time stamps is recorded revisionAction=generate with a time stamp is mandatoy in config ID

7. Management: more improvement is proposed by MILC collab. classify ensembles lover level classification (optional) Ensembles generated by a project are usually classified by e.g. lattice spacing (coarse, fine, superfine), lattice size (small, medium, large). enables to mark up such lower-level grouping

8. Convention to mark up sixLink actions gluon plaquette sixLink iwasakiRG DBW2 LuescherWeisz tpLuescherWeisz treeLevelSymanzik plaq. rect. chair 3d  c3 was missing in QCDml1.1  we mandate c3, though redundant New action: gluon

9. quark KS overlap wilson improved KS askTad domainWall wilsonTm clover npClover tpClover Requests of marking up other actions, write to us New action: quark

10. QCDml1.2.0 modification from the old version is minor the new one is not compatible with the previous QCDml1.1  compatible: if IDs written based on the old schema are still valid under the new one. strategy to name and treat new QCDml schema release QCDml1.2.0 major/minor version  if not-compatible, count-up major/minor version number  if compatible, count-up release number. All releases (with the same version number) belongs to the same name space, e.g. QCDml1.2.x has targetNamespace="http://www.lqcd.org/ildg/QCDml/ensemble1.2"

11. On-going: observables a request to markup observables e.g. lattice spacing useful for users to search ensembles conceptually (qualitatively) different from what we have marked up.  Ensemble ID: how the ensemble was generated  Observables: properties (consequences) of the ensemble Thus, deliberate action is necessary summary of discussions up to now  Some kind of observables are not property of ensemble. E.g. Lattice spacing, if it is determined by chiral extrapolations.  Dimension-full quantities are dangerous. They depend on inputs.  Values of observables change, when more configurations are added.  what kind of observables are worth marking up. pion prop maynot be.  candidate: pi-rho ratio and sommer scale in lattice units plan to come to conclusions within a month or so.

12. Validity of Schemata current version of QCDml is not valid under W3C definition strategy to express hierarchical structure of lattice actions  action: complexType, derived action: substitution of complexType  content model of the new type has to be restriction/extension of that of the old one. Current QCDml violates this rule validation of schema does not work properly with XMLspy5 QCDml does not pass XMLspy2006 and W3C… validators. causes no serious problem for usual use of QCDml  validation of ID works correctly  Xpath(1.0) query does not refer to schemata working to write a new valid schema not completed yet, but expect required changes to be backward compatible  inheritance of actionTypes is valid (action hierarchical tree unchanged)  elements in IDs are unchanged (users don’t have to do anything)

13. Other Issues and Future Works procedure to release new schemata (almost agreed by WG)  user wants to markup his/her ensemble generated with a new action  write a request to the MDWG  a MDWG member (or the user) writes a schema for the new action and circulates it to the MDWG mail-list  the proposal of change is automatically accepted if there is no objection circulated within a certain period of time (e.g. 2 weeks)  Chris Maynard volunteers final editing of schemata  we put the new release somewhere at the ILDG web-page  and announce new schemata via ILDGNews blog of the ILDG web- page or other mail-lists write glossary for marked-up actions write human readable document or guidebook, like “How to markup QCD ensembles and configurations”

14. Summary New version of QCDml (QCDml1.2) was released  Dirk Pleiter volunteered to write this version. Discussion is on-going on whether/how we extend QCDml to include observables.  feedback of your opinions/comments are welcome Work is in progress to write schemata compatible with W3C definition  Chris Maynard is tackling this issue Mail list qcdml@ccs.tsukuba.ac.jp is closed to members only.  write to yoshie@ccs.tsukuba.ac.jp if you want your mail address be included, or you send your opinions/comments to members.yoshie@ccs.tsukuba.ac.jp  mails are archived at http://www.ccs.tsukuba.ac.jp/ILDG/QCDML-MA/http://www.ccs.tsukuba.ac.jp/ILDG/QCDML-MA/