[Obscore1.1] update of the PR document following RFC Comments

[Markus Demleitner]

Mireille,

On Sat, Jul 09, 2016 at 08:51:23PM +0200, Mireille Louys wrote:
> Please find here the updated version of the PR document for Obscore DM
> version 1.1 with revision tags for easy reading .
> Comments from the review process , including comments on the RFC page as
> well those from the list have been taken into account.
> Thanks for checking this in this new version of the document .

Going through the changes here's another three little issues:

(1) p. 16 s_region has "Region covered as specified in STC or ADQL", and
I'm profoundly unhappy with that.  "or" is always an alarming word in
specs, and in this case it's particular insiduous, as the STC Rec
doesn't specify a serialisation (STC-S does, but that's not a Rec),
and ADQL suggests a serialisation that nobody ever took up and that's
different from both what TAP 1.0 and TAP 1.1 suggest.

Can't we just say "Sky region covered by the  data product (ICRS
frame)"?  [and if this were earlier in the spec process, I'd say we
should leave the type of s_regoin empty, but it probably does not
matter).

(2) in sect. 5, you say the TAP capability has

  @standardID="ivo://ivoa.net/std/TAP"

and allow later versions (which is fine).  However, in 4.12, there's
new text saying "The query response should use the current
specification defined in the TAP version used for distributing the
ObsCore TAP Schema (TAP 1.1 and up)." -- frankly, I'm not entirely
sure what this sentence is intended to say (both in general and here,
where we're talking about s_region), but it seems to imply you need
at least TAP 1.1 to have Obscore 1.1.  This is in conflict with the
above language on standardID (which in effect implies TAP 1.0 is ok),
and I don't think there's a strong reason to require TAP 1.1, is
there?

Hence, I'd propose to strike (at least) the "(TAP 1.1 and up)" from
sect. 4.12.  For the rest of the new sentence, I'm not sure.

(3) I don't like much the sentence "The ObsCore data model will be
registered using this identifier in the StandardsRegExt (standards
registry extension) definition." -- "will be" in standards is even
more alarming to me than "or".

Given we have all these ivoids around, pushing a registry record per
standard should really be a standard action.  And it's easy, too --
see http://wiki.ivoa.net/twiki/bin/view/IVOA/WriteAStandardsRecord
(yes, I'm looking at all you standard authors whose standads aren't
registered yet).

So, can we just strike this sentence?  To make this deal a bit
sweeter, I'm attaching a StandardsRegExt record of Obscore that you
can send to ivoa-rofr at cfa.harvard.edu when the thing is REC;
just fix the dates when you know them, and perhaps add a few subject
keywords.

Thanks,

          Markus
-------------- next part --------------
<!-- initially, set created and updated to (roughly) UTC of now.
change updated whenever you re-upload this record. -->
<ri:Resource 
	xsi:type="vstd:Standard" 
	created="2016-07-09T08:00:00Z" 
	updated="2016-07-09T08:00:00Z" 
	status="active"
	xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0" 
	xmlns:vstd="http://www.ivoa.net/xml/StandardsRegExt/v1.0" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xmlns:ri="http://www.ivoa.net/xml/RegistryInterface/v1.0"
	xsi:schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0
		http://www.ivoa.net/xml/VOResource/v1.0
	http://www.ivoa.net/xml/StandardsRegExt/v1.0
		http://www.ivoa.net/xml/StandardsRegExt/v1.0
	http://www.ivoa.net/xml/VOResource/v1.0
		http://www.ivoa.net/xml/VOResource/v1.0">

  <title>Observation Data Model Core Components
		and its Implementation in the Table Access</title>
  <identifier>ivo://ivoa.net/std/obscore</identifier> 
  <curation>
    <publisher>IVOA</publisher>

    <creator>
      <name>Louys, M.</name>
    </creator>
    <creator>
      <name>Tody, D.</name>
    </creator>
    <creator>
      <name>Dowler, P.</name>
    </creator>
    <creator>
      <name>Durand, D.</name>
    </creator>
    <creator>
      <name>Michel, L.</name>
    </creator>
    <creator>
      <name>Bonnarel, F.</name>
    </creator>
    <creator>
      <name>Micol, A.</name>
    </creator>

		<!-- this should be the date of the last recommendation -->
    <date role="update">2016-07-09</date>
    <version>1.1</version> <!-- the document version -->
    <contact>
      <name>IVOA Data Model Working Group</name>
      <email>dm at ivoa.net</email>
    </contact>
  </curation>
  <content>
    <subject>Virtual observatory</subject>
    <!-- you can give further keywords, one per subject element;
    use the IVOA thesaurus if possible:

    http://www.ivoa.net/rdf/Vocabularies/vocabularies-20091007/IVOAT/IVOAT.html
    -->

    <description>
    	This document defines the core components of the Observation data model
    	that are necessary to perform data discovery when querying data centers
    	for astronomical observations of interest. It exposes use-cases to be
    	carried out, explains the model and provides guidelines for its
    	implementation as a data access service based on the Table Access
    	Protocol (TAP). It aims at providing a simple model easy to understand
    	and to implement by data providers that wish to publish their data into
    	the Virtual Observatory. This interface integrates data modeling and data
    	access aspects in a single service and is named ObsTAP. It will be
    	referenced as such in the IVOA registries. There will be a separate
    	document to cover the full Observation data model. In this document, the
    	Observation Data Model Core Components (ObsCoreDM) defines the core
    	components of queryable metadata required for global discovery of
    	observational data. It is meant to allow a single query to be posed to
    	TAP services at multiple sites to perform global data discovery without
    	having to understand the details of the services present at each site. It
    	defines a minimal set of basic metadata and thus allows for a reasonable
    	cost of implementation by data providers. The combination of the
    	ObsCoreDM with TAP is referred to as an ObsTAP service. As with most of
    	the VO Data Models, ObsCoreDM makes use of STC, Utypes, Units and UCDs.
    	The ObsCoreDM can be serialized as a VOTable. ObsCoreDM can make
    	reference to more complete data models such as Characterisation DM,
    	Spectrum DM or Simple Spectral Line Data Model (SSLDM).
    </description>
    <referenceURL>http://ivoa.net/documents/ObsCore/</referenceURL>
    <type>Other</type>
  	<contentLevel>Research</contentLevel>
  </content>

  <endorsedVersion status="rec">1.1</endorsedVersion>

	<key>
		<name>core-1.1</name>
		<description>The TAP/ADQL table schema in version 1.1
		</description>
	</key>

</ri:Resource>