From M.B.Taylor at bristol.ac.uk  Mon Apr  1 10:27:10 2019
From: M.B.Taylor at bristol.ac.uk (Mark Taylor)
Date: Mon, 1 Apr 2019 08:27:10 +0000
Subject: VOTable 1.4 schema inconsistencies
In-Reply-To: <DF7BECBC-0BD0-43B7-B780-586210F73B5F@stsci.edu>
References: <DF7BECBC-0BD0-43B7-B780-586210F73B5F@stsci.edu>
Message-ID: <alpine.LRH.2.21.1904010920580.2675@localhost>

Tom,

I agree with your approach of updating the diagram where possible and
leaving the schema as is.  I confess to never having looked in great
detail at these diagrams; they are kind of useful though obviously
not as rich or precise as an XSD in defining what's legal.
You mention the idea of adding a note to that effect in section 7.1;
a possibility would be to include a comment that in case of
any discrepancies between the schema and the diagram, the schema
is definitive (or equivalently to mark section 7.1 as non-normative).
I'm pretty sure this is what readers would assume anyway, but it
might avoid potential confusion to make that explicit.  But up to
you whether you think that's a good idea.

Mark

On Sun, 31 Mar 2019, Tom Donaldson wrote:

> Hi All,
> 
> While implementing a minor tweak to the INFO element in section 5 (see proposed change at https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable14WorkingDraftNotes ), I noticed two (no three) inconsistencies between the VOTable schema and diagrams in section 7.1.
> 
> My hope is change as little as possible now, but please see and comment on my proposals for each case.
> 
> In general, I hope that VOTable 2.0 takes a new approach to many of these complexities.  In particular, I hope we can remove any flexibility that is not absolutely needed to support a well-defined use case or that does not have well-defined semantics.  A test suite of legal and illegal VOTables would be useful, but also a lot of effort to create and maintain.  But all that's for another day...
> 
> Regards,
> Tom
> 
> 
> 1) Position of INFO element inside RESOURCE:
> 
> The diagram in section 7.1 says that inside RESOURCE, the INFO, COOSYS, TIMESYS, GROUP and PARAM elements can appear in any order relative to each other.  The schema however requires that INFO appear before any of those other element (i.e., INFO is part of the sequence, but not part of the choice).  The current schema renders illegal the placement of INFO in Section 5.
> 
> This restrictiveness seems to have been added to the schema in VOTable 1.2.  This is also inconsistent with the VOTABLE element where the schema agrees with the diagram and allow flexible ordering of INFO.
> 
> Proposal:  Update the diagram to match the schema.  With that approach, any provider or consumer that relied on the schema or votlint would be OK.  If providers relied on the diagram in the past, their VOTables would already have been rejected by consumers that relied on the schema.
> 
> 
> 2)  Relative positions of LINK, TABLE, RESOURCE and INFO inside RESOURCE:
> 
> The diagram says that a RESOURCE can end with any number LINKs, followed by any number of TABLEs, followed by any number of RESOURCEs, followed by any number of INFOs.  In the schema, those elements are inside of a repeatable sequence, so the ordering is substantially more flexible than the diagram indicates, but not totally flexible due to the TABLE/RESOURCE choice in the sequence.
> 
> For example, this is legal:
> 
> 		<COOSYS ID="mycoords"/>
> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> 		<INFO name="info" value="info"/>
> 		<LINK/>
> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> 
> But this is not:
> 
> 
> 		<COOSYS ID="mycoords"/>
> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> 		<LINK/>
> 		<INFO name="info" value="info"/>
> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> 
> Proposal:  Leave the schema as is for the same reasons as case #1.  But also leave the diagram as is since we don't have existing diagram techniques to describe what the schema says.  Perhaps a note in that section trying to explain that could be helpful.  Repeating these particular elements is probably extremely rare, so what we do may not matter much for current implementations.
> 
> 
> 3)  While writing this, I noticed yet another inconsistency between the diagrams and the schema.  The diagrams claim that TABLE has no required children, but the schema requires that one of FIELD, PARAM or GROUP be present.
> 
> Proposal:  Do nothing.  A TABLE without a FIELD, PARAM or GROUP is not worth worrying about.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From francois.ochsenbein at gmail.com  Mon Apr  1 13:46:22 2019
From: francois.ochsenbein at gmail.com (Francois Ochsenbein)
Date: Mon, 1 Apr 2019 13:46:22 +0200
Subject: VOTable 1.4 schema inconsistencies
In-Reply-To: <alpine.LRH.2.21.1904010920580.2675@localhost>
References: <DF7BECBC-0BD0-43B7-B780-586210F73B5F@stsci.edu>
	<alpine.LRH.2.21.1904010920580.2675@localhost>
