ivoa-std / conesearch Goto Github PK

THere is an SR=ALLSKY slot in the Query examples section but nothing appears in the SR subsection (which discusses SR = 0 )

Likewise maxSR in the Resource metadata, we'd possibly need a maxTimeSpan for services that want to limit the maximum extent of the searchable time span.

We need to define:

• what unit will it be in: [s]?
• defaults to: no limit?
  (this supposing it will be optional)

Not clear whether this, as well as the full registration prescriptions, should stay in the ConeSearch document or continue to live within SimpleDALRegExt.

Adding time window filtering to ConeSearch brings in the use case of a TIME only query.
In that case the SR param has to be set to an all-sky value of some sort.
ConeSearch 1.03 allows SR=180 for this.
Are other solutions possible/needed?

ConeSearch currently fixes to 1 RESOURCE with 1 TABLE response.
Should this be relaxed?

Somehow related to issue #32 , this is a Resource Registry matter.
However some text should be added in the specification document and, like in issue #30 , there is the need to define the proper location of the registering details (ConeSearch or SimpleDALRegExt).

The VOTable example from FIRST catalogue needs to be updated or replaced.
The added example with time domain information has to be checked.
This has a dependency on the solution to be taken about VOTable version for ConeSerach responses.

Following discussions during the IVOA interop meeting October 2019 in Groningen, an extension for Cone Search to filter by time interval was suggested.

This proposes adding a time interval (MJD_min MJD_max) as optional parameters, and brings the question of fixing the frame. SCS has the frame fixed to ICRS, we could fix the time frame to TCB.

The spec proposes the new DALI MAXREC parameter but does not mention DALI overflow statement

REC-ConeSearch-1.03 states that in the response table:

Exactly one FIELD must have ucd="ID_MAIN", with an array character type (fixed or variable length), representing an ID string for that record of the table. This identifier may not be repeated in the table, and it could be used to retrieve that same record again from that same table.

That is, a main identifier is required in the response and this request's goal is to have an handle on the specific record (not necessarily unique) in the catalogue.

However catalogue providers might have different use case for identifiers:

• catalogue internal unique identifiers
• globally/universally unique identifiers
• no need for unique or main identifiers

