Report from Metadata Working Group

1. Report from Metadata Working Group • 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 ILDG7 (Dec.08,2005) T.Yoshie for MDWG CCS,Tsukuba

2. management archiveHistory revisions elem elem elem revision revisionAction numberConfigs Management of QCDml1.1 • strategy of QCDml1.1 • we record all events of “addition/removal of configurations” to/from the ensemble, using management part of IDs. • <revisions>: total number of revisions • <revision>: sequential number (=<revision> in config XML) • <revisionAction>: add/remove of configurations • <numberConfigs>: #config processed in this revision • <elem> 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 archiveHistory revisions elem elem elem Management: solution (1) • ensemble XML • <revisions> and all <elem>’s in <archiveHistory>are optional numberConfigs revision revisionAction • when one records optional archiveHistory elem’s: <revisionAction> 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 <numberConfs> is removed, i.e. add/remove of configs to/from an ensemble is not recorded in the ensemble XML ID.

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

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

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

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

10. QCDml1.2.0 release major/minor version 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 • 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. • mails are archived at http://www.ccs.tsukuba.ac.jp/ILDG/QCDML-MA/