Message-ID: <20190401134622.4aedf0bb@pi3>

Hello,

Just along the same remarks that the XSD schema should prevail, VOTable 
version 1.2 included the following sentence at the beginning of
section?7:

``The XML Schema represents the actual definition of a VOTable document.
In this section we illustrate this XML Schema by a set of boxes
describing the structure of a VOTable, and the list of attributes of
each VOTable element.''

Best regards to veterans and new IVOA friends ?

Fran?ois Ochsenbein

==> Le lundi 2019-04-01 ? 08:27+0000,
    Mark Taylor <M.B.Taylor at bristol.ac.uk> a ?crit:

>Tom,
>
>I agree with your approach of updating the diagram where possible and
>leaving the schema as is.  I confess to never having looked in great
>detail at these diagrams; they are kind of useful though obviously
>not as rich or precise as an XSD in defining what's legal.
>You mention the idea of adding a note to that effect in section 7.1;
>a possibility would be to include a comment that in case of
>any discrepancies between the schema and the diagram, the schema
>is definitive (or equivalently to mark section 7.1 as non-normative).
>I'm pretty sure this is what readers would assume anyway, but it
>might avoid potential confusion to make that explicit.  But up to
>you whether you think that's a good idea.
>
>Mark
>
>On Sun, 31 Mar 2019, Tom Donaldson wrote:
>
>> Hi All,
>> 
>> While implementing a minor tweak to the INFO element in section 5
>> (see proposed change at
>> https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable14WorkingDraftNotes
>> ), I noticed two (no three) inconsistencies between the VOTable
>> schema and diagrams in section 7.1.
>> 
>> My hope is change as little as possible now, but please see and
>> comment on my proposals for each case.
>> 
>> In general, I hope that VOTable 2.0 takes a new approach to many of
>> these complexities.  In particular, I hope we can remove any
>> flexibility that is not absolutely needed to support a well-defined
>> use case or that does not have well-defined semantics.  A test suite
>> of legal and illegal VOTables would be useful, but also a lot of
>> effort to create and maintain.  But all that's for another day...
>> 
>> Regards,
>> Tom
>> 
>> 
>> 1) Position of INFO element inside RESOURCE:
>> 
>> The diagram in section 7.1 says that inside RESOURCE, the INFO,
>> COOSYS, TIMESYS, GROUP and PARAM elements can appear in any order
>> relative to each other.  The schema however requires that INFO
>> appear before any of those other element (i.e., INFO is part of the
>> sequence, but not part of the choice).  The current schema renders
>> illegal the placement of INFO in Section 5.
>> 
>> This restrictiveness seems to have been added to the schema in
>> VOTable 1.2.  This is also inconsistent with the VOTABLE element
>> where the schema agrees with the diagram and allow flexible ordering
>> of INFO.
>> 
>> Proposal:  Update the diagram to match the schema.  With that
>> approach, any provider or consumer that relied on the schema or
>> votlint would be OK.  If providers relied on the diagram in the
>> past, their VOTables would already have been rejected by consumers
>> that relied on the schema.
>> 
>> 
>> 2)  Relative positions of LINK, TABLE, RESOURCE and INFO inside
>> RESOURCE:
>> 
>> The diagram says that a RESOURCE can end with any number LINKs,
>> followed by any number of TABLEs, followed by any number of
>> RESOURCEs, followed by any number of INFOs.  In the schema, those
>> elements are inside of a repeatable sequence, so the ordering is
>> substantially more flexible than the diagram indicates, but not
>> totally flexible due to the TABLE/RESOURCE choice in the sequence.
>> 
>> For example, this is legal:
>> 
>> 		<COOSYS ID="mycoords"/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 		<INFO name="info" value="info"/>
>> 		<LINK/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 
>> But this is not:
>> 
>> 
>> 		<COOSYS ID="mycoords"/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 		<LINK/>
>> 		<INFO name="info" value="info"/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 
>> Proposal:  Leave the schema as is for the same reasons as case #1.
>> But also leave the diagram as is since we don't have existing
>> diagram techniques to describe what the schema says.  Perhaps a note
>> in that section trying to explain that could be helpful.  Repeating
>> these particular elements is probably extremely rare, so what we do
>> may not matter much for current implementations.
>> 
>> 
>> 3)  While writing this, I noticed yet another inconsistency between
>> the diagrams and the schema.  The diagrams claim that TABLE has no
>> required children, but the schema requires that one of FIELD, PARAM
>> or GROUP be present.
>> 
>> Proposal:  Do nothing.  A TABLE without a FIELD, PARAM or GROUP is
>> not worth worrying about.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>
>--
>Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
>m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/


