Difference: PhotDM10RFC (6 vs. 7)

Revision 72012-09-05 - JesusSalgado

 

PhotDM-1.0 Proposed Recommendation: RFC period

Changed:
<
<
This document serves as the RFC center for the Proposed
>
>
This document serves as the RFC center for the Proposed
 
Changed:
<
<
Recommendation entitled "IVOA Photometry DM, Version 1.0".
>
>
Recommendation entitled "IVOA Photometry DM, Version 1.0".
 
Deleted:
<
<
 The latest version of PhotDM:
Changed:
<
<
>
>
Deleted:
<
<
 Discussion page is at:
Changed:
<
<
>
>
Deleted:
<
<
 where some auxiliary documents can be found.

Reference Interoperable Implementations

Changed:
<
<
  • VOSpec (ESAVO) (client)
  • Filter Profile Service (SVO) (Server + Client)
  • Catalogs with Photometry Data (CDS) (Server)
>
>
  • VOSpec (ESAVO) (client)
  • Filter Profile Service (SVO) (Server + Client)
  • Catalogs with Photometry Data (CDS) (Server)
 
Changed:
<
<

RFC Review Period: 05 June 2012 - 05 July 2012 (open)

>
>

RFC Review Period: 05 June 2012 - 05 July 2012 (closed)

 

TCG Review Period: 05 July 2012 - 05 September 2012

Changed:
<
<


>
>


 

Comments from the IVOA Community during RFC period: 05 June 2012 - 05 July 2012

Changed:
<
<


>
>


 

Comments from TCG member during the TCG Review Period: 05 July 2012 - 05 September 2012

Deleted:
<
<
 WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

Changed:
<
<

TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)

>
>

TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet)

 
Changed:
<
<

Applications Working Group (Mark Taylor)

>
>

Applications Working Group ( _Mark Taylor)

  As Gretchen points out, there are some questions raised by Appendix C.2. TAP services to be marked up in such a way should I think use the TAPRegExt <dataModel> element, but I'm not sure about Cone Search.

The response curve in the example table in Appendix C.1 seems to have all its transmission values as zero - is that a mistake?

Given consideration of those points, I approve.

Changed:
<
<
-- MarkTaylor - 05 Jul 2012
>
>
-- MarkTaylor - 05 Jul 2012
 
Changed:
<
<

Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick))

>
>
Agree with first point. Tap services could make use of the datamodel element. As commented in the registry section, details on how to register cone search services can be considered out of the scope of the DM itself, so they should be discussed in another context.
 
Changed:
<
<

Data Model Working Group (Jesus Salgado, Omar Laurino)

>
>
About second point, unfortunately the example has been taken from a real example and cut to minimize the size (the first element are zero). The example will be modified to get transmission numbers different than zero.
 
Changed:
<
<

Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff)

>
>
JesusSalgado - September 5, 2012
Added:
>
>

Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick))

 
Changed:
<
<

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

>
>

Data Model Working Group ( _Jesus Salgado, Omar Laurino)

 
Changed:
<
<
Appendix C.2 describes using a new capability type for Cone Search, i.e. Photometry. This is confusing to me, in the sense that the capability is more what we would refer to as the standard functional capability, e.g. cone, sia, ssa, sla, tap, etc. It is an interesting concept you are defining, i.e. how to describe data model implementation contained in a specifc service capability. I'm looking further to try to understand this in the context of registry schema. Currently i do not see the metadata mapping which would demonstrate how this would comply. Perhaps you had a specific example to explain further?
>
>

Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff)

 
Added:
>
>

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

Appendix C.2 describes using a new capability type for Cone Search, i.e. Photometry. This is confusing to me, in the sense that the capability is more what we would refer to as the standard functional capability, e.g. cone, sia, ssa, sla, tap, etc. It is an interesting concept you are defining, i.e. how to describe data model implementation contained in a specifc service capability. I'm looking further to try to understand this in the context of registry schema. Currently i do not see the metadata mapping which would demonstrate how this would comply. Perhaps you had a specific example to explain further?

 GretchenGreene - July 3, 2012
Changed:
<
<

Semantics Working Group (Sebastien Derriere, Norman Gray)

>
>
This was a proposal done, mainly, by our CDS colleagues in order to publish future Cone Searches with the extra metadata information. I agree this should be more discussed in the registry context and, as mentioned, the services should be registered using a standard registry extension (e.g. TAPRegExt for tap services). As this is out of the scope of the DM itself, I will remove some details on how to register these services. This could be added to the related IVOA note in coordination with the Registry group
 
Changed:
<
<

VOEvent Working Group (Matthew Graham, John Swinbank)

>
>
JesusSalgado - September 5, 2012
Added:
>
>

Semantics Working Group ( _Sebastien Derriere, Norman Gray)

 
Changed:
<
<

Data Curation & Preservation Interest Group (Alberto Accomazzi)

>
>

VOEvent Working Group ( _Matthew Graham, John Swinbank)

 
Changed:
<
<

Knowledge Discovery in Databases Interest Group (Giuseppe Longo)

>
>

Data Curation & Preservation Interest Group ( Alberto Accomazzi)

 
Changed:
<
<

Theory Interest Group (Herve Wozniak, Franck Le Petit)

>
>

Knowledge Discovery in Databases Interest Group ( Giuseppe Longo)

 
Changed:
<
<

Standards and Processes Committee (Francoise Genova)

>
>

Theory Interest Group ( _Herve Wozniak, Franck Le Petit)

 
Added:
>
>

Standards and Processes Committee ( Francoise Genova)

 
Changed:
<
<

>
>

 
Changed:
<
<

Deleted:
<
<
 
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback