Re: Issue 27: correction of the description of the Coverage in Linked Data deliverable

+1, good point made.
-Peter


On 2015-10-16 11:27, Jeremy Tandy wrote:
> Jon, Peter ...
>
> on the subject of RDF Data Cubes ... I think that datasets that are
> predictably structured can be represented as an RDF Data Cube; albeit that the
> dimensions of that cube might not relate to geometric or temporal axes. 
>
> Looking at the trajectory 'coverage' as an example ...
>
> - the trajectory (let's call it the sampling feature) is a linear feature
> through four dimensional space
> - let's say we record the variation of 5 physical properties along that
> sampling feature 
>
> ... it's a coverage because we're interested in the variation of those
> properties along the sampling feature
>
> The RDF DataCube can be used to describe the resulting set of values. The
> domain (a 1-dimensional object) is a dimension of the datacube.
>
> I'll agree that the RDF Data Cube is not always going to be the optimal way to
> present this information - but it still has its place. 
>
> Jeremy
>
> On Thu, 15 Oct 2015 at 14:35 Jon Blower <j.d.blower@reading.ac.uk
> <mailto:j.d.blower@reading.ac.uk>> wrote:
>
>     Hi Peter,
>
>     Great, sorry if I was being a pain, but I think we’re in good agreement
>     here, which is great. Hopefully others on this list found the discussion
>     helpful and not too noisy! ;-)
>
>     Still, we have more questions than answers, but that’s OK...
>
>     Best wishes,
>     Jon
>
>>     On 14 Oct 2015, at 18:44, Peter Baumann <p.baumann@jacobs-university.de
>>     <mailto:p.baumann@jacobs-university.de>> wrote:
>>
>>     Hi Jon,
>>
>>     On 2015-10-14 12:23, Jon Blower wrote:
>>>     Hi Peter,
>>>
>>>     Is an irregular polygonal mesh a “grid”? How about a trajectory (e.g.
>>>     ship track)? I would not say so, but others might use terminology
>>>     differently.
>>
>>     sorry if I made this impression - no, an irregular mesh still is a mesh.
>>     I was talking about irregular grids where, in Testbed 11, we spotted
>>     several cases. An irregular grid is characterized by individual
>>     (geometric) distances between the grid points while the underlying
>>     topology still remains a grid, ie: every grid point has its well defined
>>     neighbours.
>>
>>>
>>>     Anyway, I’m not trying to pick nits for the sake of it, I’m trying to
>>>     point out that the coverage world is quite broad. We probably need to
>>>     work out which bits of this world are most relevant to this group, as I
>>>     don’t think we know yet.
>>
>>     Indeed, and I am very willing to describe "coverage world" in detail so
>>     that the group can determine which subset is of relevance.
>>
>>>
>>>     Personally I don’t think we should be equating coverages with datacubes
>>>     (of the RDF variety or otherwise) - the reality is more complicated than
>>>     this.
>>
>>     absolutely so. Datacubes (whether mapped to relations like in ROLAP or to
>>     RDF etc) are one particular direction, and point clouds, meshes, etc are
>>     completely different stuff.
>>
>>>
>>>     I think the definition of a coverage is quite simple - it’s a function
>>>     that maps points in space and time to data values. (The ISO19123
>>>     definition is a bit longer I think but not fundamentally different.)
>>>
>>>     Grids are one way of enabling this mapping, but there are many other
>>>     ways too.
>>
>>     an excellent summary indeed!
>>
>>     -Peter
>>
>>
>>>
>>>     Cheers,
>>>     Jon
>>>
>>>
>>>>     On 13 Oct 2015, at 10:09, Peter Baumann <p.baumann@jacobs-university.de
>>>>     <mailto:p.baumann@jacobs-university.de>> wrote:
>>>>
>>>>     On 2015-10-13 08:54, Jon Blower wrote:
>>>>>>     well, a coverage is a datacube whose axes can be spatial and/or
>>>>>>     temporal. 
>>>>>
>>>>>     This is only true for certain types of coverages. Many others
>>>>>     (curvilinear grids, irregular meshes, polygon-based coverages) don’t
>>>>>     fit this definition.
>>>>
>>>>     you are right, Jon, in that coverages are wider area. Just irregular
>>>>     grids are still grids, hence in datacube world.
>>>>     I thought I focus for simplicity and blank out what's not in scope
>>>>     here, but you caught me ;-)
>>>>
>>>>     -Peter
>>>>
>>>>>
>>>>>     But I agree with your wider point that we need to step back and
>>>>>     consider what our requirements are. I’ve examined QB in a previous
>>>>>     project and am dubious that it has much practical utility for this
>>>>>     kind of thing, but that’s only my view from a certain standpoint. We
>>>>>     need to define what exactly we want to be able to do.
>>>>>
>>>>>     Cheers,
>>>>>     Jon
>>>>>
>>>>>>     On 12 Oct 2015, at 21:41, Peter Baumann
>>>>>>     <p.baumann@jacobs-university.de
>>>>>>     <mailto:p.baumann@jacobs-university.de>> wrote:
>>>>>>
>>>>>>     well, a coverage is a datacube whose axes can be spatial and/or
>>>>>>     temporal. It might be interesting to relate RDF cubes and coverages.
>>>>>>     But again, what do we want to incorporate actually?
>>>>>>     -Peter
>>>>>>
>>>>>>
>>>>>>     On 2015-10-12 01:36, Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>
>>>>>>     wrote:
>>>>>>>
>>>>>>>     I would think that QB[1] (which is derived from SDMX) would have
>>>>>>>     something to contribute here. It is an RDF vocabulary that describes
>>>>>>>     the structure of a datacube, and this provides specific RDF-oriented
>>>>>>>     queries into cells, slices, dimensions of gridded data. Geospatial
>>>>>>>     coverages have the additional feature that one or more of the
>>>>>>>     dimensions is spatio-temporal.
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     My view is that there should be no expectation that whole datasets
>>>>>>>     would have to be transformed and stored following QB, but that
>>>>>>>     subsets can be uniquely identified using QB-bases queries, which
>>>>>>>     would then be transformed into the native query (WCS, SOS, OPeNDAP)
>>>>>>>     and passed on to the hosting service).
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     [1] http://www.w3.org/TR/vocab-data-cube/
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     *From:*Peter Baumann [mailto:p.baumann@jacobs-university.de]
>>>>>>>     *Sent:* Monday, 12 October 2015 8:29 AM
>>>>>>>     *To:* Jon Blower <j.d.blower@reading.ac.uk>
>>>>>>>     <mailto:j.d.blower@reading.ac.uk>
>>>>>>>     *Cc:* Ed Parsons <eparsons@google.com> <mailto:eparsons@google.com>;
>>>>>>>     Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
>>>>>>>     <mailto:Simon.Cox@csiro.au>; frans.knibbe@geodan.nl
>>>>>>>     <mailto:frans.knibbe@geodan.nl>; public-sdw-wg@w3.org
>>>>>>>     <mailto:public-sdw-wg@w3.org>
>>>>>>>     *Subject:* Re: Issue 27: correction of the description of the
>>>>>>>     Coverage in Linked Data deliverable
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Hi Jon,
>>>>>>>
>>>>>>>     exciting questions indeed, you are absolutely right: large portions
>>>>>>>     of the overall issue are independent from "to coverage or not to
>>>>>>>     coverage" (sorry for bending language).
>>>>>>>     What I find particularly interesting is this transition from general
>>>>>>>     data linking into referencing the internals of an object. A coverage
>>>>>>>     is just one particular case, so solving this might open up vistas
>>>>>>>     for other links - into graphs, into documents (I mean: more than
>>>>>>>     just HTML anchors), etc. This is one reason why I am curiously
>>>>>>>     following progress in this group.
>>>>>>>
>>>>>>>     Nite,
>>>>>>>     Peter
>>>>>>>
>>>>>>>     On 2015-10-11 21:06, Jon Blower wrote:
>>>>>>>
>>>>>>>         Hi Peter,
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         I’m not suggesting redefining “coverage”, I’m suggesting that
>>>>>>>         there are interesting questions around the use of coverages in
>>>>>>>         the Linked Data world that aren’t concerned with ISO19123, for
>>>>>>>         example:
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         1. Identifying coverages (hence being able to link to them).
>>>>>>>
>>>>>>>         2. Behaviour of web services that serve coverages (e.g. how can
>>>>>>>         we improve WCS, OPeNDAP, NcSS etc to play more nicely with the
>>>>>>>         wider web?).
>>>>>>>
>>>>>>>         3. Linking between data catalogues and coverage services (e.g.
>>>>>>>         linking between GeoDCAT descriptions and concrete data access
>>>>>>>         services)
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         None of these are within scope for ISO19123, but I believe are
>>>>>>>         interesting problems that this group could help with (and are on
>>>>>>>         my mind at the moment because we need solutions for the MELODIES
>>>>>>>         project).
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         The question of linking *into* coverages (i.e. identifying
>>>>>>>         coverage subsets) probably does involve stuff like ISO19123(-2),
>>>>>>>         because for that we do need some common understanding of what a
>>>>>>>         coverage data structure looks like.
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         By leaping immediately into the ISO19123 world we restrict
>>>>>>>         ourselves unnecessarily to the problem of modelling and encoding
>>>>>>>         coverages, which is certainly relevant but not the only problem
>>>>>>>         that’s pertinent to Linked Data (particularly since there are
>>>>>>>         many other groups covering* some of this).
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         Cheers,
>>>>>>>
>>>>>>>         Jon
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>         * no pun intended
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>             On 11 Oct 2015, at 19:29, Peter Baumann
>>>>>>>             <p.baumann@jacobs-university.de
>>>>>>>             <mailto:p.baumann@jacobs-university.de>> wrote:
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>             Hi Jon-
>>>>>>>
>>>>>>>             several case studies for a range of different areas have
>>>>>>>             been conducted, here a theoretical [1] and an applied one
>>>>>>>             [2] - these are just a few, of course, others have worked on
>>>>>>>             this, too. It is just that the term "coverage" has a
>>>>>>>             particular definition, so we cannot redefine at will if
>>>>>>>             interoperability is among the goals. A clear scientific
>>>>>>>             treatment of terms seems important. Hence, for scientific
>>>>>>>             groundwork I'd suggest to use a neutral term, maybe
>>>>>>>             "pictures" or anything else that appears meaningful and not
>>>>>>>             yet taken.
>>>>>>>
>>>>>>>             cheers,
>>>>>>>             Peter
>>>>>>>
>>>>>>>             [1]  Angelica Garcia, Peter Baumann: /Modeling Fundamental
>>>>>>>             Geo-Raster Operations with Array Algebra/. IEEE
>>>>>>>             international workshop in spatial and spatio-temporal data
>>>>>>>             mining, October 28-31 2007, Omaha, USA
>>>>>>>             [2] Peter Baumann, Maximilian Höfner, Walter Schatz:
>>>>>>>             /Querying Large Geo Image Databases: A Case Study/. IV
>>>>>>>             Brazilian Symposium on GeoInformatics - GeoInfo 2002,
>>>>>>>             December 5-6 2002, Caxambu, Brazil
>>>>>>>
>>>>>>>             (BTW, similar studies have been done for astro and life
>>>>>>>             sciences, too)
>>>>>>>
>>>>>>>             On 2015-10-10 20:31, Jon Blower wrote:
>>>>>>>
>>>>>>>                 Hi all,
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                 I’m relatively new to this group so I don’t know all the
>>>>>>>                 history behind the wording of the Charter but I have
>>>>>>>                 always found this particular requirement to be
>>>>>>>                 prematurely specific. Personally I would be more
>>>>>>>                 comfortable with a requirement along the lines of (in
>>>>>>>                 imprecise language), “We know that a lot of coverage
>>>>>>>                 data are being published and such data pose challenges
>>>>>>>                 for Linked Data approaches. This group will develop
>>>>>>>                 recommendations for making best use of coverage data in
>>>>>>>                 a Linked Data environment.”
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                 From this high-level requirement we need to develop
>>>>>>>                 specific use cases that identify real gaps in the
>>>>>>>                 ecosystem and work out what we can actually do to fill
>>>>>>>                 them, within the scope of this group (and what we defer
>>>>>>>                 to other groups). I don’t think I’ve seen this level of
>>>>>>>                 analysis so far (apologies if I’ve missed something) but
>>>>>>>                 I’d be keen to participate in such an activity.
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                 Personally I don’t see a need to mention ISO19123,
>>>>>>>                 WaterML2, NetCDF or any other specific standard at the
>>>>>>>                 level of this requirement, except perhaps to give
>>>>>>>                 examples of what a coverage is. The following sentence
>>>>>>>                 in the Charter does a good job of highlighting that we
>>>>>>>                 will look at prior art:
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                 "Where deliverables build on prior work, any variance
>>>>>>>                 developed by the Spatial Data on the Web WG will be
>>>>>>>                 backwards compatible with the existing work. The aim is
>>>>>>>                 to formalize existing work, not to replace or compete
>>>>>>>                 with it.”
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                 Just my 0.013p (at current exchange rates).
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                 Jon
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>                     On 10 Oct 2015, at 18:44, Ed Parsons
>>>>>>>                     <eparsons@google.com <mailto:eparsons@google.com>>
>>>>>>>                     wrote:
>>>>>>>
>>>>>>>                      
>>>>>>>
>>>>>>>                     So would a better approach be to have less
>>>>>>>                     specificity in the requirement?
>>>>>>>
>>>>>>>                     Ed
>>>>>>>
>>>>>>>                      
>>>>>>>
>>>>>>>                     On Sat, 10 Oct 2015, 11:41 Peter Baumann
>>>>>>>                     <p.baumann@jacobs-university.de
>>>>>>>                     <mailto:p.baumann@jacobs-university.de>> wrote:
>>>>>>>
>>>>>>>                         yes, indeed ISO will take its time. Once there,
>>>>>>>                         ISO CIS will stay for many years as ISO's
>>>>>>>                         understanding of coverages.
>>>>>>>                         It will be a core decision for the SDW WG
>>>>>>>                         whether to bypass ISO and INSPIRE and establish
>>>>>>>                         a silo solution, or be compatible with the
>>>>>>>                         mainstream.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         -Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         On 2015-10-10 08:13, Simon.Cox@csiro.au
>>>>>>>                         <mailto:Simon.Cox@csiro.au> wrote:
>>>>>>>
>>>>>>>                             Ø  ISO-19123-2 (the soon to be published ISO
>>>>>>>                             version of the OGC Coverage Implementation
>>>>>>>                             Schema 1.1)?
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             ‘soon to be published’ is optimistic.
>>>>>>>
>>>>>>>                             It is not yet on the ISO/TC 211 program of
>>>>>>>                             work [1].
>>>>>>>
>>>>>>>                             The duration from NWIP (New Work Item
>>>>>>>                             Proposal) to IS (International Standard) is
>>>>>>>                             never less than 3 years, even if there is a
>>>>>>>                             mature starting document.
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             [1] http://www.isotc211.org/pow.htm
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             *From:*Frans Knibbe
>>>>>>>                             [mailto:frans.knibbe@geodan.nl]
>>>>>>>                             *Sent:* Friday, 9 October 2015 11:28 PM
>>>>>>>                             *To:* SDW WG Public List
>>>>>>>                             <public-sdw-wg@w3.org>
>>>>>>>                             <mailto:public-sdw-wg@w3.org>; Peter Baumann
>>>>>>>                             <p.baumann@jacobs-university.de>
>>>>>>>                             <mailto:p.baumann@jacobs-university.de>
>>>>>>>                             *Subject:* Issue 27: correction of the
>>>>>>>                             description of the Coverage in Linked Data
>>>>>>>                             deliverable
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             Issue 27
>>>>>>>                             <http://www.w3.org/2015/spatial/track/issues/27>
>>>>>>>                             is a special one, because it is about one of
>>>>>>>                             the deliverables. The Coverage in Linked
>>>>>>>                             Data deliverable
>>>>>>>                             <http://www.w3.org/2015/spatial/charter#cov> reads
>>>>>>>                             "The WG will develop a formal Recommendation
>>>>>>>                             for expressing discrete coverage data
>>>>>>>                             conformant to the ISO 19123 abstract model. ..."
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             Peter explained that this statement probably
>>>>>>>                             requires some adjustment, see this message
>>>>>>>                             <https://lists.w3.org/Archives/Public/public-sdw-wg/2015Apr/0024.html>,
>>>>>>>                             otherwise the deliverable will not have the
>>>>>>>                             proper foundation.
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             Do I understand correctly that is is a
>>>>>>>                             matter of saying that the Recommendation
>>>>>>>                             will not be based on ISO-19123, but on
>>>>>>>                             ISO-19123-2 (the soon to be published ISO
>>>>>>>                             version of the OGC Coverage Implementation
>>>>>>>                             Schema 1.1)?
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             We can not change the charter text, but we
>>>>>>>                             could add a clarification (a note) in the
>>>>>>>                             chapter about deliverables in the UCR
>>>>>>>                             document (Ed, Kerry or Phil: is that correct?).
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             If the assumption above are correct, could
>>>>>>>                             someone suggest a good wording for the note
>>>>>>>                             that should be added?
>>>>>>>
>>>>>>>                              
>>>>>>>
>>>>>>>                             Regards,
>>>>>>>
>>>>>>>                             Frans
>>>>>>>
>>>>>>>                          
>>>>>>>
>>>>>>>                         -- 
>>>>>>>
>>>>>>>                         Dr. Peter Baumann
>>>>>>>
>>>>>>>                          - Professor of Computer Science, Jacobs University Bremen
>>>>>>>
>>>>>>>                            www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>>>>
>>>>>>>                            mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>>>>>>
>>>>>>>                            tel: +49-421-200-3178, fax: +49-421-200-493178
>>>>>>>
>>>>>>>                          - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>>>>>>
>>>>>>>                            www.rasdaman.com <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>>>>>>
>>>>>>>                            tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>>>>>>>
>>>>>>>                         "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>>>>>
>>>>>>>                          
>>>>>>>
>>>>>>>                          
>>>>>>>
>>>>>>>                     -- 
>>>>>>>
>>>>>>>                     *Ed Parsons*
>>>>>>>                     Geospatial Technologist, Google
>>>>>>>
>>>>>>>                     Google Voice +44 (0)20 7881 4501
>>>>>>>                     www.edparsons.com <http://www.edparsons.com/> @edparsons
>>>>>>>
>>>>>>>                  
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>             -- 
>>>>>>>
>>>>>>>             Dr. Peter Baumann
>>>>>>>
>>>>>>>              - Professor of Computer Science, Jacobs University Bremen
>>>>>>>
>>>>>>>                www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>>>>
>>>>>>>                mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>>>>>>
>>>>>>>                tel: +49-421-200-3178, fax: +49-421-200-493178
>>>>>>>
>>>>>>>              - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>>>>>>
>>>>>>>                www.rasdaman.com <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>>>>>>
>>>>>>>                tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>>>>>>>
>>>>>>>             "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>          
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     -- 
>>>>>>>     Dr. Peter Baumann
>>>>>>>      - Professor of Computer Science, Jacobs University Bremen
>>>>>>>        www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>>>>        mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>>>>>>        tel: +49-421-200-3178, fax: +49-421-200-493178
>>>>>>>      - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>>>>>>        www.rasdaman.com <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>>>>>>        tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>>>>>>>     "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>>>>>      
>>>>>>>      
>>>>>>
>>>>>>     -- 
>>>>>>     Dr. Peter Baumann
>>>>>>      - Professor of Computer Science, Jacobs University Bremen
>>>>>>        www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>>>        mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>>>>>        tel: +49-421-200-3178, fax: +49-421-200-493178
>>>>>>      - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>>>>>        www.rasdaman.com <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>>>>>        tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>>>>>>     "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>     -- 
>>>>     Dr. Peter Baumann
>>>>      - Professor of Computer Science, Jacobs University Bremen
>>>>        www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>        mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>>>        tel: +49-421-200-3178, fax: +49-421-200-493178
>>>>      - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>>>        www.rasdaman.com <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>>>        tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>>>>     "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>>
>>>>
>>>
>>
>>     -- 
>>     Dr. Peter Baumann
>>      - Professor of Computer Science, Jacobs University Bremen
>>        www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>        mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>        tel: +49-421-200-3178, fax: +49-421-200-493178
>>      - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>        www.rasdaman.com <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>        tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>>     "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>
>>
>

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)

Received on Friday, 16 October 2015 11:11:39 UTC