-- 
======================================================================
Francois Ochsenbein  ---   6, rue des Vosges -- 67380 Lingolsheim 
ochsenbein at evc.net   ---   francois.ochsenbein at gmail.com
+33 (0)388 77 81 17  ---   +33 (0)602 39 60 78
======================================================================

From glemson1 at jhu.edu  Mon Apr  1 15:37:46 2019
From: glemson1 at jhu.edu (Gerard Lemson)
Date: Mon, 1 Apr 2019 13:37:46 +0000
Subject: VOTable 1.4 schema inconsistencies
In-Reply-To: <20190401134622.4aedf0bb@pi3>
References: <DF7BECBC-0BD0-43B7-B780-586210F73B5F@stsci.edu>
	<alpine.LRH.2.21.1904010920580.2675@localhost>
	<20190401134622.4aedf0bb@pi3>
Message-ID: <BL0PR0102MB33780BAE82345FF8691C896497550@BL0PR0102MB3378.prod.exchangelabs.com>

As an aside regarding the XSD.
There are still a bunch of comments in there that I made >>10 years ago when we rewrote the schema.
Most prefixed by "GL:". I think it might be nice to finally remove these in the next version.
Cheers
Gerard



> -----Original Message-----
> From: apps-bounces at ivoa.net [mailto:apps-bounces at ivoa.net] On Behalf Of
> Francois Ochsenbein
> Sent: Monday, April 01, 2019 7:46 AM
> To: Mark Taylor <M.B.Taylor at bristol.ac.uk>
> Cc: Applications WG <apps at ivoa.net>
> Subject: Re: VOTable 1.4 schema inconsistencies
> 
> 
> Hello,
> 
> Just along the same remarks that the XSD schema should prevail, VOTable
> version 1.2 included the following sentence at the beginning of section?7:
> 
> ``The XML Schema represents the actual definition of a VOTable document.
> In this section we illustrate this XML Schema by a set of boxes describing the
> structure of a VOTable, and the list of attributes of each VOTable element.''
> 
> Best regards to veterans and new IVOA friends ?
> 
> Fran?ois Ochsenbein
> 
> ==> Le lundi 2019-04-01 ? 08:27+0000,
>     Mark Taylor <M.B.Taylor at bristol.ac.uk> a ?crit:
> 
> >Tom,
> >
> >I agree with your approach of updating the diagram where possible and
> >leaving the schema as is.  I confess to never having looked in great
> >detail at these diagrams; they are kind of useful though obviously not
> >as rich or precise as an XSD in defining what's legal.
> >You mention the idea of adding a note to that effect in section 7.1; a
> >possibility would be to include a comment that in case of any
> >discrepancies between the schema and the diagram, the schema is
> >definitive (or equivalently to mark section 7.1 as non-normative).
> >I'm pretty sure this is what readers would assume anyway, but it might
> >avoid potential confusion to make that explicit.  But up to you whether
> >you think that's a good idea.
> >
> >Mark
> >
> >On Sun, 31 Mar 2019, Tom Donaldson wrote:
> >
> >> Hi All,
> >>
> >> While implementing a minor tweak to the INFO element in section 5
> >> (see proposed change at
> >> https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable14WorkingDraftNotes
> >> ), I noticed two (no three) inconsistencies between the VOTable
> >> schema and diagrams in section 7.1.
> >>
> >> My hope is change as little as possible now, but please see and
> >> comment on my proposals for each case.
> >>
> >> In general, I hope that VOTable 2.0 takes a new approach to many of
> >> these complexities.  In particular, I hope we can remove any
> >> flexibility that is not absolutely needed to support a well-defined
> >> use case or that does not have well-defined semantics.  A test suite
> >> of legal and illegal VOTables would be useful, but also a lot of
> >> effort to create and maintain.  But all that's for another day...
> >>
> >> Regards,
> >> Tom
> >>
> >>
> >> 1) Position of INFO element inside RESOURCE:
> >>
> >> The diagram in section 7.1 says that inside RESOURCE, the INFO,
> >> COOSYS, TIMESYS, GROUP and PARAM elements can appear in any order
> >> relative to each other.  The schema however requires that INFO appear
> >> before any of those other element (i.e., INFO is part of the
> >> sequence, but not part of the choice).  The current schema renders
> >> illegal the placement of INFO in Section 5.
> >>
> >> This restrictiveness seems to have been added to the schema in
> >> VOTable 1.2.  This is also inconsistent with the VOTABLE element
> >> where the schema agrees with the diagram and allow flexible ordering
> >> of INFO.
> >>
> >> Proposal:  Update the diagram to match the schema.  With that
> >> approach, any provider or consumer that relied on the schema or
> >> votlint would be OK.  If providers relied on the diagram in the past,
> >> their VOTables would already have been rejected by consumers that
> >> relied on the schema.
> >>
> >>
> >> 2)  Relative positions of LINK, TABLE, RESOURCE and INFO inside
> >> RESOURCE:
> >>
> >> The diagram says that a RESOURCE can end with any number LINKs,
> >> followed by any number of TABLEs, followed by any number of
> >> RESOURCEs, followed by any number of INFOs.  In the schema, those
> >> elements are inside of a repeatable sequence, so the ordering is
> >> substantially more flexible than the diagram indicates, but not
> >> totally flexible due to the TABLE/RESOURCE choice in the sequence.
> >>
> >> For example, this is legal:
> >>
> >> 		<COOSYS ID="mycoords"/>
> >> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> >> 		<INFO name="info" value="info"/>
> >> 		<LINK/>
> >> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> >>
> >> But this is not:
> >>
> >>
> >> 		<COOSYS ID="mycoords"/>
> >> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> >> 		<LINK/>
> >> 		<INFO name="info" value="info"/>
> >> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
> >>
> >> Proposal:  Leave the schema as is for the same reasons as case #1.
> >> But also leave the diagram as is since we don't have existing diagram
> >> techniques to describe what the schema says.  Perhaps a note in that
> >> section trying to explain that could be helpful.  Repeating these
> >> particular elements is probably extremely rare, so what we do may not
> >> matter much for current implementations.
> >>
> >>
> >> 3)  While writing this, I noticed yet another inconsistency between
> >> the diagrams and the schema.  The diagrams claim that TABLE has no
> >> required children, but the schema requires that one of FIELD, PARAM
> >> or GROUP be present.
> >>
> >> Proposal:  Do nothing.  A TABLE without a FIELD, PARAM or GROUP is
> >> not worth worrying about.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >--
> >Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> >m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> 
> 
> --
> ================================================================
> ======
> Francois Ochsenbein  ---   6, rue des Vosges -- 67380 Lingolsheim
> ochsenbein at evc.net   ---   francois.ochsenbein at gmail.com
> +33 (0)388 77 81 17  ---   +33 (0)602 39 60 78
> ================================================================
> ======


