Although the goal of this message is not to report on that meeting, we do need to note a few points:
Timeline
Running meeting(25/02/2021)
DM meeting - Workshop preparation - collective remarks and minutes Participants 15
The purpose of this meeting is to prepare the DM workshop forseen in April 2021: Workshop goals LM presents the goal of the meeting. Preparation of meeting on data models on VO and how to improve consensus on data modeling generation. Some DMs work well but disagreements on how to match models with scientific quantities. Proposal to solve mapping problems is MANGO, developed by LM Also, proposal from Tom D. to organize a workshop on how to solve this gap Proposed process to prepare the workshop Gather a list of concrete use cases and possible solutions Gather contributions
The dm-usecases repository These use cases is created compiling some VO historical use cases that require data modeling Two folders per use case, raw_data with an annotated xml and another folder with a mango proposal fulfilling the use case Time line for contribution to the use cases repository is during March to allow the pull requests merging of all the contributions poll created on use cases portal: https://github.com/ivoa/dm-usecases/wiki/poll FB: Procedure is to create a branch and ask for a pull request to be merged by LM? yes, either for commenting existing or creating a new use case TM: Lack of consensus are, in my view, due to the level of implementation of the solutions LM: I contacted Mark T. about using data models in Topcat and the problem comes from heteregeneous data modeling annotations in VOTables FG: It is difficult to decide whether to implement before having an idea of the work required to implement This means that the point has to be central to the workshop using the use cases MD: Will implement. If it works for VizieR, it will work for him. TM: Use case for proper motion representation? LM: Yes, in astrometry Mark CD: Orbital models not present, a new use case is needed MD: Not clear if we need models for quantities as this could be solved just with UCDs FB: UCDs are standalone, DM informs about quantities. MD: physics: UCDs, use DM to annotate GL: Mango enables to link two different quantities together, no need to have a specific model for each case. Workshop conduct virtual / in person ? Proposal and decision for a Date
SESSION #2
DM meeting - Workshop preparation - collective remarks and minutes - Second session Participants 8: Laurent Michel, Mireille Louys, Gregory Dubois-Felsmann, Jesus Salgado, Francois Bonnarel, Gerard Lemson, Tom Donaldson, Mark Allen, Harry Enke LM presents objective of propossed workshop and historical background poll created on use cases portal: https://github.com/ivoa/dm-usecases/wiki/poll Use cases page proposed: https://github.com/ivoa/dm-usecases GL: Is there a DM behind all the MANGO annotations? LM: totally free Changes to be done in another branch (to be merged with trunk after review) If a specific model is proposed , a new directory should be inserted Same if a new mapping strategy is proposed
Participants 17 Gerard Lemson, Janet Evans, Mark Cresitello-Ditmar, Tom Donaldson, Laurent Michel, Mark Allen, Francous Bonnarel, Ian Evans, Jean-Mark, Jesus Salgado, Gilles Landais, Jean-Michel Glorian Markus Demleitner, Vicenzo Galluzzi, Stefania Amodeo, Hendrik Heinl, Eric Buchlin This session will allow interested participants to evaluate our proposals with regard to the services they are operating or may need to build in the future. The meeting is OPEN to everyone. One thing we are trying to do though is target scientists/implementors who may consider volunteering to relate their experiences at the Interop Workshop. We envision presenting feedback on the use-case work completed so far, or presenting a vision of where a more mature version of the use case could end up someday. Agenda
Proposals Mark Cresitello Dittmar p (17+3’)
Laurent Michel (17+3’)
François Bonnarel (8+2’) Minutes: Introduction by LM: - Objective on how to use data models into VO and technical ways to share and to implement interoperability using DMs - Use cases: Display Plot Filtering X-Match Data Sharing ...
VODML Overview (Gerard Lemson):
Proposals Mark Cresitello Dittmar Packages: Jovial, Rama (both specific for VO DMs developed mainly by Omar Laurino) and Astropy, MatPlotLib GL: Code to use annotation MCD: Jovial Markus Demleitner
Laurent Michel
F. Bonnarel
Wrap-up
Q/A
Chat dump
Interop Sessions | |||||||||||||
Changed: | |||||||||||||
< < | Session #1 Wednesday May 26 15h UTC Model users have the floor floor Participants 53 Laurent Michel Introduction - Explanation of data model benefits for interoperability - Presentation of data model use cases repository created by the team with examples of mapping techniques - Presentation of goals of workshop Jesus Salgado Data Models: Homogeneous view for heterogeneous data High level, why are we creating data models in the IVOA? - combining data from different missions is difficult and prone to error - serialization o data is only partially standardized IVOA Architecture: - data models are a 'core' component, to be used by multiple aspects of IVOA standards Data Models - visual representation of data elements and relations between them - assist data discover, database design, data documentation and interoperability Photometry example: - everyone uses magnitudes - magnitudes are relative measurements; how do we compare between observatories? - Photometry model associates necessary metadata to properly interpret/compare/combine magnitude data "IVOA DM should be complex enough to allow scientific use cases but simple enough to..." No questions Jean Michel Glorian A developer's point of view on the use of models in the votable - Presentation of CASSIS and use of data models on it - Visualize and analyze electromagnetic spectra. Makes use of SAMP, SSAP, SLAP, TAP (with dataproduct=spectra) EPN-TAP - From the data model point of view: Spectrum, Spectral Line, Spectral Data Cube, Image, Time Series - utype is not enough. Some metadata is not present - annotation could be used to fully characterize the spectrum (spectral axes, error spectral axes,...) - Pointing to the client, link between different columns: flux value-> error flux value, flux value->normalized flux value - In favour of mapping block preamble without breaking VOTable - Also, a library for consuming this preamble would be very useful (e.g. java, python) Questions: LM: A point missing also is the library for sever side MCD: UCDs versus Data models for physics of the meassurements? JMG: based on a fixed table. Sometimes the UCD is not enough and it is difficult to identify when it is really a problem Matthias Fuessling Science case requirement for CTA - Description of use of data models on CTA - CTA covers gamma-ray with two telescopes arrays (La Palma and Chile) - from sub-TeV to multi-TeV - Also different coordination centers across Europe - Open observatory run by proposals - Requirement to follow FAIR protocols and support VO - PB/year, only reduced data to the user (PB/year) - Different data levels: R0, R1, DL0-DL6 (DL6, skymaps, spectra, light curves, phaseograms) - DL3 are event-list and technical tables, and it is one of the scientific products level - DL3 in line with the Open Gamma-ray Astro Data Format (OGADF) - OGADF will evolve in lines with science needs - H.E.S.S. format already have been released via VO - Also, CTA is part of the multi messengers initiatives, in ASTERICS, ESCAPE, connected to VO events, what would need also metadata to be characterized Questions: LM: Meaning of data VO complaint difficult to define MCD: Comparison of Cube DM with gamma-ray data MF: Not sure if this comparison has been done for CTA. All data is usually cubes so we will take a look into it Catherin Boisson: Small test done with high level data (no exactly the same than X-Ray). Plans to do a deeper study François Bonnarel Mango YAML serialisation - Description of used cases - VizieR use case: Photometry of 3 main belt asteroids - Metadata from asteroids, fundamental metadata join with aspects shown - Also, photometric measurements and positions relative to Earth and Sun - Exercise to map all these table and characterize metadata using MANGO - Generic MANGO elements used and Mango extension for TimeSeries created - Serialization in YAML format with MANGO view - FB showing and explaining the YAML file content GDF: Origin of times (zero point) (Use of TIMESYS?) FB: Taken from coordinates for the time (one single float value). Time system defined at the beginning MCD: In the data models, a zero point for time is defined. JD and MJD are defined into the data model (class names) | ||||||||||||
> > | Session #1 Wednesday May 26 15h UTC Model users have the floor floor Participants 53 Laurent Michel Introduction - Explanation of data model benefits for interoperability - Presentation of data model use cases repository created by the team with examples of mapping techniques - Presentation of goals of workshop Jesus Salgado Data Models: Homogeneous view for heterogeneous data High level, why are we creating data models in the IVOA? - combining data from different missions is difficult and prone to error - serialization o data is only partially standardized IVOA Architecture: - data models are a 'core' component, to be used by multiple aspects of IVOA standards Data Models - visual representation of data elements and relations between them - assist data discover, database design, data documentation and interoperability Photometry example: - everyone uses magnitudes - magnitudes are relative measurements; how do we compare between observatories? - Photometry model associates necessary metadata to properly interpret/compare/combine magnitude data "IVOA DM should be complex enough to allow scientific use cases but simple enough to..." No questions Jean Michel Glorian A developer's point of view on the use of models in the votable - Presentation of CASSIS and use of data models on it - Visualize and analyze electromagnetic spectra. Makes use of SAMP, SSAP, SLAP, TAP (with dataproduct=spectra) EPN-TAP - From the data model point of view: Spectrum, Spectral Line, Spectral Data Cube, Image, Time Series - utype is not enough. Some metadata is not present - annotation could be used to fully characterize the spectrum (spectral axes, error spectral axes,...) - Pointing to the client, link between different columns: flux value-> error flux value, flux value->normalized flux value - In favour of mapping block preamble without breaking VOTable - Also, a library for consuming this preamble would be very useful (e.g. java, python) Questions: LM: A point missing also is the library for sever side MCD: UCDs versus Data models for physics of the meassurements? JMG: based on a fixed table. Sometimes the UCD is not enough and it is difficult to identify when it is really a problem Matthias Fuessling Science case requirement for CTA - Description of use of data models on CTA - CTA covers gamma-ray with two telescopes arrays (La Palma and Chile) - from sub-TeV to multi-TeV - Also different coordination centers across Europe - Open observatory run by proposals - Requirement to follow FAIR protocols and support VO - PB/year, only reduced data to the user (PB/year) - Different data levels: R0, R1, DL0-DL6 (DL6, skymaps, spectra, light curves, phaseograms) - DL3 are event-list and technical tables, and it is one of the scientific products level - DL3 in line with the Open Gamma-ray Astro Data Format (OGADF) - OGADF will evolve in lines with science needs - H.E.S.S. format already have been released via VO - Also, CTA is part of the multi messengers initiatives, in ASTERICS, ESCAPE, connected to VO events, what would need also metadata to be characterized Questions: LM: Meaning of data VO complaint difficult to define MCD: Comparison of Cube DM with gamma-ray data MF: Not sure if this comparison has been done for CTA. All data is usually cubes so we will take a look into it Catherin Boisson: Small test done with high level data (no exactly the same than X-Ray). Plans to do a deeper study François Bonnarel Mango YAML serialisation - Description of used cases - VizieR use case: Photometry of 3 main belt asteroids - Metadata from asteroids, fundamental metadata join with aspects shown - Also, photometric measurements and positions relative to Earth and Sun - Exercise to map all these table and characterize metadata using MANGO - Generic MANGO elements used and Mango extension for TimeSeries created - Serialization in YAML format with MANGO view - FB showing and explaining the YAML file content GDF: Origin of times (zero point) (Use of TIMESYS?) FB: Taken from coordinates for the time (one single float value). Time system defined at the beginning MCD: In the data models, a zero point for time is defined. JD and MJD are defined into the data model (class names | ||||||||||||
Session #2 Thursday May 27 15h UTC Model users have the floor floor
Participants: 60 Gilles Landais Annotated VOTable in VizieR - Presentation of VOTable responses from VizieR and annotations
- Example of mapping of radial velocities and associated errors - Photometry viewer implementation using photometry annotations - Analysis of possible MANGO annotated VizieR tables and presentation of prototype - DMs used, Source and Meassure annotations - In order to convert prototype to operational:
Questions: Ada Nebot: ask for link: VizieR mango prototype: 
 http://viz-beta.u-strasbg.fr/viz-bin/Mango?-source=[catalogue_name] Tom D.: in last point, about the need of new provenance. GillesL: For second part to prevent scientists looking for it but for photometry in order to consume it by clients Gilles: I like DataModel when a flat view exists ! (eg: Obscore, photDM) Ian Evans Science considerations for IVOA data models - Expose complex datasets managed by Chandra including sources, detections, ancilliary tables, and many types of FITS data products - Explanatin of complexity on X-ray astronomy data, composed from (x, y, t, PHA) in order to reconstruct photons - X-ray photometry depends on the source spectrum in order to calculate iteratively the real photon meassurement (forward fitting) - CSC makes use of Bayesian X-ray aperture photometry, so multiple detections are solved simultaneously - Optimization done by MCMC (Markov Chain MonteCarlo Chain) - Use of confidence intervals (independent lower and upper confidence limits) - 2nd lesson learned is temporal variability - Individual and multi-epoch data - Many to many relationship between detections and sources - Data models should contain shape and epoch information - IVOA data models can represent X-ray and X-ray source data? - Some changes needed - MANGO provides a good framework for mapping Questions: Kai P: Probability function is needed in general to make proper science Ian E: Yes, for a radial velocity sensor, e.g. PDF are also needed Jean Marc Petit Asteroids: astrometry, photometry, dynamics, survey modelling Different types of data: - Photometry:
