================================================================== U-1) Format of Logical file name ================================================================== lfn:/// I'm sure next is correct. lfn://CP-PACS/RCNF2/RC24x48-B2100K013820C1470-C-01265 CMM:Yes. I believe so. BJ: Wearing my middleware hat, I suppose I would prefer: lfn://JLDG/CP-PACS/RCNF2/RC24x48-B2100K013820C1470-C-01265 To be more clear, in the middleware WG, by collaboration we really mean National Collaboration. Perhaps Dirk defined it better as the name of the National ILDG Grid. (The entity that will run the metadata catalogue and replica catalogue). Will there be other ILDG entities in Japan? Will CP-PACS, KEK, JLQCD all run separate metadata or replica catalogue? In this case what Tomoteru suggests is just fine. If instead all Japanese collaborations will use one MDC and RC run on top of JLDG, then I would prefer the variant I suggest. TY: Now I clearly understand what "collaboration" means. Japan is going to operate only one MDC. So we will use lfn://JLDG/CP-PACS/RCNF2/RC24x48-B2100K013820C1470-C-01265 ================================================================== U-2) Format of markovChainURI ================================================================== http://www.lqcd.org/ildg// ^^^^^^^^^^^^^^^^^^^^^^^^^ This part is fixed. http:// required. I suppose next is correct, because I follow Chirs's examples http://www.lqcd.org/ildg/CP-PACS/RCNF2/RC24x48-B2100K013820C1470 CMM:Yes. We have the whole namespace from http://www.lqcd.org/ildg to use, and if we then add the collaboration name, each collaboration has complete control over the name for the ensemble. DP: I think we should drop the protocol. Otherwise, it would not be clear to me why using 'http'. For the communication with the MDC front-ends http will probably be the standard protocol independently of what protocol is specified in the URI. TY: I suppose Chris added "http://" following the way we do for namespaces. ("http://" has no meaning for namespaces.) Why do we add http://www.lqcd.org/ildg/ at the top of markovChainURI? For dataLFN, middleware WG mandates the format lfn:/// Shall we follow the same strategy? I mean, e.g. mc:/// An example is mc://JLDG/CP-PACS/RCNF2/RC24x48-B2100K013820C1470 BJ (12/12/05): I agree with Tomoteru, and was about to post, but he got ahead of me. I put forward the not untypical use case that one may need to look up an MDC based on a markovChainURI (eg find the configurations belonging to ensemble with MarkovChainURI ) In this case the client needs to know which MDC to contact. The service part of the URI could serve the same index role as it does for LFNs. In essence the markovChainURI is a special LFN with no data associated with it in a replica catalogue. I would even go as far as to make the prodocol lfn:// instead of mc:// although I am willing to give way on this last part if people disagree. The MDC middleware essentially treats the markovChainURI as a LFN. DP (12/12/05: I prefer Tomoteru's proposal adopting the structure for markovChainURI and dataLFN and define a scheme 'mc'. (I do not like using 'lfn' here, because there will be no catalogue which translates the logical into a physical file name.) To confuse future misunderstandings, we should maybe adopt the language used in RFC 3986 which defines URIs: URI = scheme :// authority / path In our case we would have scheme="mdc", authority=, path= (the latter will typically translate into path=/). TY (13/12/05): Summary markovChainURI is a URI with the structure mc:/// The should be the same as the of dataLFN: lfn:/// ================================================================== U-3) Format of algorithm glossary ================================================================== This is collab dependent. glossary is a link to xml, text etc. The following two snippets are correct. CP-PACS-HMC www.ccs.tsukuba.ac.jp/ILDG/CP-PACS/CP-PACS-HMC.xml ^^^^ CP-PACS-HMC www.ccs.tsukuba.ac.jp/ILDG/CP-PACS/CP-PACS-HMC.text ^^^^ For glossary, we omit http:// CMM: Sorry, that was me being lazy, I omitted the protocol, but only because it doesn't resolve to a file. I am assuming one would in general want to access the file by http, but it really it doesn't matter. The glossary documents will not be dealt with by any API so really the type is not anyURI, but anyType as far as the schema goes. For ease of use by people, I guess it should be a url, (including protocol) BJ: To be clear this is a URL or URI. Should this be an address I can present to a browser to initiate a download, or is it just a URI which I can present to my XML database ? DP: I think this should be a URL, i.e. adding the protocol here would make sense. But assuming http as default would be fine with me. TY: I also agree that this should be a URL with protocol. Then a valid example is CP-PACS-HMC http://www.ccs.tsukuba.ac.jp/ILDG/CP-PACS/CP-PACS-HMC.text Because algorithm is dependent of ILDG collaboration, we don't have to put glossary files on www.lqcd.org/ildg. Instead I propose that each collaboration prepares its own place and puts its glossaries there. Also, I propose each collaboration can choose format of glossary files, e.g. text, pdf, xml.. DP: I propose to restrict the choice to a set of commonly used data formats: txt, ps, pdf, xml, tex TY (13/12/05): Summary Because algorithms are dependent of collaborations, MDWG does not prepare default glossary files. Each collaboration is requested to prepare a glossary file using one of formats txt, ps, pdf, xml, tex, put it at some URL and marks it up as XXX-HMC http://..... http:// is recommended but not mandated. File types have to be one of txt, ps, pdf, xml, tex. We do not mandate particular file names. Each collaboration takes care of persistency of the URL. When the URL is changed, each collaboration will rewrite ensemble XML IDs. ================================================================== U-4) Format of action glossary ================================================================== This is the most ambiguities for me. I think action glossary document is common to all collaborations. So we have to write. Then, we have to decide where we put glossaries. (Let me know if you think action glossary is collab dependent.) An example from UKQCD schema 1.1 page www.lqcd.org/ildg/plaquetteGluonAction.xml looks strange. www.lqcd.org/ildg/Glossary/plaquette.... is better. Are we going to use XML or Text or HTML ....? We have to fix this point, before we write final version of ID. CMM: We can decide anything we like. As its supposed to be read, why not pdf? That way we can format Maths most easily? BJ: Could I recomment: www.lqcd.org/ildg/actionGlossaries/ While at the Jlab, I can undertake to put any glossary document up on the ILDG web page. However, the top-level space of www.lqcd.org/ildg will get cluttered quickly if we don't put in a few directories. Already there are i) fileformat schema documents i)) service description format and instance file iii) the web pages for the ILDG Wiki. I would potentially also consider www.lqcd.org/ildg/MDCSchemas/v/.xsd DP: It seems we are about to revive an old discussion. Please see qcdml-321 (April 30, 2004): D-1. Are glossary documents dependent of groups? ------------------------------------------------------------------ (yoshie,Apr13) I think everyone agree that glossary documents are group dependent and that MDWG proposes a guideline later. ... ((Concluded,May07)) See QCDML0.4 glossary is a URI to a documentation provided by contributors But like for the algorithm glossary files, I think it should be an URL (ie. not an URI). To ensure the URL being persistent it might nevertheless be good to foresee the documents being stored at www.lqcd.org/ildg. But of course this depends on whether the hosting institution is willing to provide this service. TY: I remember we have once agreed that glossary documents are dependent of groups. http://www.rccp.tsukuba.ac.jp/ILDG/QCDML0.40/ I propose we reconsider this issue. Meaning of lattice actions (and also observables) has to be common to all collaborations. So why not we (metadata working group) write glossary documents and put them on www.lqcd.org/ildg? I propse http://www.lqcd.org/ildg/actionGlossaries/npCloverQuarkAction.pdf ..... Namely, 1) protocol "http:" is required 2) glossary file type is pdf 3) file name should agree the name of action element (npCloverQuarkAction in this case) DP: We should not confuse documentation and glossary files. All missing (human readable) information to make the definition of the actions in the schema exact should go into the documentation. The documentation will be posted on the ILDG web site, i.e. no additional reference necessary (the definition is not supposed to be changed, i.e. it does not depend on the revision of the schema). The glossaries were introduced to provide the physics collaborations with a mechanism to provide extra information. A typical use case (also discussed at the time of introducing the glossary files) might be information on the choise of coefficients. Also in case of actions with non-perturbatively determined coefficients the value is not unique as different methods will typically give different results (either because of statistics or systematic higher order effects). Having said this, I would nevertheless propose to prepare default/prototype glossary files. The path proposed by Balint/Tomoteru is fine with me. Concerning the pratical issues: 1) The value of should be a URL (where scheme typically will be but not does not have to be http) 2) I propose to allow contributors to choose from a set of data formats: txt, ps, pdf, xml, tex 3) Since the value is a URL, we do not have to mandate any particular file name. 4) I would like to raise again the issue of persistency: as names and/or the corresponding internet domain names did change in recent years it might be better to foresee a central repository. TY (13/12/05): I thank you, Dirk, for your explanation recalling us to our strategy. I supposed some of you thought that action glossaries had to be written by us. I withdraw my proposal to reconsider this issue. What we (MDWG) have to prepare is documentation and/or sample (default) glossary files. Each collaboration will prepare its own glossary files which includes additional information e.g. how non-perturbative csw is determined. Then, Summary MDWG will prepare default glossary files and put them on http://www.lqcd.org/ildg/actionGlossaries/. Glossary file type is pdf (do you agree we use pdf?) and file name agrees with the name of action. Therefore the following snippet of instance document is correct. http://www.lqcd.org/ildg/actionGlossaries/zzzzzzAction.pdf ..... When each collaboration adds supplementary information, the collaboration writes its own glossary file and put it at some URL, and marks it up as http://www....... ..... http:// is recommended but not mandated. File types have to be one of txt, ps, pdf, xml, tex. We do not mandate particular file names. Each collaboration takes care of persistency of the URL. When the URL is changed, each collaboration will rewrite ensemble XML IDs.