<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The dataproduct_type allowed values in EPNcore are (at the moment, and it may change by new additions, we are currently assessing this):<div class="">- image: object depending on 2 spatial dimensions </div><div class="">- spectrum: object depending on 1 spectral dimension </div><div class="">- timeseries: object depending on 1 temporal dimension</div><div class="">- catalog: list of object not depending on a specific dimension </div><div class="">- spectral cube: object depending on 1 spectral and 2 spatial dimensions </div><div class="">- dynamic spectrum: object depending on 1 spectral and 1 temporal</div><div class="">- profile: object depending on 1 spatial dimension</div><div class="">- cube: object depending on several dimensions (generic)</div><div class="">- movie: object depending on 1 temporal and 2 spatial dimensions</div><div class="">- volume: object depending on 3 spatial dimensions</div><div class="">- spatial_vector: sparse object depending on 2 or 3 spatial dimensions (not sure now what we meant, for this one :-)</div><div class=""><br class=""></div><div class="">The mentioned dimension dependences are those that are considered as primary dimensions by the provider. It is usually the dimensions of the sampling axes, but not necessarily. This can be used to define how interoperable tools will treat the data. </div><div class=""><br class=""></div><div class="">So to add my contribution to this discussion, I would vote for "catalog" rather than "sourcelist", which seems too specific to me. In our EPN-TAP services we already have a few ones with dataproduct_type = "catalog" :</div><div class="">- The <a href="http://exoplanet.eu" class="">exoplanet.eu</a> catalog</div><div class="">- The HELIO Feature Catalog of Active Regions</div><div class=""><div class="">- The HELIO Feature Catalog of Coronal Holes</div><div class=""><div class="">- The HELIO Feature Catalog of Solar Radio Bursts</div></div><div class="">- The NASA Dust Samples Catalog</div><div class="">- The Main characteristics of solar system planets</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Baptiste</div><div class=""><br class=""></div><div class=""></div><div class=""> <br class=""><div><blockquote type="cite" class=""><div class="">Le 11 mai 2016 à 16:02, Laurent MICHEL <<a href="mailto:laurent.michel@astro.unistra.fr" class="">laurent.michel@astro.unistra.fr</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">Hello Dough,<br class=""><br class="">Le 09/05/2016 01:19, Douglas Tody a écrit :<br class=""><blockquote type="cite" class="">These are good points. Note, dataproduct_type is coarse grain, e.g.,<br class="">at this level we say just "image" not what type of image. "Catalog"<br class="">as I suggested earlier is also too fine grained. So if we add support<br class="">for table data the value for dataproduct_type should be "table".<br class=""></blockquote><br class="">To me, "table" is too coarse. Event lists or time series can be seen as tables either. The word we are looking for is related to tables containing sky objects related to one observation. According to this i continue to support the "sourcelist" option.<br class=""><br class="">Laurent<br class=""><br class=""><blockquote type="cite" class="">While not a mandatory parameter, dataproduct_subtype would be perfect<br class="">for specifying the data-provider defined type of the table, e.g.,<br class="">"sourcelist" or "catalog" (this is intentionally not a controlled<br class="">vocabulary, rather it is site or domain specific, controlled by the<br class="">user). A UCD might be useful for specifying the table type as well,<br class="">although this is perhaps beyond the scope of a UCD since it is not<br class="">a quantity. - Doug<br class=""><br class=""><br class="">On Wed, 20 Apr 2016, Laurent Michel wrote:<br class=""><br class=""><blockquote type="cite" class="">Hello,<br class=""><br class=""><br class="">I'm likely guided by my experience with XMM data but this is a<br class="">valuable use case anyway.<br class="">The data bulk released with one XMM observation contains various data<br class="">types. To make it simple, we can find there event lists, images,<br class="">spectra, time series and source lists possibly in various formats<br class="">(FITS, PDF..)<br class="">All these data sets can take place in an Obscore table except the<br class="">source list. This exception has no justification since the source list<br class="">is a scientific product issued from the processing of a particular<br class="">observation. There is even one stronger reason for pushing the source<br class="">lists in Obscore which is that source level products (e.g. time<br class="">series, spectra) are attached to individual detections which are<br class="">nothing else than source list rows. So hiding the source list would<br class="">limit the possibilities of the data discovery.<br class="">I guess that this point of view can easily be extended to other<br class="">missions of instruments.<br class=""><br class="">Moreover, for catalogues which are table compilations (e.g. XMM<br class="">catalogue) or large sky coverage surveys (e.g. 2MASS), most of the<br class="">characterisation axes parameters are not relevant. So Obscore<br class="">description does not bring much. The Dataset DM or the source DM are<br class="">better suited for his kind of datasets.<br class=""><br class="">The right position of the cursor between publishing or not a table in<br class="">Obscore is left to the appreciation of the data publisher.<br class="">But an appropriate vocabulary may help for this.<br class=""><br class="">As far as vocabulary is concerned, I would prefer to speak about a<br class="">'source list' instead of a 'catalogue' which is too generic for a list<br class="">of sources extracted from one specific observation.<br class=""><br class="">Assuming that most of the Obscore axe values can be set from the<br class="">parameters of the related observation, I suggest to allow<br class="">dataproduct_type='sourcelist' in Obscore1.1.<br class=""><br class=""><br class="">Laurent<br class=""><br class="">Le 15/04/2016 19:45, Douglas Tody a écrit :<br class=""><blockquote type="cite" class="">I have always thought that ObsCore should include "catalog" as a<br class="">dataproduct type. This was opposed in the first version due to a desire<br class="">by the Exec to keep things as simple as possible, but I do not think it<br class="">would have complicated things or delayed the release.<br class=""><br class="">A catalog is a valid data product with calib_level 3 or higher. It is<br class="">not that much different than some other high level, derived data<br class="">products such as a dither stack. These higher level data products are<br class="">often the data products one most wants to find for analysis.<br class=""><br class="">While many catalogs are derived from multiple observations or even<br class="">collections, it is possible for example to perform object detection on a<br class="">single observation, and include the result in the set of data products<br class="">published for the observation, all sharing the same obs_id. Catalogs<br class="">can even have valid metadata giving the spatial, spectral, and time<br class="">coverage for the catalog. So, +1 for me too. - Doug<br class=""><br class=""><br class="">On Fri, 15 Apr 2016, Patrick Dowler wrote:<br class=""><br class=""><blockquote type="cite" class="">Guilty as charged :-)<br class=""><br class="">Our underlying data model (CAOM2) has catalog as a valid type and I<br class="">recall some of us trying to get catalog into the vocabulary back<br class="">before 1.0.... I can easily fix this because ObsCore is a view on<br class="">CAOM2, with the cost being that people can't find all the products via<br class="">ObsCore. But for ASKAP, if they implement ObsCore directly then they<br class="">would be left with no way to provide discovery of catalog products.<br class=""><br class="">The DM rationale is that ObsCore is a list of products (it is a<br class="">flattened view of Observation+Product where there is a 1..* relation).<br class="">As such, there are certainly other kinds of things that can be created<br class="">from data (besides just more data). Do such things belong in ObsCore?<br class="">I obviously think they do so IMO we should add to the vocabulary and<br class="">I've either been meaning to request it or forgot about that little<br class="">non-compliance.<br class=""><br class="">The alternative that I see if that access to the catalog would be a<br class="">link in a DataLink response with semantics="derivation"... and then<br class="">probably augment the DataLink vocabulary to be able to ay catalog...<br class="">and then still not be able to discover them via a data discovery<br class="">query. DataLink *is* awesome and all, but that doesn't seem so great.<br class=""><br class="">So: can we add "catalog" to the ObsCore-1.1 vocabulary for<br class="">datapoduct_type? +1 from me<br class=""><br class=""><br class=""><br class="">On 15 April 2016 at 05:21, Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk" class="">M.B.Taylor@bristol.ac.uk</a>><br class="">wrote:<br class=""><blockquote type="cite" class="">James,<br class=""><br class="">it looks like you're not the only one to hit this. If I use the<br class="">ObsTAP service at <a href="http://www.cadc.hia.nrc.gc.ca/tap" class="">http://www.cadc.hia.nrc.gc.ca/tap</a> to run:<br class=""><br class=""> select distinct top 100<br class=""> dataproduct_type, obs_collection<br class=""> from ivoa.obscore<br class=""> where dataproduct_type not in<br class=""> ('image', 'cube', 'spectrum', 'sed',<br class=""> 'timeseries', 'visibility', 'event')<br class=""><br class="">I get<br class=""><br class=""> +------------------+----------------+<br class=""> | dataproduct_type | obs_collection |<br class=""> +------------------+----------------+<br class=""> | catalog | APASS |<br class=""> | catalog | CFHTTERAPIX |<br class=""> | catalog | JCMT |<br class=""> +------------------+----------------+<br class=""><br class="">(note this is one of the tests run by taplint, currently failing at<br class="">CADC).<br class=""><br class="">Mark<br class=""><br class="">On Fri, 15 Apr 2016, <a href="mailto:James.Dempsey@csiro.au" class="">James.Dempsey@csiro.au</a> wrote:<br class=""><br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">In ObsCore v1.0 and 1.1 the dataproduct_type field has a defined<br class="">list of values. We currently advertise our ASKAP catalogue<br class="">data products in our ObsCore table, but have to leave the<br class="">dataproduct_type field blank for these records as none of the<br class="">possible types match.<br class=""><br class="">Has the inclusion of a catalogue type been considered before? If<br class="">not, would it be possible to include in ObsCore v1.1?<br class=""><br class="">Cheers,<br class="">James Dempsey<br class=""><br class=""></blockquote><br class="">--<br class="">Mark Taylor Astronomical Programmer Physics, Bristol<br class="">University, UK<br class=""><a href="mailto:m.b.taylor@bris.ac.uk" class="">m.b.taylor@bris.ac.uk</a> +44-117-9288776<br class=""><a href="http://www.star.bris.ac.uk/~mbt/" class="">http://www.star.bris.ac.uk/~mbt/</a><br class=""></blockquote><br class=""><br class=""><br class="">--<br class="">Patrick Dowler<br class="">Canadian Astronomy Data Centre<br class="">Victoria, BC, Canada<br class=""><br class=""></blockquote></blockquote><br class="">--<br class="">jesuischarlie/Tunis/Paris/Bruxelles<br class=""><br class="">Laurent Michel<br class="">SSC XMM-Newton<br class="">Tél : +33 (0)3 68 85 24 37<br class="">Fax : +33 (0)3 )3 68 85 24 32<br class=""><a href="mailto:laurent.michel@astro.unistra.fr" class="">laurent.michel@astro.unistra.fr</a> <<a href="mailto:laurent.michel@astro.unistra.fr" class="">mailto:laurent.michel@astro.unistra.fr</a>><br class="">Université de Strasbourg <<a href="http://www.unistra.fr" class="">http://www.unistra.fr</a>><br class="">Observatoire Astronomique<br class="">11 Rue de l'Université<br class="">F - 67200 Strasbourg<br class=""><a href="http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34" class="">http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34</a><br class=""><br class=""></blockquote></blockquote><br class="">-- <br class="">---- Laurent MICHEL Tel (33 0) 3 68 85 24 37<br class=""> Observatoire de Strasbourg Fax (33 0) 3 68 85 24 32<br class=""> 11 Rue de l'Universite Mail <a href="mailto:laurent.michel@astro.unistra.fr" class="">laurent.michel@astro.unistra.fr</a><br class=""> 67000 Strasbourg (France) Web <a href="http://astro.u-strasbg.fr/~michel" class="">http://astro.u-strasbg.fr/~michel</a><br class="">---<br class=""></div></blockquote></div><br class=""></div></div></body></html>