Should we modify the main ID behaviour in ConeSearch (while moving to UCD1+, see issue #20)?

Back compatibility will still require to have one (and only one) FIELD with ucd="meta.id;meta.main" (going for the easiest mapping on UCDs), but maybe some other solutions, based on practical use case, can be considered.

How to annotate a ConeSearch response with Source DM matadata?

Currently the document says (§3 Succesful Response):

[...] VOTable format (version 1.0 or later) [...]

where the goal was to relax the previous 1.0 to 1.1 limitation.
However, for TIME aware responses, VOTable 1.4+ would be required due to the TIMESYS PARAM addition.

I suppose this issue could be solved by modifying the wording to something like:

... must be in VOTable format. The appropriate VOTable version may vary depending on the service response and needed features; e.g. when returning properly annotated time records, VOTable must be of version 1.4+ due to the addition of the TIMESYS param.

Forgot to do this before. Even if applicable only to an error behaviour that is about to be deprecated it is worth the addition for minor revision continuity.

(when specification reaches enough maturity, i.e. around Proposed REC)
Need to update the .xsd for validation and the .vor for registering the standard.

As expressed in this DAL (quite old) mail thread to query the sky at a given epoch.
(connected also to solar system use cases)

There are many cases where a unique conesearch service engine serves multiple catalogues in the backend. The usual solution uses an extra query argument in the ConeSearch base_url to split the registration in multiple ConeSearch services.

In the process of moving to a solution without extra arguments in the base_url (see issue #31 ) a way could be formalising an optional query parameter, e.g. CATALOG, to achieve the same result, thus preparing for a smoother transition towards a no-extra-args specification.

This parameter has the same drawbacks in terms of registration and w.r.t. clients than the TIME one.

Being the TIME query parameter optional, it is not clear how a client can discover the services that support it. This should be a matter of resource registration, but it could be also conveyed in a metadata only response for the service.

This metadata response can be achieved using a MAXREC=0 call to the service:

• if it returns an error it means the client deals with a ConeSearch-1.03 service
• otherwise the metadata would show whether TIME is available as a param for query or not

In the process of moving to a more flexible GET/POST independent query protocol currently there is:

• a must on allowing HTTP GET
• a should on allowing HTTP POST
  to preserve compatibility with legacy services using extra query arguments that prevent appending /capabilities or other endpoints to the registered base_url.

Should we keep going this way, maybe alerting that GET-only will be deprecated in the future?
Should we allow REQUEST to handle getCapabilities and such where extra query args are present? (this poses an issue on registering the dual behaviour of services)

Although this is definitely a major change in the specification, we should try to move the UCDs listed in the ConeSearch protocol to the UCD1+ syntax.

The following UCD 1.0 words are the only ones used in ConeSearch 1.03:

• ID_MAIN
• POS_EQ_RA_MAIN
• POS_EQ_DEC_MAIN
• OBS_ANG-SIZE

Given there's no overlap between current ConeSearch-1.03 query parameters names and the ones used in the core specifications for SIAP-2.0 and SODA-1.0, it may be feasible to allow both query solutions.

I presume that services are not required to be time-aware.

This is alluded to in section 2.1 "The set of query constraints a cone search needs to understand MUST include the RA, DEC, SR parameters, MAY understand the TIME parameter,..." but glossed over elsewhere.

I think it should be spelled out more explicitly elsewhere how the service is expected to behave if it is not time-aware. How do clients presenting a TIME constraint know if it has been honoured? Should a non-time-aware service treat a time constraint as an error?

The current text in sec 3.1 (VOTable compliant response) mandates a time column in the output table alongside the ID, RA and Dec columns. I agree this should be mandatory where the service has performed filtering based on a submitted TIME parameter, but I would suggest that it should be optional for non-time-aware services. If it's mandatory, non-time-aware services may be tempted to put some dummy value in there.

With a working tessellation solution a search by ST-MOC looks promising.
It deviates from the "cone" legacy idea, but allows great flexibility, and it includes TIME filtering at the same time.

In order to allow for time filtering of the results an optional TIME parameter has been added to the specification.

Some clarifications/checks on the current text are needed:

• in the abstract
• in §2.1 where its optional behaviour is introduced
• §2.1.4: where TIME is properly defined (compatible to SIAv2 and SODA)
• in §5/§5.1.5 within ConeSearch capabilities description
  • this has an attachment to registering and filtering TIME-aware services

Section 2.1 declares that the {query} resource is of the form http://<server>/<local_path>?.

Do we need to make explict that the http could alternatively be https? We could scatter some httpss in the examples too.

I propose to add the ivoid as an in the VOTable header in order to links the result with the dataset described in the registry.

Note that other simple info could also be added see https://www.ivoa.net/documents/DataOrigin/index.html

In the porting of the REC-1.03 to the current document SR=0 was described as identical with MAXREC=0.
Since this is not exactly true the analogy among these two parameters has to be relaxed.
(anyway the actual goal is the same, thus MAXREC=0 is encouraged w.r.t. SR=0)

Simple Cone Search as an IVOA specification comes from a US-NVO project document.
The NVO document link went lost in time.
Now that it is available again, it would be nice to have it linked to the IVOA specification.
(it could also be nice to preserve the HTML version of the NVO in the repo)

Moving ConeSearch to an up to date version w.r.t. current VO technical scenario without moving to a major revision, some solutions coming from REC-ConeSearch-1.03 have been kept but marked as deprecated. This is done, however, inline in the document, mixing the expected default behaviour with the deprecated one.

The idea is to refactor the document to host the deprecated solutions in a dedicated section and let the expected default behaviour sections more readable.

ConeSearch states (end of §2.1)

If a query includes an optional parameter, either one specified by this document or not, that is not supported by the service implementation, the service must ignore that parameter.

This looks like silent failure.
Maybe we can suggest (a SHOULD?) to add <INFO> elements reporting the unused parameters.

Ray was removed when thinking about a major revision of this specification.
Since we're dealing first with a minor revision it is appropriate and fair to re-add him.

In the "volute" changes for the ConeSearch revision Marco Molinaro was added as editor alongside the v1.03 editor Ray Plante.
Given Ray Plante is not actively working within the IVOA and considering that Time Search will have an impact on the ConeSearch revision (just restarted) I suggest to:

• leave Ray Plante in the authors list only (dropping him from the editor's role)
• add Ada Nebot as an editor

How to query a catalogue with multiple target positions?

While WD-ConeSearch-1.1-20200828 tried to align with DALI also on error responses, REC-ConeSearch-1.03 still speaks of

• ID="Error" name="Error"

in INFO element for VOTable error response (w.r.t. name="QUERY_STATUS" value="ERROR").

Server/client implementations need be checked to see whether this change can be applied as minor revision to 1.03.