ivoa-std / conesearch Goto Github PK
View Code? Open in Web Editor NEWSimple Cone Search
License: Creative Commons Attribution Share Alike 4.0 International
Simple Cone Search
License: Creative Commons Attribution Share Alike 4.0 International
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:
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?
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:
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:
In the process of moving to a more flexible GET/POST independent query protocol currently there is:
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:
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:
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 https
s 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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.