From tdonaldson at stsci.edu  Wed Apr  3 16:18:55 2019
From: tdonaldson at stsci.edu (Tom Donaldson)
Date: Wed, 3 Apr 2019 14:18:55 +0000
Subject: Call for Applications Contributions
Message-ID: <F6353DF3-E4CC-4840-BE55-00127150CDE2@stsci.edu>

Dear IVOA,

This is an invitation to submit contributions to the Applications session(s) at the upcoming IVOA Interoperability Meeting in Paris, May 12-17 (https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2019MeetingPage).

If you would like to present something or lead a discussion, please let me and Raffaele know as soon as possible so that it can be considered while the TCG makes the meeting schedule.

Talks are welcome on a variety of topics, especially:

* New implementations of applications/tools/libraries that use IVOA standards:
**  Demonstrations
**  Architecture
**  Providing or using open source code
**  Challenges faced

* Standards under the Applications domain:
**  VOTable 1.4 and beyond
**  MOC, HiPS, SAMP

* Python
** Implementations
** Open Development

Regards,
Tom



From tdonaldson at stsci.edu  Thu Apr  4 16:47:57 2019
From: tdonaldson at stsci.edu (Tom Donaldson)
Date: Thu, 4 Apr 2019 14:47:57 +0000
Subject: New VOTable 1.4 Working Draft
Message-ID: <EB8C0295-541A-4E1D-B999-FAB4441E8D8C@stsci.edu>

Hi All,

A new VOTable 1.4 working draft has been published at:
http://www.ivoa.net/documents/VOTable/20190403/

The changes this time were fairly minor.  Please see the complete change logs for all the working drafts at: 
https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable14WorkingDraftNotes

At this point, major changes are unlikely unless we need to address issues found during implementation.  In order to move to a "Proposed Recommendation" status, we should have at least 2 reference implementations as well as provisions for validation.

Exactly what that means is up for debate, but ideally I would like to see (at least) one data provider that can utilize the TIMESYS element, and (at least) one client that can not only parse the VOTable, but also make it clear that it "understands" the TIMESYS semantics.

I will try to work on the parsing side in both the Astropy VOTable parser and probably the MAST Portal parser.  Neither of those will be able to use the TIMESYS data by themselves, so I'd be interested in hearing some possible use cases as well as getting some realistic VOTables to test on.

Please let me know if you plan on, or may get to, working on an implementation or validator.