- Astrometry:
- Dynamics
- Comparison with models explanation - Question on how to represent metadata needed for orbital estimation Questions: Francois B: How is done the generation of orbital parameters from observational measurements (astrometry)? Jean-Mark: there is a data hierachy from meassurements to the orbital estimator calculation. JJK: what is the data provenance is the question, does it have any? Answer from JM is yes, but the provenance is not expressed in the model we use. Jean-Marc: Fully agree Mark C-D: Comparison of simulated and observed data is a very interesting case to me. Optimally, I think, the data itself could be described by the same model, but with VERY different associated Dataset Metadata, one describing the observation, the other describing the simulation. Does this approach seem feasible for your data? Jean-Marc: Models and real data behaves the same in the orbital simulator. GL: Link between real and simulated data is done through by defining the provenance of both sides (that is different) but trying to find similarities between both metadata AN : I also like this idea of the comparison of simulated and observed data. Same model for both helps for that. I guess that we have an example of something like this in the VOSA service (different context tho), where photometry (observed, collected from different surveys) is compared with synthetic photometry computed from stellar models., the aim is to determine stellar parameters from SED. In this specific science case it would be from positions, time, rvs, get the orbital parameters. Laurent Michel Binding PyVO with MANGO - Presentation of plans to include MANGO support on PyVO - Presentation of basic architectural concepts on VOTable handling in pyVO - MANGO is a container model - MANGO improves view of metadata - Example of elements to annotate VOTable with SpaceFrame, LonLatSkyPosition and ProperMotion (Global and Parameter Dock) - Showing example of MANGO annotation with previous elements - A MANGO parameter could contain different columns (e.g. value, error, frame) - Description of similarities between python dictionary and MANGO
Session #3 Thursday May 28 15h UTC Mapping Syntax
Participants: 41 Laurent Michel Introduction: | |||||||||||||
Deleted: | |||||||||||||
< < | |||||||||||||
- Concepts:
- VO-DML Mapper
- Mapping Meta-Models
- Inspired by object-relational mapping - Explanation of VO-DML mapping, VODML-mapping.xsd - VODML/Model: Model1: xmatch -> Model2: source <- Model-2-sub: sdss-source - GLOBALS: container for "standalone" instances of VO/DML types - ATTRIBUTE - Explanation of the different elements into VO/DML mapping - CONTAINER/FOREIGNKEY Laurent Michel ModelInstanceInVot: alternative or evolution - More focused on the mapping generation than the object-relational mapping - Comparison of the approach of the path from mapping and models - XML elements faith to the model path - Use of dmrole and dmtype - Into the mapping block there are globals and the mapping of the tables included in the document - working draft written on ModelInstanceInVot - Similarities with VO/DML mapping but, also, significant differences Questions: GL: Elements can have structure so mapping is somehow more complex. Also connections from rows is too simplified. Container is very similar Some commonalities, some deviations but close enough to find elements missing LM: JSON can express complex data organizations, so the solution is based on this GL: Some elements in the VO/DML mapping so a different approach would be to evolve the old standard with these ideas Mark Cresitello Dittmar Summary - Impressions of the two approaches comparison - Both support the workshop use cases - Analysis of the Modelinstanceinvot mapping and VODML mapping on the use cases, including possible mapping limitations - Possibility of moving forward by using an hybrid solution Questions: GL: Same problem, elements is more general that attributes. Original idea was to have a very specific tecniques and it could be simplied FB: GROUPBY only have one reference but it can be stacked LM: to get the inputs and prepare summary to be sent to interop GL: question of SourceDM in MANGO LM: MANGO is not a SourceDM but annotations for source Mireille L: Question on the roadmap for a mapping strategy? 60% of simple datasets that can be already mapped. Do we need more complex use cases? TD: Probably mapping syntax is linked to VOTable 2.0 so first would be to ignore the block in the mapping and second the parser AN: If you have multiple tables we should wait to VOTable 2.0 and ensure we do not break backwards compatibility TD: multiple tables are allowed in VOtable but connections not really expressed LM: Internship at CDS to create a TAP that annotates on the fly | |||||||||||||
Changed: | |||||||||||||
< < | DM Workshop Session #4 Wrap up Tuesday 2021 July 13 17h UTC Subject: Zoom meeting invitation - DM Workshop Wrap-Up - Laurent Michel Time : 13 Jul 2021 07:00 PM Paris. (05 PM UTC) Participate to the Zoom meeting Meeting ID : 892 7641 9126 Secret code : 862213 Participants : Laurent Michel, F. Bonnarel, Mark Taylor, Mark Cresitello-Dittmar, Tom Donaldson, JM Glorian, Mireille Louys, Jesus Salgado, Adrian Damian, Gerard Lemson Slides https://docs.google.com/presentation/d/1jvEeLPze750SaAYCUg_BH0Zv6SRW8ocgFI9vkMOEYtI/edit?usp=sharing TD feel >0 Can help for PyVO integration JMG we have to keep in touch TD: how do you validate wrt the xml schemata. votable element / instance ? how do the imports work? LM: shows unit tests on some instances in the mapping examples Separate the parts using name spaces at top of the votable there is a reference to the mapping syntax schema there must be a skip possibility to interpret the mapping , and the votable separately MT : can stiil ignore the mapping part and work with the VOtable part do we need an update of VOtable std? GL : Mapping part can be external to the VOTable, but it points into VOtable Fields for instance TD: how can we keep these parts separated do we want Votable and mapping syntax evolve separately for their future versions ? MT: what happens when the model is changed ? LM: if you rename or if you delete/ remove one attribute or instance JS : how difficult is it for a parser to cope with model changes ? TD: Parsing is relately straightforward depends on the model , more than on the syntax of the original VOTable. Parsing in a model agnostic way is easy but how to use properly this information could be tricky if the model is complex When the exercise for VO/DML was done to create a parser, it took not too long to create the parsing of the preamble propose reference interpretation to understand the problem pragmatically. GL: Also, the mapping tool could be adapted for this new syntax so the annotations are done in a more consistent way so parsing is simplified. MCD; About server side implmentations, obviusly ViZieR would be relevant implementation but we do not expect them to annotate all the catalogues JS: Maybe for luminosities is not so complex as they were already identified by Sebastien Derriere in the past and annotated in a temporary agreed syntax LM : model agnostic translation this was the experience of TD too in presenting syntax comparison in Santiago Topcat does not need the complex model structure to work Spectra tools are more suppposed to cope with Model complexity what if you would have a source model ? Could e.g. topcat/stilts be adapted to make use of the annotations for science use cases? Xmatch use-case : at best can interpret selection boxes, but much interpretation and choices come from the astrononer expertise Topcat does not do automatic conversions using metadata provided by the service. The user always select the information and use if in the way they consider it correct GL : try the Source model for annotation can be done by hand , crowd-source effort , or infered with rules from ucds / units reminder / sharing the merged syntax document Laurent to send the link around TD : how the Votable schema will change : we should clarify this can help to move the process further MT to chek how to interpret a VOtable with two imported schemata GL to test import of one schema?? please confirm , I may have not understood correctly (neither clear to me) chat 18:56:40 From Laurent Michel to Everyone: https://docs.google.com/presentation/d/1jvEeLPze750SaAYCUg_BH0Zv6SRW8ocgFI9vkMOEYtI/edit?usp=sharing 18:56:51 From Laurent Michel to Everyone: 18:57:11 From Laurent Michel to Everyone: 19:09:10 From Mark Taylor to Everyone: good summary of my concerns! 19:30:13 From François Bonnarel to Everyone: concordia.xsd 19:30:17 From François Bonnarel to Everyone: ???* 19:30:49 From Gerard Lemson to Everyone: hi all, sorry for being delayed. 19:31:03 From Mark CD to Everyone: https://github.com/ivoa-std/ModelInstanceInVot/blob/master/schema/xsd/merged-syntax.xsd 19:49:09 From François Bonnarel to Everyone: Where is the etherpad ? 19:54:59 From Jean-Michel Glorian to Laurent Michel(Direct Message): Désolé, je dois partir du zoom. Comme je l'ai dit je n'ai pas eu le temps de regarder tout cela mais je vais essayer de voir ce que je peux faire avec le service de spectre polarbase que je maintiens et avec cassis coté client... Par conrte aucune idée au niveau du planning ... 19:55:10 From Laurent Michel to Jean-Michel Glorian(Direct Message): 19:55:56 From Jean-Michel Glorian to Laurent Michel(Direct Message): tu viens de m'nevoyer le lien à moi directement ... 19:56:08 From Laurent Michel to Everyone: 19:56:27 From Laurent Michel to Everyone: | ||||||||||||
> > | DM Workshop Session #4 Wrap up | ||||||||||||
Added: | |||||||||||||
> > | Workshop overview MAY2021-ws41.pdf Tuesday 2021 July 13 17h UTC
Participants : Laurent Michel, F. Bonnarel, Mark Taylor, Mark Cresitello-Dittmar, Tom Donaldson, JM Glorian, Mireille Louys, Jesus Salgado, Adrian Damian, Gerard Lemson
TD feel >0 Can help for PyVO integration JMG we have to keep in touch TD: how do you validate wrt the xml schemata. votable element / instance ? how do the imports work? LM: shows unit tests on some instances in the mapping examples Separate the parts using name spaces at top of the votable there is a reference to the mapping syntax schema there must be a skip possibility to interpret the mapping , and the votable separately MT : can stiil ignore the mapping part and work with the VOtable part do we need an update of VOtable std? GL : Mapping part can be external to the VOTable, but it points into VOtable Fields for instance TD: how can we keep these parts separated do we want Votable and mapping syntax evolve separately for their future versions ? MT: what happens when the model is changed ? LM: if you rename or if you delete/ remove one attribute or instance JS : how difficult is it for a parser to cope with model changes ? TD: Parsing is relately straightforward depends on the model , more than on the syntax of the original VOTable. Parsing in a model agnostic way is easy but how to use properly this information could be tricky if the model is complex When the exercise for VO/DML was done to create a parser, it took not too long to create the parsing of the preamble propose reference interpretation to understand the problem pragmatically. GL: Also, the mapping tool could be adapted for this new syntax so the annotations are done in a more consistent way so parsing is simplified. MCD; About server side implmentations, obviusly ViZieR would be relevant implementation but we do not expect them to annotate all the catalogues JS: Maybe for luminosities is not so complex as they were already identified by Sebastien Derriere in the past and annotated in a temporary agreed syntax LM : model agnostic translation this was the experience of TD too in presenting syntax comparison in Santiago Topcat does not need the complex model structure to work Spectra tools are more suppposed to cope with Model complexity what if you would have a source model ? Could e.g. topcat/stilts be adapted to make use of the annotations for science use cases? Xmatch use-case : at best can interpret selection boxes, but much interpretation and choices come from the astrononer expertise Topcat does not do automatic conversions using metadata provided by the service. The user always select the information and use if in the way they consider it correct GL : try the Source model for annotation can be done by hand , crowd-source effort , or infered with rules from ucds / units reminder / sharing the merged syntax document Laurent to send the link around TD : how the Votable schema will change : we should clarify this can help to move the process further MT to chek how to interpret a VOtable with two imported schemata GL to test import of one schema?? please confirm , I may have not understood correctly (neither clear to me)
Chat Dump
chat 18:56:40 From Laurent Michel to Everyone: https://docs.google.com/presentation/d/1jvEeLPze750SaAYCUg_BH0Zv6SRW8ocgFI9vkMOEYtI/edit?usp=sharing 18:56:51 From Laurent Michel to Everyone: 18:57:11 From Laurent Michel to Everyone: 19:09:10 From Mark Taylor to Everyone: good summary of my concerns! 19:30:13 From François Bonnarel to Everyone: concordia.xsd 19:30:17 From François Bonnarel to Everyone: ???* 19:30:49 From Gerard Lemson to Everyone: hi all, sorry for being delayed. 19:31:03 From Mark CD to Everyone: https://github.com/ivoa-std/ModelInstanceInVot/blob/master/schema/xsd/merged-syntax.xsd 19:49:09 From François Bonnarel to Everyone: Where is the etherpad ? 19:54:59 From Jean-Michel Glorian to Laurent Michel(Direct Message): Désolé, je dois partir du zoom. Comme je l'ai dit je n'ai pas eu le temps de regarder tout cela mais je vais essayer de voir ce que je peux faire avec le service de spectre polarbase que je maintiens et avec cassis coté client... Par conrte aucune idée au niveau du planning ... 19:55:10 From Laurent Michel to Jean-Michel Glorian(Direct Message): 19:55:56 From Jean-Michel Glorian to Laurent Michel(Direct Message): tu viens de m'nevoyer le lien à moi directement ... 19:56:08 From Laurent Michel to Everyone: 19:56:27 From Laurent Michel to Everyone: | ||||||||||||
| |||||||||||||
Added: | |||||||||||||
> > |
| ||||||||||||