W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2016

Re: geosparql:asWkt feedback from NL

From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
Date: Thu, 28 Jul 2016 18:52:31 +0200
To: Frans Knibbe <frans.knibbe@geodan.nl>
Cc: W3C SDW WG - Public <public-sdw-wg@w3.org>
Message-id: <66d325fa-23ca-0b83-1411-23c23fc5a246@jrc.ec.europa.eu>
On 28/07/2016 17:27, Frans Knibbe wrote:
> On 28 July 2016 at 16:26, Andrea Perego <andrea.perego@jrc.ec.europa.eu
> <mailto:andrea.perego@jrc.ec.europa.eu>> wrote:
>
>     (re-directing this conversation to the SDW mailing list)
>
> Probably a good idea.
>
>     On 28/07/2016 15:41, Frans Knibbe wrote:
>
>         Hi Andrea,
>
>         Yes, it depends what the right level of granularity is. That is
>         why I
>         think it would be good idea to allow some freedom there.
>         Sometimes the
>         right place is a single geometry (if there is only one geometry, for
>         instance), but in other cases distributions, datasets, graphs or
>         classes
>         could be an appropriate level. Having the CRS be a mandatory
>         part of the
>         coordinate string is too restrictive in my opinion.
>
>     I agree about some freedom is needed, in the (inclusive) sense that
>     a CRS can be attached to dataset, distributions as well as
>     geometries. But this does necessarily not mean that if you have a
>     CRS for a dataset, this needs to be excluded from the geometries
>     belonging to it.
>
> That is true. But that does not necessarily mean the CRS reference
> should be part of a literal. In case of a single geometry, the CRS
> reference could be coupled in another way, for instance as a triple if
> the geometry is an object, or in the datatype specification.
>
>
>         [snip]
>
>         Of course the language tag should be used for text only. I think
>         Marco
>         hinted at something similar to language tags. Datatypes could
>         perhaps be
>         used. Datatypes are now assigned to literals to specify that a
>         literal
>         represents a geometry. Perhaps it makes sense to let the data
>         type also
>         identify the CRS? Something like "50 6"^^geo:crs84geometry? The
>         specification of the datatype could then refer to a certain
>         definition
>         of the CRS (a CRS URI), for example an OGC registry.
>
>
>     But in this case you're loosing the information about the geometry
>     serialisation used. So, you know the CRS, but you have to infer how
>     the geometry is encoded.
>
>
> Not if the geometry encoding is also part of the datatype specification.
> Perhaps I could have written  "50 6"^^geo:crs84WKTliteral.