Thanks,
Tom



From M.B.Taylor at bristol.ac.uk  Thu Apr  4 17:02:06 2019
From: M.B.Taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 4 Apr 2019 15:02:06 +0000
Subject: New VOTable 1.4 Working Draft
In-Reply-To: <EB8C0295-541A-4E1D-B999-FAB4441E8D8C@stsci.edu>
References: <EB8C0295-541A-4E1D-B999-FAB4441E8D8C@stsci.edu>
Message-ID: <alpine.LRH.2.21.1904041549480.10616@andromeda.star.bris.ac.uk>

Tom,

I hope to add some TIMESYS capability to STIL/STILTS/TOPCAT before
the Paris interop, I'm not sure yet if this would be in released or
pre-release code.  The intention would be to do what I've done for
COOSYS (since topcat 4.5): model the TIMESYS element in STIL's
internal model of a table and update the VOTable input and output
handlers accordingly, so that topcat/stilts can round-trip VOTables
while preserving TIMESYS elements, and allow display of the TIMESYS
attributes in topcat's column metadata window.  On this timescale
I probably will not attempt anything smarter than that,
e.g. functions to actually make use of this time system metadata.

I guess I should prototype TIMESYS validation in taplint too,
though coping with a new VOTable version *may* make that more
complicated than it sounds ... I'll see how I go.

I'll report back if I make progress.

Mark


On Thu, 4 Apr 2019, Tom Donaldson wrote:

> Hi All,
> 
> A new VOTable 1.4 working draft has been published at:
> http://www.ivoa.net/documents/VOTable/20190403/
> 
> The changes this time were fairly minor.  Please see the complete change logs for all the working drafts at: 
> https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable14WorkingDraftNotes
> 
> At this point, major changes are unlikely unless we need to address issues found during implementation.  In order to move to a "Proposed Recommendation" status, we should have at least 2 reference implementations as well as provisions for validation.
> 
> Exactly what that means is up for debate, but ideally I would like to see (at least) one data provider that can utilize the TIMESYS element, and (at least) one client that can not only parse the VOTable, but also make it clear that it "understands" the TIMESYS semantics.
> 
> I will try to work on the parsing side in both the Astropy VOTable parser and probably the MAST Portal parser.  Neither of those will be able to use the TIMESYS data by themselves, so I'd be interested in hearing some possible use cases as well as getting some realistic VOTables to test on.
> 
> Please let me know if you plan on, or may get to, working on an implementation or validator.
> 
> Thanks,
> Tom
> 
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From msdemlei at ari.uni-heidelberg.de  Mon Apr  8 16:41:10 2019
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Mon, 8 Apr 2019 16:41:10 +0200
Subject: refframe vocabulary
Message-ID: <20190408144110.pnu7yptujlrlcjoq@victor>

Dear colleagues,

