old means item number in reviewed No. 11 doc new means item number in new draft >---007-------------------------------------------------------------------------- >(TimCornwell) >- I think that the distinction between science and technical >archives is not worth making, and would probably lead to problems. related to 118, 145, In the original No. 11 document, the technical data seems to be only in the header of (observational) data. The draft authors thought that we must store the technical data both during observation and when telescope has no observation. OK, let us use "observational data" and "technical data" rather than two functionality of the archive, because it may be misleading. >---009-------------------------------------------------------------------------- >(WimBrouw) > Comments on Pipeline part of ALMA SSR and Use cases -- version 4 > >Question (in principle for Use cases): will the measured WVR be archived? If >not, calibration based on WVR should not be included in off-line package. see old3.7.2-R3=new3.7.2-R3 >---117-------------------------------------------------------------------------- >(JoeSchwarz) >p. 40, Section 3.7 in general > >It is likely to be very difficult to construct a satisfactory (User-) Archive >without more information about its intended use. It seems to me that statements >like "all data taken by the array is archived" are somewhat irresponsible. >Certainly, we don't want to lose anything important, but this shouldn't be >used as an excuse to not think about what should be in and what should be >left out. It's not just that storage space is wasted, but that packing the >Archive with data that's not needed makes it more difficult to manage and >organize the data that *is* needed. related to 119, 122, 155, 156 comment 155 is accepted >---118-------------------------------------------------------------------------- >(JoeSchwarz) >p. 40, 7.1-R2 The distinction between "observational" and "technical" archives >is never exploited and is often blurred (scripts, for example, seem to be >included in both). What is needed is specification of what uses will be made >of what kind of data. Then the Archive designers can decide where best to >put it to facilitate these uses. related to 009, 145 see reply to 009 >---119-------------------------------------------------------------------------- >(JoeSchwarz) >p. 40, 7.2-R2 "The observational archive shall also include as header data... >technical data..." So, again, why have we defined a "technical" archive that >is to hold "all technical data"? related to 122, 155, 156 comment 155 is accepted >---120-------------------------------------------------------------------------- >(JoeSchwarz) >p. 40, 7.2-R5 "...extract the database information for efficient data search >from the header..." What does this mean? That certain information should be >indexed? Why not specify what kind of performance is desired (i.e., what >"efficient data search" means) and let the Archive designers worry about how >to get it. related to 129,134 see replay to 134 >---121-------------------------------------------------------------------------- >(JohnBenson) >p.40 >7.0-R1 I think you should also archive the calibrated/flagged data > from the pipeline. This is probably what the observers will > want distributed to them anyway.. We guess 7.0-R1 should read 7.2-R1. Is "images produced by the pipeline" not OK? The pipeline has automated flagging (From old3.6.2-R3). >---122-------------------------------------------------------------------------- >(JohnBenson) >p. 40 >7.0-R2 In order for dynamic scheduling and automated pipeline > processing to work, the system needs to have a quantitative, > parameterized description of the observers scientific goals. > Things like sensitivity limits, image fidelity requirements, > maybe spectral range and resolution in km/sec... related to 119, 155, 156 We guess 7.0-R2 should read 7.2-R2. We think these are in the first item "all user (observer) input". comment 155 is accepted >---123-------------------------------------------------------------------------- >(MasatoshiOhishi) >p. 40 3.7.2 Observational Archive >In 7.2-R2, item 4, wrong reference to 1.3-R2 ? It might refer to >2.3-R2 in page 17. It refers to old3.7.3-R2, thanks. However, the revision made this reference unnecessary... >---124-------------------------------------------------------------------------- >(PrebenGrosbol) >p.40 7.2-R1 > '... shall include raw data, header information, ...' All these > items should be in the archive but I was missing things like > catalogs of line data or calibration sources. Where are they > going to be? related to 184 accepted (new3.7.2-R2) >---125-------------------------------------------------------------------------- >(TadafumiTakata) >p40 7.1-R1 >Comment > Archive system should enable astronomers and engineers to know the status >of data handling. It is like "supervisor of data handling". >On managing side, it is very useful to know where the data is at that time >such as in the way of pipeline processing, archiving, or in the way to >RSC or so, especially in the trouble around data handling. >The most important role of archive system is let users know everything >about all data. >In the distributed database environment such as ALMA, which has several >copies of database in each RSC and so on, tracing the problem in data >handling is very complicated work and this supervisoring function >(like FEDEX managing system,,,,) may be useful in various sites of >ALMA. >On user side, such as astronomer(observer and/or support astronomer, >observation operator) may want to know the status of their observational >data such as what step their data are in pipeline processing and so on. >For astronomical requirement, the trace of dataset processing may be >better for users. partially accepted will show the data list, when requested. The pipeline status will not be necessary for ALMA archive, because the archive user's concern is just whether the data is ready for reduction or not. >---126-------------------------------------------------------------------------- >(TadafumiTakata) >p40 7.2-R4 >Comment > The submission of offline reduced data by users should be performed >using user-friendly GUI and submission process should have the function >to make a link from submitted data to the original raw data or dataset >for effective use of these data by archive users or so. GUI described in old3.7.4-R1=new3.7.3-R1 will guarantee the first point. The latter part is accepted >---127-------------------------------------------------------------------------- >(TimCornwell) >Page 40, 7.2-R2 > >Throughout this section, the phrase "header information" is used. This >seems to indicate to me that every item retrieved must have the >extensive information attached. In the first sentence here, I'd just >remove "as header data". accepted >---128-------------------------------------------------------------------------- >(TimCornwell) >Page 40, 7.2-R3 > >I cannot think of any reason why one would want to let the user make an >irreversible choice like this. I'd remove the last sentence "This may be >overridden.". accepted >---129-------------------------------------------------------------------------- >(TimCornwell) >Page 40, 7.2-R5 > >I have no idea what this means! see reply to 134 >---130-------------------------------------------------------------------------- >(WimBrouw) >p40 >3.7.1: I would suggest to have the VO requirements R1 and R3 (7.5) in the > introduction. They are essential requirements from the science point of > view related to 185 We think that VO related items should be located in a subsession, because it treats some specific function. >---131-------------------------------------------------------------------------- >(WimBrouw) >p40 >7.1-R2.1 : add: Access and interface to the two archives should be compatible see reply to 007, 167 > R2.2 : add: Searching in the archive should be of O(1), or O(lnN) at > most. We think that old3.7.1-R1=new3.7.1-R1 includes this. More clearly we state this in old3.7.4-R2=new3.7.3-R3. >---132-------------------------------------------------------------------------- >(WimBrouw) >p40 >7.2-R3: I think it is wrong in principle to let the user (I suppose the > observer here) decide what should be archived. The value of an archive lies > in having information of which it is a priori unknown if it will ever be > used. Either always archive both (preferred IMO) or let the ALMA operations > at some stage decide which one will be archived from then on accepted >---133-------------------------------------------------------------------------- >(WimBrouw) >p40 >7.2-R4: This isuues raises the questions of archive management (which should > maybe be raised in use cases) and of 'super-headers' ';linking' etc. > In cases of final products and/or papers would it be advantageous to have > the headers of observations used point to these outcomes (and the outcome > of course point to the observations). Both would probably best served by > having a 'supra' or 'virtual' header describibg the sum of observations > used; and the results (with, if at all feasable a pointer from low-level to > high level (or linked-list)). Note that one observation can be part of many > super headers. > Probably this requirement is one for the introduction. This will be treated in the section of VO and interface to it. >---134-------------------------------------------------------------------------- >(WimBrouw) >p40 >7.2-R.5: Like I mentioned above, I think eficiency should be stated as a > general requirement, and not give a 'solution'. I could easily imagine that > there will be sub-headers (e.g. log or linkage to others, or because > knowledge increases) which should be searchable. Drop this one, and replace > it with: > "All information describing the observation should be accessable through the > header." > This ensures that the archive will as coherent as possible (and is also > updatable easily at a later stage). accepted >---135-------------------------------------------------------------------------- >(WimBrouw) >p40 >7.2-R6: why not: > All information shall be archived in SOC/OSF as soon as it is available in > coherent units. > This will enable headers; logs; rawdata in pieces; pipeline parts (like > individual channel images) be off-loaded as soon as possible Related to 171 >---136-------------------------------------------------------------------------- >(JoeSchwarz) >p. 41, 7.2-R8 Shouldn't this be the responsibility of the Regional Centers? >Why should there be an *additional* access point? We think that the principal archives represent those at SOC, and RSC with physical archive. Note that the recent ASAC report says that RSC might choose just a link to SOC. >---137-------------------------------------------------------------------------- >(JoeSchwarz) >p. 41, 7.2-R9 This requirement can be dropped if each Regional Center has a >full copy of the Archive. Backup of this amount of data is a *very* expensive >exercise. related to 142, 147 At any rate, we may need some kind of backup (another RSC or shadow archive or tape...) >---138-------------------------------------------------------------------------- >(JoeSchwarz) >p. 41, 7.2-R11 Who decides what the "goal" of a scan is? Can't it serve >multiple purposes? If an "expert" writes a series of low-level commands to >define his/her observing procedure, how can the system figure out what >his/her intention was? We think that it must be defined in OT, and then the info is to be stored in the archive. In case of low-level commands, how about putting them for target observation? >---139-------------------------------------------------------------------------- >(JoeSchwarz) >p. 41, 7.2-R13 If we should sometimes store images and generate >them on-the-fly at other times, then I conclude that uniformity is not a >requirement for the Alma Archive. This could pose a problem for survey- >type research (i.e., to make sure that you're getting a uniform sample, >you'd have to reprocess all the images that you want to include). Is this >really what's wanted? related to 140, 152, 153 When we have new calibration data or method, the stored image will be recalibrated (old3.7.2-R14=new3.7.2-R13.3) >---140-------------------------------------------------------------------------- >(JoeSchwarz) >p. 41, 7.2-R14.2 Does this mean that, for example, an e-mail should be sent >to anyone who has ever used the Archive every time calibration procedures >change? This sounds a little like spamming. accepted When necessary, data will be recalibrated automatically. related to 139, 152, 153 >---141-------------------------------------------------------------------------- >(JohnBenson) >p. 41 >7.0-R8 I think the archive should be accessable through web-tool > GUI's on the internet. Essentially all information in the > archive catalog tables (your header data I think) should be > accessable to any qualified user. accepetd Incorporated in the GUI section old3.7.4=new3.7.3 > Our goal with the NRAO E2E Archive is to build web-tools that > allow a user a wide set of queries, and allow selection and > FTP downloading of archived data. I think the FTP downloading > will be very popular for a substantial fraction of observing > programs. The rest will have to be distributed on some recording > media. see old3.7.4-R16=new3.7.3-R17 >---142-------------------------------------------------------------------------- >(MasatoshiOhishi) >p. 41 3.7.2 Observational Archive >In 7.2-R9, only one backup for the archive ? It would be useful to >backup the principle archive in ALL RSCs. related to 137, 147 see reply to 137 >---143-------------------------------------------------------------------------- >(PrebenGrosbol) >p.41 7.2-R13.4 > 'Image must always be archived if the pipeline cannot ...' This > requirement just re-states a special case of 7.2-R13.3. accepetd, delete this >---144-------------------------------------------------------------------------- >(PrebenGrosbol) >p.41 7.2-R14.1 > '... and provide the most up-to-date calibration.' It sounds like > only the most resent calibrations are in the archive. I would > think that all calibrations are there but you by default only get > the latest. accepetd >---145-------------------------------------------------------------------------- >(TimCornwell) >Page 41, 3.7.3 Technical archive > >The concept of a technical archive is troublesome. There are different >roles (observer, engineer, operator) that access the archive but I do >not think that this should mean that there are different archives. I >would rather see one archive that can be filled to analysis packages in >different ways: e.g. some tables to engineers, most information but >perhaps sub-sampled to analysis programs. In the AIPS++ MeasurementSet, >we have subtables for environmental data (the WEATHER subtable) in the >expectation that the observer might chose to flag all data where >WIND_VELOCITY>20m/s. Similarly the observer might wish to see the >operator log book. Hence the trend that I see is to move away from >separate archives but allow filling programs to chose to fill different >information from the archive in a context-dependent way. related to 007, 118 see reply to 007 >---146-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R7: There may be several SHADOW archives .. > > > accepted >---147-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R9: One shadow archive shall act as a backup, and be shadowed on a > continuous and complete basis > Note: the shadowing could be done through a tape or other medium, not > necssarily net. related to 137, 142 will not specify implementation (mirror or tape). >---148-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R10: does R6 not already imply this (i.e. how can you archive data if you > have no access to archive?) see reply to 171 >---149-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R11: should be 2-way. I.e. header should know what the data (or dat > piece) represents (cf R5 (either old or proposed from) ? >---150-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R12: ceratinly at the start of the ALMA observations (and even much > later) it will be completely unknown which technical/environment data > could/should be used at some (maybe future) time to improve the quality of > the reduced data. Limiting it at this stage to 'which is necessary to make > off-line analysis' and 'if not present in header' is too constricting. > Why not: > 'The archive shall provide, in the observation header, the appropriate > links to all technical data available for the observation period. This link > is in addition to the set of technical data that is provided in the header. accepted >---151-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2--R13.5: Add: On-the-fly re-imaging should be available for saved images > as well in special circumstances > > This to be able to redo bad calibration; or to compare with a newer > observation done with a different calibration scheme. We think that it is guaranteed from other requirements, isn't it? >---152-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R14: I sthis talking about calibration 'DATA' or 'PROCEDURES' or both? both > Does transparently mean that all the maps in the archive are invalidated > and/or automatically redone? >Or just a message/code to any user of a stored > map from before the change? related to 139,140,153 see reply to 139 >---153-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.2-R14.3 '... which should always use the 'standard' ...' is undefined. The > standard will be different for images that are retrieved from stored to > images done at the same time but re-imaged OTF. I suggest that if a stored > imaged that is reflagged is retrieved, it will be re-imaged always OTF. related to 139, 140, 152 see replay to 139 >---154-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.3-R1: replace 'recorded' by 'measured'. Changed the part after ',' by: Each > item shall contain a time-stamp. > The reason is that you should not prescribe the archive organisation: a > more hierarchal or other structure could be better than just a single > threaded time series. > (Even by requesting a time-stamp you request certain hardware > characteristics of the information gathering devices). accepted >---155-------------------------------------------------------------------------- >(WimBrouw) >p41 >7.3-R2: Always dangerous to give an inclusive list as requirements. At the > least say: > - all measured environmental data > - the water vapor radiometric raw data (at ~1s timescale) > - all monitored data > > I should exclude the 'derived' pathlength. This is model dependent (and > hence will vary with time), but also it is cheaper to recalculate > (processing is always faster than reading data up to quite some processing; > and it will save storage space. related to 117, 119, 122, 156 accepted >---156-------------------------------------------------------------------------- >(JoeSchwarz) >p. 42, 7.3-R3 The "high- and low-level scripts" that we're asked to save >in the Technical Archive were already saved in the Observational Archive >in 7.2-R2. This reinforces the need to be explicit about what is to be >*done* with the data, not *where* it is to go. > >Asking for the "monitor data" is pretty vague and open-ended. It would be >good to think about what's really needed here. related to 119, 122,155 e.g. the record of "go to El=45 without observation" The examples of monitor data are: - SIS bias voltage and current - Total power from IF port - temperatures inside the cryostat - PLL error voltage >---157-------------------------------------------------------------------------- >(JoeSchwarz) >p. 42, 7.3-R3 & R4 Things like electronic log books and records of manual >operations should be available in the Archive, but it should be clear that >it's not an Archival task to provide the user interfaces to enter this data. We think that it may be a task in the archiving system UI. >---158-------------------------------------------------------------------------- >(JoeSchwarz) >p. 42, 7.4-R1 says that the Archive Search Tool should be a GUI, 7.4-R2 >states that >the Data Extractor Tool should use it as a front end, 7.4-R9 says that 'the >Data Extractor Tool shall use the Search Tool'.... This is a clear >contradiction! Which tool is using which other tool, shall a programmatic >tool (Data Extractor Tool) use a GUI (the Archive Search Tool)? accepted in old3.7.4-R9=new3.7.3-R10 " the Data Extractor Tool shall receive the information from the Search Tool" >---159-------------------------------------------------------------------------- >(JoeSchwarz) >p. 42, 7.4-R5 "Two interfaces" are asked for, but the differences between >them are never described. related to 145 see reply to 007, 167 We think that we need separate interfaces for separate purposes. Difference would be obvious from the purpose. >---160-------------------------------------------------------------------------- >(JohnBenson) >p.42 >7.0-R10 You might add 'project' and 'observer' to your list of > search criteria. 'Molecular transition' is a good idea, I hadn't > thought of that one for the E2E Archive, I'll use it. We think - Project name - Name of Principal Investigator correspond to them. >---161-------------------------------------------------------------------------- >(PrebenGrosbol) >p.42 7.3-R3 > 'The archive shall record all high- and low-level scripts' It > seems not reasonable to request the archive to record scripts, > it should rather store them. It must be the Dispatcher/Sequence > which records the scripts in the archive. accepted >---162-------------------------------------------------------------------------- >(TadafumiTakata) >p42 7.4-R6 >Comment > Exspecially in technical archive, it is very important to provide >the function of data searching using any kind of keyword and header >information flexibly. (R6 may be very essential especially during >developing and first light phases.) We think that "Any other header info" corresponds to this. >---163-------------------------------------------------------------------------- >(TimCornwell) >Page 42, 7.4-R1 > >A CLI must be available to interrogate the archive from scripts. In >addition, one will also want a web service equivalent. accepted related to old3.7.4-R14=new3.7.3-R15 >---164-------------------------------------------------------------------------- >(WimBrouw) >p42 >7.3-R4: make it priority 1: especially at the start of operations the notes > can be very helpful in disentangling any problem or error. accepted >---165-------------------------------------------------------------------------- >(WimBrouw) >p42 >7.4-R2: ... searching the OBSERVATION database ... accepted >---166-------------------------------------------------------------------------- >(WimBrouw) >p42 >7.4-R4: priority 2 (make the cookbook then priority 1): use feedback to > finalise help accepted >---167-------------------------------------------------------------------------- >(WimBrouw) >p42 >7.4-R5: Do you mean: > The AST shall have two interfaces: one mainly for astronomical product > production; one mainly for technicien use (e.g. for quality monitoring and > error tracing) > > I believe that data from both archives can (and should be) used for either > astronomical and technical purposes. The interface for both purposes should > be different (certainly), not the underlying available data. accepted >---168-------------------------------------------------------------------------- >(WimBrouw) >p42 >7.4-R6: 'The search criteria shall include all the information in the > observation headers, including any information pointed to in > sub-headers. Search criteria based on combination of search fields > should be possible (e.g. time * bandwidth) They shall include (but not be > limited to) e.g.: > - your list; but: > is integration time the total or the per sample; integration per image pixel, I think > why not have a product of bandwidth and time (for continuum mostly) > there are coupled items: configuration and resolution; frequency and > resoltion, ... accepted >---169-------------------------------------------------------------------------- >(WimBrouw) >p42 >7.4-R6.1: Add: The user interface should be able to understand an SQL-type > language with expressions between fields. > (this takes also care, and should be combined with R.7) see old3.7.4-R14=new3.7.3-R15 revision >---170-------------------------------------------------------------------------- >(JoeSchwarz) >p. 43, 7.4-R8 The intent of showing "query statements" isn't clear. We don't >know what database technology we will use for the Archive; I assume the user >just wants to know what the search criteria was and be able to modify them. accepted >---171-------------------------------------------------------------------------- >(JoeSchwarz) >p. 43, 7.4-R12: This is impossible to provide for a general archive user. >We must >allow for some (possibly short) delay. The Scheduling Process and ALMA >operations must have top priority at this stage. If we still think about >something like a 'Fast Store Archive' and a separate general Archive, then >the upload of the data to the general archive will have to be asynchroneous >and might be delayed in case of peak load to the fast store. related to 135 "immediately" is replaced by "as soon as practical" >---172-------------------------------------------------------------------------- >(JoeSchwarz) >p. 43, 7.4-R13 How can a Data Extractor provide links? Or is the Data >Extractor really a GUI? Date Extractor should read Search Tool. Thanks! >---173-------------------------------------------------------------------------- >(MasatoshiOhishi) >p. 43 3.7.4 User Interface >In relation with 7.4-R13, it would be useful to have a hyperlink with >published papers e.g., ADS if available, that used the relevant data. accepted although the term "hyperlink" may be modified (see 181). >---174-------------------------------------------------------------------------- >(PrebenGrosbol) >p.43 7.4-R14 > '... request to get the file like' The requirement should be more > specific and not just give one example. Also this requirement > seems to contradict 7.4-R9 which states that the Search Tool > shall be used. see reply to 172, 182 >---175-------------------------------------------------------------------------- >(RayPlante) >p. 43, 3.7.4, 7.4-R13 >Wording seems a little funny. I think you mean that the Tool, when >displaying project/data product descriptions, should be able to >include hyperlinks that retrieve related images or catalog data from >external archives. see reply to 172 >---176-------------------------------------------------------------------------- >(RayPlante) >p. 43, 3.7.4, 7.4-R14: >I didn't quite understand what this meant. Does it mean... > a. the Tool should respond to a url-encoded HST archive search > query? (I don't think so.) > b. that the Tool accept URL-encoded search queries for retrieving > data? This implies that the tool is a web service (as opposed > to a client application that connects to the archive via the web). >Personally, I don't think it is sensible to retrieve big data products >via a search query as it's too easy for the query to return much more >data (or not enough) than you want. Instead, associate each data >product with an unique identifier, which is then retrievable via a >unique URL. Search queries can then return these URLs along with >other metadata; the Extractor (or user) can then select what data >should actually be downloaded. This is the model used with the BIMA >archive. The client application DaRT allows the user to download a >list of URLs all in one shot. see reply to 172 and 182 "search requests" added > >---177-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R10: Is meant as: 'A preview image of the image produced from the > selected data shall be made available before transfer of the final > image-cube'? yes > I think this requirement is not meant that way, but what is meant to > produce from the selected data a small image. Small in field? Integrated > over spectrum? Low resolution? Taking only every 10th datapoint? Whatever > way you do it, for it to give any indication of correctness, a full > calibration and imaging must be done. yes >Maybe it would be better to change > this to something like: > Before transmitting the selected data, an image of the distribution of the > datapoints in the Fourier domain will be transmitted (or maybe a PTF) at > some centre frequency. Preview image is to choose what should be transmitted. >---178-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R10.1: cannot be done: the data selection will not correspond with > pipeline result. Only way to do this is to add all the individual pipeline > results (will they always be scaled the same?) images based on the data > selected. If integrated over relevant velocity and pixels are small, OTF would be fast enough, we think. >---179-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R10.2: same m.m. > > > >---180-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R11: is that not inhrent in 7.2-R6? R6 is just search criteria only. >---181-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R13: replace 'hyperlink' with 'persistent link information' > (hyperlinks have the tendency to become invalid; by using more modern ideas > (e.g. XML links) this can be largely overcome: leave it to the archive > designers to come with solution) accepted >---182-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R14: should not be as such in SSR. More: > The DET should be able to accept (properly verified) web-based extraction > requests accepted >---183-------------------------------------------------------------------------- >(WimBrouw) >p43 >7.4-R15: The DET must be invokable from the Offline .. > (I suppose you do not want to limit it to Offline package only: must be > stand-alone as well (and R14)) accepted oldR14=newR15 changed >---184-------------------------------------------------------------------------- >(JoeSchwarz) >p. 44, 7.5-R2.1 I believe there was an ASAC decision to exclude source >extraction as part of the Alma project responsibility. If this is right, >what are the "ALMA Catalogues", and who will produce them? related to 124 old3.7.5-R2.1 deleted We may contain catalogues made outside the ALMA project, but can be as RSC task. >---185-------------------------------------------------------------------------- >(JoeSchwarz) >p. 44, 7.5-R3 This requirement says basically, "We don't know what the VO >requirements are, but you must meet them, and moreover as Priority 1 [when >Interim Science Ops begin]." This will be an exceptionally hard requirement >to meet. related 130 see modification >---186-------------------------------------------------------------------------- >(MasatoshiOhishi) >p. 44 3.7.5 Relationship with the VO Projects >As one of leading persons for the Japanese Virtual Observatory Project, >I would very appreciate to see this section. Important points are to >guarantee data quality including in providing its reliable information, >and to provide network-transparent interface to connect to each >VO via, for example, the globus tool kit. related to 188 >---187-------------------------------------------------------------------------- >(PrebenGrosbol) >p.44 7.4-R19 > '... secure access to proprietary data' Security is good and > needed but I would also have expected some more general > requirements on access like that all users of the archive should > be identified by user-id or something like that. accepted >---188-------------------------------------------------------------------------- >(TimCornwell) >Page 44, 3.7.5 Relationship with Virtual Observatory Projects > >There are several blank checks being signed here! There is no definition >yet of what it means to meet requirements for VO access so the project >cannot take on an obligation to support such access. I would remove this >section (I am in favor of VOs but not of signing blank checks). related to 185,186 see reply to 185 >---189-------------------------------------------------------------------------- >(WimBrouw) >p44 >7.4-R17: If an archive user requests a DISK file... in A user accessible > directory. The user will be informed about the estimated transfer time. An > email message can be requested at the end of the transfer. accepted >---190-------------------------------------------------------------------------- >(WimBrouw) >p44 >7.4-R19: is DET or AST meant her (R9 says that the DET uses the AST). Or is > it meant that login only necessary to get proprietary data? Data Extractor Tool should read Archive Search Tool. Thanks! >---191-------------------------------------------------------------------------- >(WimBrouw) >p44 >7.5-R1/R3: see earlier > > > >---192-------------------------------------------------------------------------- >(WimBrouw) >p44 >7.5-R2: Whatever ... to provide: > - ALMA catalogs (i.e. archived images) related to 124, 184 > - image quality information for archived images > - data quality information for selected observations accepted >---195-------------------------------------------------------------------------- >(WimBrouw) >p77 >4.6.2: The goal .... There are proprietary ... always available for > everyoine. > This is stated to sloppy in view of earlier comments in the archiving > part that all search information should be available in header. This > could e.g. be the max/min flux (as it should be I think), integrated > flux; SNR; binning period for variable phenomna; source list coordinates > etc which could be indicators of the astronomical results. > Maybe 'header' should be replaced by 'pre-observational header > information' or some other restriction > > 2. Does user provides all of these? some of them; as an example? > exception Course 1: PART OF requested.. accepted (in Search Archived Data UC). > Last issue mentioned (pipeline output): is already completely defined in > the requirements The modification (including above) made by K. Tatematsu and K. Nakanishi for Use Cases for archiving was not incorporated in the the new No. 11 for review, by accident in the editorial process. We incorporate all revisions (we made before review and after review) in the new draft.