I wonder how this can be addressed, practically. Last time I checked the 
OGC EPSG registry (http://www.opengis.net/def/crs/EPSG/0/), it included 
5,500+ CRSs. If we combine CRSs with /N/ geometry serialisations, should 
the resulting /N/*5,500+ items be recorded in a registry, as RDF 
datatypes / SKOS concepts?

> I more or
> less assumed that the WKT encoding of the coordinates already is a best
> practise.

I think the approach should be consistently applied to all geometry 
serialisations. Otherwise we'll have geometry literals (WKT) where the 
datatype denotes the CRS and others (non-WKT) where the datatype denotes 
the geometry serialisation used.

Andrea

> Regards,
> Frans
>
>
>
>     Andrea
>
>         Greetings,
>         Frans
>
>
>         On 27 July 2016 at 13:57, Andrea Perego
>         <andrea.perego@jrc.ec.europa.eu
>         <mailto:andrea.perego@jrc.ec.europa.eu>
>         <mailto:andrea.perego@jrc.ec.europa.eu
>         <mailto:andrea.perego@jrc.ec.europa.eu>>> wrote:
>
>             Hi, Frans.
>
>             My comments inline.
>
>             On 27/07/2016 12:47, Frans Knibbe wrote:
>
>                 Hi Matt, Josh,
>
>                 Whether or not it makes sense to have a CRS reference be
>         part of
>                 a WKT
>                 literal is a returning point of debate. It has been
>         discussed at
>                 length
>                 in the Locations and Addresses community group. No clear
>                 conclusion was
>                 found, so I would really welcome further discussion.
>
>                 I am in favour of removing the CRS reference from the
>         WKT string
>                 (or any
>                 other geometry datatype). Here are some reasons why:
>
>                  1. A CRS reference should be a URI, not part of a
>         string literal.
>                  2. A geometry is characterised by many attributes
>         (coordinates,
>                     geometry type, level of detail, CRS, number of
>                 dimensions,..). To
>                     conflate all in a single text string would be
>         inflexible.
>                  3. In many cases it makes sense to define a CRS at a higher
>                 level, for
>                     instance for a dataset/graph, or for a class (e.g. class
>                 GeomCRS84).
>
>
>             Well, that's a tricky ground - I mean identifying the right
>         level of
>             granularity.
>
>             Just an example:
>
>             In the GeoDCAT-AP WG there was a discussion on whether the CRS
>             should be specified at the dataset or distribution level
>         (i.e., you
>             may have multiple distributions of the same dataset, each
>         using a
>             different CRS - or different sets of CRSs).
>
>             Eventually, to be in line with ISO 19115, the CRS was associated
>             with the dataset, but without preventing people from
>         specifying CRSs
>             also for distributions.
>
>                  4. It seems to me that GML, GeoJSON and KML are more
>         elaborate
>                 schemes
>                     than WKT, which is a single text string, a data
>         type. So it
>                 makes
>                     more sense for GML, GeoJSON and KML to include some
>         sort of CRS
>                     reference.
>                  5. The orginal WKT did not have a CRS part (although
>         CRS can be
>                     desribed in WKT, but that is another matter).
>
>
>             True, but, besides GeoSPARQL, we have also other examples of CRS
>             included in WKT - as the Extended WKT (EWKT) format used in
>         PostGIS:
>
>
>         http://postgis.net/docs/using_postgis_dbmanagement.html#EWKB_EWKT
>
>             Said that, I'm not against having the CRS out of geometry
>         literal.
>             Only, I don't think we should say if CRSs should be out or
>         in. We
>             can support both the approaches.
>
>             We know how to include the CRS in geometry literals. What is
>         missing
>             is guidance / BPs on how to specify it outside geometry
>         literals.
>
>                 I have to admit it is a not an easy topic. It has to do
>         with the
>                 nature
>                 of geometry: which attributes of a geometry are its
>         intrinsic
>                 parts? Can
>                 a geometry exist as a naked string of coordinates?  I
>         think it can.
>
>                 I see a parallel with text. Take the word "map". You will
>                 probably have
>                 interpreted the word, and probably the interpretation
>         was wrong.
>                 I meant
>                 the Dutch word "map", which means "folder" in English. I
>         should have
>                 written "map"^^nl, that would have prevented the
>         misunderstanding...
>                 This example shows that language is an essential
>         attribute of text
>                 strings. Omitting it causes errors. But still it works in
>                 practice. We
>                 have the freedom to attach languages to text strings, or to
>                 infer the
>                 language from context. I think it would not hurt to have
>         the same
>                 freedom with geometric coordinate strings.
>
>
>             I'm not sure, but I guess your point is about Marco's
>         proposal to
>             specify the CRS as done with language tags.
>
>             If this is the case, I would just like to note that, AFAIK,
>         in RDF a
>             literal is either a plain literal (in such a case you can
>         use the
>             lang tag) or a typed literal (and then you should specify
>         the datatype).
>
>             In GeoSPARQL, :asWKT and :asGML are datatype properties -
>         i.e., take
>             as value typed literals. And so is locn:geometry, when used with
>             geometry literals.
>
>             I'm not aware of examples / proposals to associate both a
>         datatype
>             and a language tag with a literal - although I may see the
>         rationale
>             in relation to having "localised typed literals".
>
>             (Sorry for being pedantic here)
>
>             Cheers,
>
>             Andrea
>
>
>                 Matt's arguments against are valid, of course. Backward
>                 compatibility is
>                 a problem, but not insolvable. And I can imagine that a
>         solution for
>                 triple store management can be found too, with some
>         creative thought
>                 (named graphs for all supported CRSs?). I wonder if
>         modern index
>                 management in triple stores always assumes that all
>         relevant data is
>                 contained in a single triple. What if you would want to
>         have an
>                 index of
>                 names of people, or of toponyms? Some form of distinction
>                 between types
>                 of text strings would be needed. What if a
>         recommendation takes
>                 the form
>                 of having CRS-typed predicates, something like
>         (<ex:geom1234>
>                 <geo:crs84Coordinates> "6 50")?
>
>                 Greetings,
>                 Frans
>
>
>
>                 On 25 July 2016 at 17:03, matthew perry
>                 <matthew.perry@oracle.com
>         <mailto:matthew.perry@oracle.com>
>         <mailto:matthew.perry@oracle.com <mailto:matthew.perry@oracle.com>>
>                 <mailto:matthew.perry@oracle.com
>         <mailto:matthew.perry@oracle.com>
>
>                 <mailto:matthew.perry@oracle.com
>         <mailto:matthew.perry@oracle.com>>>> wrote:
>
>                     Hi Josh,
>
>                     I would be pretty strongly opposed to removing the
>         encoded CRS
>                     reference from wktLiteral.
>
>                     If you look at other formats like GML and GeoJSON, those
>                 geometry
>                     literals include encoded CRS information, and it is
>         implicitly
>                     encoded in KML because there is only one possible
>         CRS. WKT
>                 is really
>                     the only major serialization that lacks CRS
>         information, so
>                 to me it
>                     seems better to add CRS information to WKT so that it is
>                 consistent
>                     with the other serializations instead of depending
>         on some other
>                     property of the geometry that may or may not exist in a
>                 particular
>                     dataset.
>
>                     From a triplestore implementer's point of view,
>         creating a
>                 spatial
>                     index for a GeoSPARQL dataset would be an order of
>         magnitude
>                 harder
>                     if CRS information is not encoded in the geometry
>         literal
>                 itself and
>                     you have to resort to looking for other triples to
>         determine the
>                     CRS, as these triples may be missing and will be updated
>                 over time.
>                     Plus, such a change for GeoSPARQL 1.1 would not be
>         backwards
>                     compatible with GeoSPARQL 1.0, which would cause a
>         lot of
>                 headaches.
>
>                     Thanks,
>                     Matt
>
>
>                     On 7/25/2016 10:30 AM, Joshua Lieberman wrote:
>
>                         Hi,
>
>                         I am a bit concerned about proliferating versions of
>                     geomLiteral
>                         and asWKT properties. It’s a big step already to
>         make a
>                     geometry a
>                         first-class object with a global identifier and
>         all the
>                     management
>                         issues that raises. Others have also noted that
>         queries get
>                         considerably more complicated if one has to peer
>         into
>                     the literals
>                         in order to get the right result. The
>         alternative is to
>                     treat the
>                         asWKT and other coordinate properties as the data
>                     properties they
>                         are, dependent on the geometry object they are a
>         part
>                     of. Then the
>                         coordinate system is defined by the crs property
>         of the
>                     geometry.
>                         It may even be best to remove the CRS reference
>         from the
>                         WktLiteral to improve interoperability between
>         that and
>                     “regular”
>                         WKT that is returned by database functions.
>
>                         Another consideration is to make it easier for
>         software
>                     systems to
>                         provide the right CRS and translate between CRS’s as
>                     needed. One
>                         way might be to negotiate CRS as part of the content
>                     format for
>                         the geometry, as we have proposed for encoding
>         format (e.g.
>                         application/ttl; geomLiteral=“WKT”;
>         crs=“CRS84"). This
>                     at least
>                         doesn’t proliferate encodings or languages.
>
>                         It would also, I think, simplify making queries that
>                     don’t have to
>                         explicitly select a geometry to test spatial
>         relations
>                     or filters
>                         and allow the responding system to select or
>         transform
>                     CRS’s as
>                         needed to process the query.
>
>                         Josh
>
>                             On Jul 25, 2016, at 9:34 AM, Brattinga, Marco
>                             <Marco.Brattinga@ordina.nl
>         <mailto:Marco.Brattinga@ordina.nl>
>                         <mailto:Marco.Brattinga@ordina.nl
>         <mailto:Marco.Brattinga@ordina.nl>>
>                         <mailto:Marco.Brattinga@ordina.nl
>         <mailto:Marco.Brattinga@ordina.nl>
>                         <mailto:Marco.Brattinga@ordina.nl
>         <mailto:Marco.Brattinga@ordina.nl>>>> wrote:
>
>                             Hi Matt,____
>                             __ __
>                             Thanks for pointing us to the geof:getSRID,
>         this is
>                         indeed what
>                             we need for that particular requirement.____
>                             __ __
>                             As for the encoding of CRS: we propose to
>         encode the
>                         CRS into the
>                             language tag, not the datatype. But you
>         could argue
>                         that this
>                             would proliferate the set of languages…____
>                             __ __
>                             Marco____
>                             __ __
>                             *Van:* matthew perry
>                         [mailto:matthew.perry@oracle.com
>         <mailto:matthew.perry@oracle.com>
>                         <mailto:matthew.perry@oracle.com
>         <mailto:matthew.perry@oracle.com>>]
>                             *Verzonden:* maandag 25 juli 2016 15:26
>                             *Aan:* Linda van den Brink;
>                         public-sdw-comments@w3.org
>         <mailto:public-sdw-comments@w3.org>
>                         <mailto:public-sdw-comments@w3.org
>         <mailto:public-sdw-comments@w3.org>>
>                             <mailto:public-sdw-comments@w3.org
>         <mailto:public-sdw-comments@w3.org>
>                         <mailto:public-sdw-comments@w3.org
>         <mailto:public-sdw-comments@w3.org>>>
>                             *CC:* Brattinga, Marco; Veer, Rein van
>                         (Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>
>         <mailto:Rein.vanVeer@kadaster.nl <mailto:Rein.vanVeer@kadaster.nl>>
>                             <mailto:Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>
>                         <mailto:Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>>>); Farla, Joost
>                             (Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>
>                         <mailto:Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>>
>                         <mailto:Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>
>                         <mailto:Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>>>);
>                             Maria, Pano (Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>
>                         <mailto:Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>>
>                         <mailto:Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>
>
>                         <mailto:Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>>>)
>                             *Onderwerp:* Re: geosparql:asWkt feedback
>         from NL____
>                             __ __
>
>                             Hi Linda,____
>
>                             Thanks for forwarding the comments.____
>
>                             One of the downsides of encoding the CRS
>         info into
>                         the WKT
>                             literal is that you can't directly process the
>                         string with
>                             existing WKT tools, but it's pretty trivial
>         to read
>                         a few bytes
>                             and strip the CRS URI off. I would be
>         concerned with a
>                             proliferation of different datatypes if we
>         encoded
>                         the CRS into
>                             the datatype URI. Creating subproperties of
>                         ogc:asWKT seems like
>                             a good, practical approach though.____
>
>                             By the way, GeoSPARQL already defines a
>         function to
>                         return the
>                             CRS of a WKT literal:____
>
>                             *8.7.10 Function: geof:getsrid*____
>
>                             geof:getSRID (geom: ogc:geomLiteral):
>         xsd:anyURI____
>
>                             Returns the spatial reference system URI for
>         geom.____
>
>                             Cheers,
>                             Matt____
>
>                             __ __
>                             On 7/25/2016 3:22 AM, Linda van den Brink
>         wrote:____
>
>                                 Hi all, ____
>                                  ____
>                                 From the developers at the Dutch
>         Kadaster I got
>                         the email
>                                 below, detailing some of the problems
>         they have
>                         with CRS
>                                 detection and selection in the current (web)
>                         standards. They
>                                 also suggest some interesting solutions.
>         ____
>                                  ____
>                                 (sent to the comments list so they can
>                         participate in any
>                                 discussion)____
>                                  ____
>                                 Linda____
>                                  ____
>                                 *Van:* Brattinga, Marco
>                         [mailto:Marco.Brattinga@ordina.nl
>         <mailto:Marco.Brattinga@ordina.nl>
>                         <mailto:Marco.Brattinga@ordina.nl
>         <mailto:Marco.Brattinga@ordina.nl>>]
>                                 *Verzonden:* zaterdag 23 juli 2016 22:49
>                                 *Aan:* Linda van den Brink; Veer, Rein van
>                                 (Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>
>                         <mailto:Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>>
>                         <mailto:Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>
>                         <mailto:Rein.vanVeer@kadaster.nl
>         <mailto:Rein.vanVeer@kadaster.nl>>>);
>                                 Farla, Joost (Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>
>                         <mailto:Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>>
>                                 <mailto:Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>
>                         <mailto:Joost.Farla@kadaster.nl
>         <mailto:Joost.Farla@kadaster.nl>>>); Maria, Pano
>                                 (Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>
>                         <mailto:Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>>
>                         <mailto:Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>
>                         <mailto:Pano.Maria@kadaster.nl
>         <mailto:Pano.Maria@kadaster.nl>>>)
>                                 *CC:* Brattinga, Marco
>                         (Marco.Brattinga@kadaster.nl
>         <mailto:Marco.Brattinga@kadaster.nl>
>                         <mailto:Marco.Brattinga@kadaster.nl
>         <mailto:Marco.Brattinga@kadaster.nl>>
>                                 <mailto:Marco.Brattinga@kadaster.nl
>         <mailto:Marco.Brattinga@kadaster.nl>
>
>                         <mailto:Marco.Brattinga@kadaster.nl
>         <mailto:Marco.Brattinga@kadaster.nl>>>)
>                                 *Onderwerp:* RE: geosparql:asWkt
>         uitdaging icm
>                         CRS-en____
>                                  ____
>                                 Linda,____
>                                  ____
>                                 As you know, at the Dutch Land Registry,
>         we are
>                         currently
>                                 making all our public data available as
>         Linked
>                         Open Data.
>                                 Because most of our data contains a spatial
>                         component, we are
>                                 very interested in the work of the
>         spatial on
>                         the web
>                                 workgroup.____
>                                  ____
>                                 We would like to raise some questions
>         and have the
>                                 opportunity to share our concerns and
>                         experiences.____
>                                  ____
>                                 The situation:____
>                                 -          Our data should not only be
>         available
>                         as Linked
>                                 Open Data, but also as JSON-LD and JSON
>         data via
>                         REST API’s;____
>                                 -          Currently, we store our spatial
>                         information as WKT
>                                 strings;____
>                                 -          Most of the original spatial
>         data is
>                         represented
>                                 as RD (the Dutch CRS, EPSG:28992), and some
>                         geospatial
>                                 experts would really like to use the
>         data in its
>                         original
>                                 CRS;____
>                                 -          But most “regular” webdevelopers
>                         would like to use
>                                 the data as CRS84;____
>                                 -          As far as we know, a
>         “regular” WKT
>                         string doesn’t
>                                 contain a reference to the CRS, and this
>         should
>                         be figured
>                                 out from the context;____
>                                 -          The current geosparql
>         specification
>                         specifies that
>                                 the asWKT object is a WKT string,
>         prefixed with
>                         a CRS,
>                                 represented with its URI name, or –if
>         absent-
>                         CRS84 is
>                                 assumed;____
>                                  ____
>                                 We use the geosparql specification, so a
>                         particular resource
>                                 will have a property
>         geosparql:hasGeometry, with
>                         a reference
>                                 to a resource of the class
>         geosparql:Geometry,
>                         and this
>                                 latter resource has a geosparql:asWKT
>         property,
>                         with a WKT
>                                 string as the object.____
>                                  ____
>                                 Our challenges:____
>                                 -          We like the idea of a separate
>                         geometry. But we
>                                 would like to include multiple
>         WKT-strings, each
>                         with its own
>                                 CRS, just like you would have an
>         rdfs:label with
>                         multiple
>                                 languages;____
>                                 -          The current situation means
>         that we
>                         would have to
>                                 encode the CRS in the WKT-string and
>         that means
>                         that it is
>                                 not really a WKT string any more (which
>         presents
>                         problems if
>                                 we want to use it for our REST API,
>         which users
>                         don’t
>                                 understand the encoding of the CRS);____
>                                 -          Another problem is, that
>         you’ll get
>                         multiple asWKT
>                                 triples, you have to parse the string if you
>                         want to select
>                                 just one of the triples. This is not
>         nice (at
>                         least we would
>                                 like to have a function available, just
>         like the
>                         lang()
>                                 function)____
>                                  ____
>                                 At this moment, we’ve solved the problem by
>                         introducing a
>                                 subPropertyOf asWKT, for every CRS:____
>                                  ____
>                                 pdok:asWKT-RD rdfs:subPropertyOf
>         geosparql:asWKT____
>                                  ____
>                                 Every Geometry in our dataset has one
>                         geosparql:asWKT with a
>                                 WKT string without a CRS (meaning that
>         it should
>                         be CRS84,
>                                 which is fine), and a property pdok:asWKT-RD
>                         with the
>                                 semantics that it also shouldn’t contain
>         a CRS,
>                         because
>                                 EPSG:28992 is assumed. It works and is
>         compliant
>                         to the
>                                 standards, but not very nice.____
>                                  ____
>                                 What we really would like is:____
>                                 -          A more elegant way of
>         encoding the
>                         CRS. Maybe you
>                                 could do it just like a language tag, for
>                         example: <Geo>
>                                 geosparql:asWKT “POINT(53,2
>         5,6)”@EPSG:28992;____
>                                 -          A function to check for a
>         particular
>                         CRS, similar
>                                 to lang(), for example: crs(?wkt) (which
>         would
>                         result a
>                                 literal or maybe a IRI representing the
>         CRS)____
>                                  ____
>                                 Because most spatial encodings can be
>         converted
>                         between each
>                                 other, even a better approach might be
>         to have a
>                                 transformation service
>         (toCRS(?wkt,?crs)).____
>                                  ____
>                                 Last, but not least: it would be very much
>                         appreciated if a
>                                 user could request for a particular CRS,
>         and the
>                         response
>                                 could “tell” what the CRS is. We would
>         like to
>                         suggest using
>                                 http-accept-crs and a crs-content-type
>         kind of
>                         headers, just
>                                 like a language accept-header or a
>         serialization
>                                 accept-header: having content negotiation
>                         available for CRS’s
>                                 as well.____
>                                  ____
>                                 With regards,____
>                                 Marco____
>
>                                 This e-mail and any attachments are
>         confidential
>                         and are
>                                 solely intended for the addressee. If
>         you are
>                         not the
>                                 intended recipient, please notify the
>         sender and
>                         delete
>                                 and/or destroy this message and any
>         attachments
>                         immediately.
>                                 It is prohibited to copy, to distribute, to
>                         disclose or to
>                                 use this e-mail and any attachments in
>         any other
>                         way. Ordina
>                                 N.V. and/or its group companies do not
>         accept any
>                                 responsibility nor liability for any damage
>                         resulting from
>                                 the content of and/or the transmission
>         of this
>                         message.____
>
>
>
>                                 ____
>
>                             __ __
>
>                             Disclaimer
>                             Dit bericht met eventuele bijlagen is
>         vertrouwelijk en
>                             uitsluitend bestemd voor de geadresseerde.
>         Indien u
>                         niet de
>                             bedoelde ontvanger bent, wordt u verzocht de
>         afzender te
>                             waarschuwen en dit bericht met eventuele
>         bijlagen
>                         direct te
>                             verwijderen en/of te vernietigen. Het is niet
>                         toegestaan dit
>                             bericht en eventuele bijlagen te
>         vermenigvuldigen,
>                         door te
>                             sturen, openbaar te maken, op te slaan of op
>         andere
>                         wijze te
>                             gebruiken. Ordina N.V. en/of haar
>                         groepsmaatschappijen accepteren
>                             geen verantwoordelijkheid of
>         aansprakelijkheid voor
>                         schade die
>                             voortvloeit uit de inhoud en/of de
>         verzending van
>                         dit bericht.
>
>                             This e-mail and any attachments are
>         confidential and
>                         are solely
>                             intended for the addressee. If you are not
>         the intended
>                             recipient, please notify the sender and delete
>                         and/or destroy
>                             this message and any attachments
>         immediately. It is
>                         prohibited to
>                             copy, to distribute, to disclose or to use this
>                         e-mail and any
>                             attachments in any other way. Ordina N.V.
>         and/or its
>                         group
>                             companies do not accept any responsibility nor
>                         liability for any
>                             damage resulting from the content of and/or the
>                         transmission of
>                             this message.
>
>
>
>
>
>             --
>             Andrea Perego, Ph.D.
>             Scientific / Technical Project Officer
>             European Commission DG JRC
>             Directorate B - Growth and Innovation
>             Unit B6 - Digital Economy
>             Via E. Fermi, 2749 - TP 262
>             21027 Ispra VA, Italy
>
>             https://ec.europa.eu/jrc/
>
>
>
>     --
>     Andrea Perego, Ph.D.
>     Scientific / Technical Project Officer
>     European Commission DG JRC
>     Directorate B - Growth and Innovation
>     Unit B6 - Digital Economy
>     Via E. Fermi, 2749 - TP 262
>     21027 Ispra VA, Italy
>
>     https://ec.europa.eu/jrc/
>
>

-- 
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/
Received on Thursday, 28 July 2016 16:53:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:24 UTC