[apologies for the wide cross-post, but there's something in this for
everyone; I'd suggest followup to semantics]

For STC2, we will need an updated list of reference frames, and
current plans are to keep the list of reference frames in a
vocabulary, in particular to facilitate quick updates as they are
need (e.g., for solar system bodies).

With the resurrection of COOSYS, it further seems to me we should
keep VOTable's notion of refframes in sync with this effort, which in
turn would make it prudent to maintain existing VOTable terms as
well.

With these considerations, based the STC1 list, VOTable COOSYS, and
previous work by Mark CD, I've made a first draft vocabulary for the
reference frames at http://docs.g-vo.org/rdf/refframe/.

I'd be great if you could review the terms and their explanations.
Specific to-do points from me:

* I've removed the Earth reference systems for now; I suspect we
  might need them for observatory positions and such, but I'm sure we
  should only include here what we absolutely need (use cases!)

* There are also no planetary reference systems.  These probably
  should hang off of BODY when they come in.  I'd be really grateful
  if we could normative references for all of these (Galactic and
  ICRS show how I'd like this to look like).

* Speaking of references, once you start digging, it turns out
  ECLIPTIC becomes a tricky term.  If you can supply a reference for
  what this probably means where it's being used, I'd be really
  happy.  Oh, and if you have something ready for SUPER_GALACTIC, I'd
  like that as well.

* There are three VOTable terms I've not found sufficiently defined,
  and perhaps someone on Apps still remembers what they were supposed
  to be:

  (1) xy -- is this really UNKNOWN?  VOTable 1.1 speaks of "user
      defined" here, and it looks a bit... well, cartesian.  Hm.
  (2) barycentric -- this sounds a bit like ICRS BARYCENTER, where
      one thing would cover both the refpos and the refframe.  Is that 
      what it is?  If not, what else?
  (3) geo_app -- Ummm.  Do I appear extremely dumb if I admit I can't
      even speculate on this?

As usual, everyone is invited to do edits on volute:
https://volute.g-vo.org/svn/trunk/projects/semantics/vocabularies/refframe

The terms are stored in a simple CSV file, with just a bit of
hierarchy implied through the second column, so don't panic.  No RDF
fu required here.

Thanks,

            Markus

From baptiste.cecconi at obspm.fr  Thu Apr 11 14:04:30 2019
From: baptiste.cecconi at obspm.fr (Baptiste Cecconi)
Date: Thu, 11 Apr 2019 14:04:30 +0200
Subject: refframe vocabulary
In-Reply-To: <20190408144110.pnu7yptujlrlcjoq@victor>
References: <20190408144110.pnu7yptujlrlcjoq@victor>
Message-ID: <63CA263C-C94E-4DBC-A739-DA6CF89A8DC5@obspm.fr>

Hi Markus! 

As you know I've been on those advocating for a controlled vocabulary of reference frames outside STC, so that we can handle easily the variety of solar system (and spacecraft) reference frames. 

First, here we talk about space reference frames, right ? The STC model defines reference frames for space (SpaceRefFrame), time (TimeFrame), spectral (SpectralFrame), velocity (RedshiftFrame). 

I see that in your proposal, all solar system reference frames should fall into the BODY coordinates bag. I guess that is possible, but the definition of the the BODY generic frame will not work in this case. Some planetary reference frames are planetocentric, others are planetographic, planetodetic (don't ask the difference, I don't really know :-), or even barycentric (planetary system (planet+moons) barycenter). On Martian rovers, for instance, AZ_EL may be used (but on a different planet than Earth), etc. Moreover, for Earth magnetospheric frames, would depend on BODY, whereas other Earth centered astronomical frames would not. 

On the VESPA wiki, there is a page where we have tried to list all reference frames we know of for planetary and solar sciences:
https://voparis-confluence.obspm.fr/display/VES/Planetary+Coordinate+Systems

There is also coordinate reference system list for planetary bodies maintained for GIS applications on Mars and the Moon:
https://github.com/planetserver/planetary-crs

We have also started a github repo for SolarSystemRefFrames, with a list of bibliographic references and sources for Ref Frames:
https://github.com/epn-vespa/SolarSystemRefFrames/blob/master/list-of-sources.md

Cheers
Baptiste



> Le 8 avr. 2019 ? 16:41, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> a ?crit :
> 
> Dear colleagues,
> 
> [apologies for the wide cross-post, but there's something in this for
> everyone; I'd suggest followup to semantics]
> 
> For STC2, we will need an updated list of reference frames, and
> current plans are to keep the list of reference frames in a
> vocabulary, in particular to facilitate quick updates as they are
> need (e.g., for solar system bodies).
> 
> With the resurrection of COOSYS, it further seems to me we should
> keep VOTable's notion of refframes in sync with this effort, which in
> turn would make it prudent to maintain existing VOTable terms as
> well.
> 
> With these considerations, based the STC1 list, VOTable COOSYS, and
> previous work by Mark CD, I've made a first draft vocabulary for the
> reference frames at http://docs.g-vo.org/rdf/refframe/.
> 
> I'd be great if you could review the terms and their explanations.
> Specific to-do points from me:
> 
> * I've removed the Earth reference systems for now; I suspect we
>  might need them for observatory positions and such, but I'm sure we
>  should only include here what we absolutely need (use cases!)
> 
> * There are also no planetary reference systems.  These probably
>  should hang off of BODY when they come in.  I'd be really grateful
>  if we could normative references for all of these (Galactic and
>  ICRS show how I'd like this to look like).
> 
> * Speaking of references, once you start digging, it turns out
>  ECLIPTIC becomes a tricky term.  If you can supply a reference for
>  what this probably means where it's being used, I'd be really
>  happy.  Oh, and if you have something ready for SUPER_GALACTIC, I'd
>  like that as well.
> 
> * There are three VOTable terms I've not found sufficiently defined,
>  and perhaps someone on Apps still remembers what they were supposed
>  to be:
> 
>  (1) xy -- is this really UNKNOWN?  VOTable 1.1 speaks of "user
>      defined" here, and it looks a bit... well, cartesian.  Hm.
>  (2) barycentric -- this sounds a bit like ICRS BARYCENTER, where
>      one thing would cover both the refpos and the refframe.  Is that 
>      what it is?  If not, what else?
>  (3) geo_app -- Ummm.  Do I appear extremely dumb if I admit I can't
>      even speculate on this?
> 
> As usual, everyone is invited to do edits on volute:
> https://volute.g-vo.org/svn/trunk/projects/semantics/vocabularies/refframe
> 
> The terms are stored in a simple CSV file, with just a bit of
> hierarchy implied through the second column, so don't panic.  No RDF
> fu required here.
> 
> Thanks,
> 
>            Markus


From msdemlei at ari.uni-heidelberg.de  Thu Apr 11 15:00:41 2019
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Thu, 11 Apr 2019 15:00:41 +0200
Subject: refframe vocabulary
In-Reply-To: <63CA263C-C94E-4DBC-A739-DA6CF89A8DC5@obspm.fr>
References: <20190408144110.pnu7yptujlrlcjoq@victor>
	<63CA263C-C94E-4DBC-A739-DA6CF89A8DC5@obspm.fr>
Message-ID: <20190411130041.2umobeqvub7lmylu@victor>

Hi all,

I'm sure followups to this should be restricted to ssig at ivoa.net.
For those on ssig: this is about a proposed vocabulary at
http://docs.g-vo.org/rdf/refframe/.

On Thu, Apr 11, 2019 at 02:04:30PM +0200, Baptiste Cecconi wrote:
> First, here we talk about space reference frames, right ? The STC
> model defines reference frames for space (SpaceRefFrame), time
> (TimeFrame), spectral (SpectralFrame), velocity (RedshiftFrame). 

This is a list of spatial reference frame names, yes.

> I see that in your proposal, all solar system reference frames
> should fall into the BODY coordinates bag. I guess that is
> possible, but the definition of the the BODY generic frame will not
> work in this case. Some planetary reference frames are
> planetocentric, others are planetographic, planetodetic (don't ask
> the difference, I don't really know :-), or even barycentric

Well, I'm open to new top-level terms as long as they help machines
make sense of what they're seeing, because that's the purpose of
these terms and their hierarchy.  I'm not enough of a cartographer to
figure out if it helps to know if a frame is planetographic or
-centric, though.

> (planetary system (planet+moons) barycenter). On Martian rovers,
> for instance, AZ_EL may be used (but on a different planet than
> Earth), etc. Moreover, for Earth magnetospheric frames, would

On AZ_EL, I suspect the nature of the ground shouldn't matter.  To
make sense of these automatically, we'd need to define the observer
location, and when we do this, I don't think we'll much favour Earth
over anything else.

> On the VESPA wiki, there is a page where we have tried to list all
> reference frames we know of for planetary and solar sciences:
> https://voparis-confluence.obspm.fr/display/VES/Planetary+Coordinate+Systems
> 
> There is also coordinate reference system list for planetary bodies
> maintained for GIS applications on Mars and the Moon:
> https://github.com/planetserver/planetary-crs
> 
> We have also started a github repo for SolarSystemRefFrames, with a
> list of bibliographic references and sources for Ref Frames:
> https://github.com/epn-vespa/SolarSystemRefFrames/blob/master/list-of-sources.md

Hm -- that's... quite a bit.

Although STC has never been explicit about that and thus the question
might really be up for discussion, I would suggest that the purpose
of this vocabulary is operational rather than encyclopaedic.  This
means: Before we add a term in here, there should be a VOTable in
which the term needs to be used, and there should be a consumer of
that VOTable that can actually make use of the term when it's there.

We (i.e., the Semantics WG) plan to make it reasonably easy to add
terms to the lists as needed, so there's no reason to put in terms
"because we might need it later".

So: is there a top 10 or top 20 of spatial reference frames you'd
actually need and can use in VESPA right now?  Something of that
order would be great for prototyping.

You see, the whole big list *is* a bit overwhelming (bordering on
discouraging), and if we get it wrong with 500 terms, cleaning up is
a lot harder than when we've got just a dozen.

Thanks,

        Markus

From tdonaldson at stsci.edu  Mon Apr 15 18:31:00 2019
From: tdonaldson at stsci.edu (Tom Donaldson)
Date: Mon, 15 Apr 2019 16:31:00 +0000
Subject: Call for Applications Contributions
In-Reply-To: <F6353DF3-E4CC-4840-BE55-00127150CDE2@stsci.edu>
References: <F6353DF3-E4CC-4840-BE55-00127150CDE2@stsci.edu>
Message-ID: <584F71CC-C8E7-4CAE-8E06-5376B81FCAE3@stsci.edu>

Hello All,

Just a reminder to please submit your proposals for talks during Applications sessions at the upcoming Interop.

Cheers,
Tom


From: <apps-bounces at ivoa.net> on behalf of Tom Donaldson <tdonaldson at stsci.edu>
Date: Wednesday, April 3, 2019 at 10:19 AM
To: Applications WG <apps at ivoa.net>, "interop at ivoa.net" <interop at ivoa.net>
Cc: Raffaele D'Abrusco <rdabrusc at cfa.harvard.edu>
Subject: Call for Applications Contributions

Dear IVOA,

This is an invitation to submit contributions to the Applications session(s) at the upcoming IVOA Interoperability Meeting in Paris, May 12-17 (https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2019MeetingPage).

If you would like to present something or lead a discussion, please let me and Raffaele know as soon as possible so that it can be considered while the TCG makes the meeting schedule.

Talks are welcome on a variety of topics, especially:

* New implementations of applications/tools/libraries that use IVOA standards:
**  Demonstrations
**  Architecture
**  Providing or using open source code
**  Challenges faced

* Standards under the Applications domain:
**  VOTable 1.4 and beyond
**  MOC, HiPS, SAMP

* Python
** Implementations
** Open Development

Regards,
Tom



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20190415/8acf5074/attachment.html>

From tdonaldson at stsci.edu  Tue Apr 16 18:20:39 2019
From: tdonaldson at stsci.edu (Tom Donaldson)
Date: Tue, 16 Apr 2019 16:20:39 +0000
Subject: RFC process question
Message-ID: <4ED985C2-FFC8-42E5-89A0-6DCB1265CBEC@stsci.edu>

Hi TCG and Apps,

The Applications working group has 2 documents in Working Draft status, MOC 1.1 and VOTable 1.4.

Discussion has settled on both documents, so there is a desire to move to RFC.  However, I want to make sure I understand the implementation requirements.

I had been thinking that implementations could happen during the RFC period, so I hadn?t been pushing them during our working draft discussions.  But in reading the process documentation more carefully, it seems that 2 reference implementations and provision of validation tools should be present prior to the RFC period.  

That requirement makes sense to me, since the commenters should have access to the implementations to inform their comments.  So all that setup leads to this question:

Is it OK to create the RFC page as a place to document implementations and gather comments prior to the official RFC period (and its 6 week countdown)?  That seems OK to me, but it could lead to a confusing document status.  Any suggestions on how to proceed would be appreciated.

Thanks,
Tom



From dbaines at sciops.esa.int  Mon Apr 29 16:08:23 2019
From: dbaines at sciops.esa.int (Deborah Baines)
Date: Mon, 29 Apr 2019 16:08:23 +0200
Subject: Call for contributions to issue 21 of the IVOA newsletter. Deadline
	for articles: 5th June 2019
In-Reply-To: <563d3061-b85d-58ac-e3ec-08b1d6026ec9@sciops.esa.int>
References: <c4c43765-217c-9397-5b30-1c673d2365f5@sciops.esa.int>
	<563d3061-b85d-58ac-e3ec-08b1d6026ec9@sciops.esa.int>
Message-ID: <17620_1556546864_5CC7052E_17620_142_1_bfd83cfe-38dd-8ca3-7231-ce02334c1646@sciops.esa.int>

Dear All,

This is a call for contributions to the next (21st) issue of the IVOA 
newsletter, due to be published in early July 2019.

The IVOA newsletter aims to bring the latest news about Virtual 
Observatory applications to astronomers. It is composed of short (~100 
word) articles highlighting new VO capabilities, including software 
tutorials and outreach activities, together with a list of recent 
articles and upcoming events.

Please note that the audience is the general astronomy scientific 
community so VO jargon must be minimized, and usefulness to astronomers 
maximized!

Please submit your articles to ivoa-news-editors at ivoa.net by Wednesday 
5th June2019.

Contributors are requested to use the same brief format for articles as 
used in the previous issues (http://www.ivoa.net/newsletter/). This is a 
short text highlighting a new application or feature, with a single 
small image (that may expand to a larger one via a link) and a URL for 
more information. Articles will be edited by the Newsletter Editors, and 
the newsletter will be checked by an oversight committee prior to release.

Please feel free to distribute this email to your colleagues and any 
interested parties.

Many thanks,

Debbie Baines, on behalf of the IVOA newsletter editors


-- 
________________________________________________________
QUASAR Science Resources for ESA - European Space Agency

Dr. Deborah Baines
Astronomy Archives Science Lead

ESAC Science Data Centre (ESDC)
Data and Engineering Division
Operations Department, Directorate of Science
European Space Astronomy Centre (ESAC)
European Space Agency (ESA)

Camino Bajo del Castillo s/n
Urb. Villafranca del Castillo
E-28692 Villanueva de la Ca?ada, Madrid, Spain
deborah.baines at sciops.esa.int | www.esa.int
Tel. +34 918 131 146  | Fax  +34 918 131 218
________________________________________________________



This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20190429/e0ab8171/attachment.html>