*IVOA DAL WG Running Meeting #6 *Wednesday 9 December 2020 - 20:00 UTC - vconf Participants: (13) Marco Molinaro, James Dempsey, François Bonnarel, Brent Miszalski, Gregory Dubois-Felsmann, Judith Silverman, Mark Taylor, Markus Demleitner, Patrick Dowler, Raffaele D'Abrusco, Serge Monkewitz, Tom Donaldson, Trey Roby *Agenda: 1. DataLink (discussion and Interop follow up) 1.1. Topics from Trey - we don't have to cover all these but there are from my talk 1.1.1. DataLink GitHub issues: 51,52,55 1.1.1.1. 51 - required vs optional parameters 1.1.1.2. 52 - data product vs web page 1.1.1.3. 55 - example URL 1.1.2. Validating a client implementation - How? 1.1.3. content_type, content_length, semantics, description as part of the standard 2. AOB *Notes: *1. DataLink * * dataprooduct_type issue * Raised a PR with this called content qualifier * Templating mechanism for accessURL * PR raised * Good feedback from MT * How to tell the source of the substitution - input params or field - may use field.x to designate a field and comply with the templating standard * MD has concerns about this - can these be put in the datalink table. Would like examples where this would not work * [FB] Some values come from the input values from the user rather than the from the table * [MD] But that´s a simple service -- still in the datalink document. * [GDF] The service descriptor is an important communication to clients about what can be down with every row and so can drive the UI displayed * [MD] * [GDF] Concrete exmaple: millions of rows, time series for each row, allow UI to show a button for the time series - homogenoeus tabl * [GDF] In a SIA service/obstap then need to rely on individual rows as the capabiltiies will vary for images,cubes, etc * [MD] Please add a comment to the PR pointing to the concrete services where you'd use (or perhaps already use) the new facilities. * [PD] Discussion would be different of the service descriptors were in a different standard -would need to choose which standard to solve the problem * [MM] Not sure who would take this on * [PD] Roadmap * version 1.1 is close to ready, finish with just the small improvements * for 1.2, would be good to split out serfice desc out in the future as it is used in other places. * Also for 1.2 templating is big and could be best in its own version [MD: +1] * [FB] Need prototypes of templating so that clients can try it out * [MT] Where is the complexity? * [PD] Current standard puts things on the end, templating allows inline adiditons - would be a problem with old clients * [MT] Is it really possible to be done as a minor version? * [PD] We can try but if it doesn't work out then can be done when we split it and then have a 2.0 * [MT] Client side doesn't look too hard * [PD] Splitting/postponing to a new minor version shouldn't delay it too much * [TR] Do we know how many clients are around? * [PD] One internal to CADC, another in PyVO (aimed at ALMA archive) * [GDF] PyVO clinet has been SIA focussed - is it being generalised? Planning to make a lot of use of datalink in Vera Rubin * [TR] Interested in having a URL that is passed to another URL where second is built using templating - open door to apps than can run other apps with the data [GDF] +1 for the need * [TR] Demonstrated this with the time series viewer - but without templating this was a bit messy * [GDF] Clients: Aladin, topcat, examples above * [FB] EPNTap also have a client * [FB] Many people are producing datalink * [MT] Backward compatibility is important - even if he changed Topcat today, have people using 2+ year old versions * [MD] Feel that much of this can be solved by a service that hands out 301/303 saving clients from adding logic - concerns with escaping * [MT] Escaping is a problem but well taken care of in the RFC - haven't implemented a client yet but comfortable with the spec * [FB] Lack of inline params is a limitation for Vizier * [PD] Many use cases that would benefit - continue work but push out 1.1 as we work and don't hold it up for this * Other issues raised by TR * type=optional to designate optional params * [FB] CDS uses type=hidden a lot * This proposal needs input from VOTable editor(s) * "type" attribute is reserved in votable, still used in places (see below) * [GDF] I am having some difficulty finding where in VOTable 1.4 it says that the “type” attribute of is deprecated. * [MD] It´s not deprecated, it´s reserved. p. 15... * a solution based on PDL is proposed, but there's not enough expertise to have a clear view currently. * example URLs for service descriptors - [JD] has been controvertial though * Move service descriptors spec to another home * Others issues around: Grouping datalink results, * Roadmap: * [MM] Issues flagged in github for v1.1 seem to be already done * [PD] close on 2 issues, FB has done content qualifier which solves #42 * [PD] can then release 1.1 and move on to look at templating * [MM] wrapping up 1.1 soon and going to RFC soon would be good and not hold up templating * [PD] Will examine if a backwards compatibilite approach to ... can be done in time for 1.1 * [SM] If newer templated service descriptors could be hidden from older clients via something like a RESOURCE with a different type. * [MD] I was hoping for something less intrusive ...
In particular because RESOURCE/@type has severely restricted values so far.
 [MM] (simple reminder): these running meetings aren't for formal decisions, but more to keep up the pace and ease communication. (reminder to prevent worries for those who are not able to attnd a specific meeting) [TR] How to tell the difference between data product, data itself, and application? [PD] Content type should tell you - text/html for open in browser, application/fits for data file [FB] Can have a param in content type(??) [FB] Content type In 1.1 not yet in 1.0 [MD] Thinking about service descriptor [MD] Links response can figure this out - content type plus semantics [GDF] One problem is that there’s no place for a version number annotation of the delivery of service descriptors in the current scheme. [PD] concerns about default vocab - put a lot of effort in to remove datset dependency and allow it to be used fo rother use cases [GDF] Using example of time series viewer - cone search gets back service desc and would hope to have a guide to how to load time series in specific format. Would use data product type of time series. Would like UI to be metadata driven - allow anyone to use the Rubin viewer - how to specify this speratae tothe data product? [PD] Leaning towards not havcing default vocab and putting full URI in - removes the bias towards datasets [TR] Was having problems as the standard doesn;t call out how to do this so wasn;t sure what the right way was [SM] I very much agree with Gregory - service descriptors should be annotated with a standard version somehow [MD] Driving use case is where do clients send the links to - so would encourage use of the default vocabs or identify other use cases and their implications [GDF] Striuggling to see other use cases - have semantics and content qualfiier axes and not well defined what to out in there [PD] Mainly an issue of making iot too tied to data products and making it to hard to support other cases [FB] Semantics - relationship of thing in table and link target [FB] Content qualifier/type - about the target itself - seperate from relationship [MD] Should encourage peple in the spec to use the data product type vocab in the content qualifier field but not require it [PD] COncerned about just #something referring to DPT as this biases against other use cases [MD] Longer URIs make it harder to compare if you need to cut away the URI [PD] can treat them as longer string values? [FB] Can we define the default URI in the response rather than the spec? [MD] Still feel that we should focus on the known use case and make it easier [MD] As soon as we have full URI it takes it out of interoperable clients.