Expressing 2- and 3-D coordinates

Rob Seaman seaman at noao.edu
Thu Dec 15 15:22:42 PST 2005


Ed says:

> The VO user base includes everyone.  But the VO project space can  
> not include all projects.

We are discussing a function - for the sake of argument, a function  
of one variable:

	usage = f(individual)

You are commenting on the domain of the function - although one might  
assert this is more like "everyone with a networked computer".  We  
are really interested in the range of the function, i.e., in  
maximizing actual VO users.

The VO project space may not include all projects, but it likely  
should include those with funding, such as VOEvent.

> It would be great if two STC schema is all everyone ever needs.   
> But if you accept STCLite then you accept the wisdom of the view.

Uh - no.

> STCLite is STC with elements knocked out to satisfy a specific  
> project.

No - STCLite is implemented via an entirely separate schema.

> And that is fine.  Some projects are going to knock out a few more  
> things some, a few less, some will add somethings of their own.

But that is not what you said.  You said:

> Projects are free to create copies of the schema and knock out  
> parts and change required elements to optional ones.

An STC "typed" element with added "somethings" might be supported by  
an STC schema that would allow for adding certain somethings.

An STC typed element with a few things "knocked out" will certainly  
be supported by a schema (like STC) in which those subelements/ 
attributes are optional.

Your suggestion amounts to the statement that anybody can claim VO  
conformance while using any schemata they feel like using - to  
"create copies" and to "change required elements to optional elements".

VOEvent uses a wide range of standard VO technology.  The WG reached  
a consensus to use STC.  The majority of the WG would have preferred  
an STC with "common sense" defaults, but that was the only basic  
issue with using STC.  STC has been a bit of a moving target in the  
mean time - and not, I think, primarily because of pressure from  
VOEvent.  XIncludes seemed like a problem - we're assured that XLink  
fixes all that.  We also have this conceptual issue with the wisdom  
of coordinate "vectors".  It sounds like other folks do, too.

Perhaps we can return to talking about the issue, and stop talking  
about talking about the issue.

Arnold says:

> I'd be very hesitant to encourage multiple STC-based schemata; that  
> also was the main rationale for rejecting STCLite.

Multiple schemata does sound a bit like "SIMPLE = F" FITS files.  Why  
have a standard at all?

> VO schemata ultimately will need to support list types since arrays  
> are such an integral part of our data.  In that context and  
> considering that such a list type is the more natural way to  
> express coordinate vectors (though I realize that this is my  
> subjective judgment) the present use of lists of doubles for  
> coordinate vectors would be preferable.

Subjective indeed.  Does anything actually *break* if a single RA/Dec  
or Long/Lat pair are expressed as individual elements?  Does anything  
actually work appreciably *better* if these two values (in the  
simple, frequent case) are expressed as a list type?

Surely, when list types are universally supported (should this ever  
occur) we still won't choose to represent every element as a list?

> a. STC sticks with list types and VOEvent may do something else.

Don't want to do this.  Don't think anybody else really wants VOEvent  
to, either.  Ultimately though, the existence of a consensus is more  
important than what the consensus turns out to be (within reason).

> b. STC temporarily converts to enumerating the vector components as  
> in my first message, and changes back to list types when list  
> support is firmly there.
>
> c. STC converts permanently to separate the components witin the  
> vector element.

These are equivalent for all practical purposes.  Doubt that v1.21 is  
intended to be the final version of STC.  Our grandchildren can  
always reconsider in a future version.

> 2. Is Ed's prognosis accurate?

Not likely.  Phil Massey once suggested selling IRAF insurance.  Will  
Ed cover the point spread?

Rob



More information about the dm mailing list