Re: CRS specification

Hello Kostis,

> So essentially, *both* a class and a datatype representation is needed.
> The datatype representation is used for the serialization of the
> geometry while the class representation provides you the vocabulary to
> say more things about the spatial features e.g., assign an ex:length
> (assume ex defines an example namespace) data property for linestrings,
> an ex:area data property for 2D polygons and so on. My main point is
> that the locn vocabulary should not deal with the serialization of
> geometries. Instead, it should contain just some part that can glue
> together the locn vocabulary with existing (or even future) relevant
> standards.

We are essentially saying the same thing, which is good :-) I'm all for 
not re-inventing the wheel of course. Which vocabulary would you suggest 
to use for representing the geometry? GeoSPARQL? NeoGeo?

The original problem that has triggered this thread (see the subject) 
still remains: if none of these existing geometry vocabularies enable to 
specify a particular CRS, why locn should not be able to include such a 
predicate?

>     In your view, if I understand well, you want the geometry value to
>     be of a (complex) datatype, therefore, putting the CRS information
>     *and* the coordinates into a literal that needs to be (correctly)
>     parsed to be used.
>
> I agree with you on this. But how can we do this in RDF? In RDF we
> cannot define complex datatypes, so we either have to define complex XML
> elements using XML schema or use OWL 2 to define such a datatype. In any
> case we are "abandoning" the plain RDF world. This is why my opinion is
> that we should encode both CRS and coordinates into a single typed
> literal of a properly defined datatype.

Sorry, the word "complex datatype" is unfortunate. I didn't mean in the 
XML Schema way. What I meant was that it is perfectly fine to describe 
in RDF a resource (an instance of a class) which is defined with a 
restriction to that it contains a "ex:CRS" property and a 
"ex:coordinates" property. The value of the CRS property could be a URI 
such as http://www.opengis.net/def/crs/OGC/1.3/CRS84 while the value of 
the coordinates property could either be a literal or a 
Polygon/LinearRing, etc.

> I do not say that a geometry cannot be modeled as a class. On the
> contrary! There should be hierarchies about geometry types. I am arguing
> however that a pre-defined set of datatypes (WKT and GML at the moment)
> must be used for the encoding the serialization of a geometry, thus
> allowing SPARQL extension functions to handle multiple types of geometry
> as input/output.

If we replace your MUST by COULD or even SHOULD, then I agree with you. 
Basically, a useful vocabulary should definitively let people to 
represent a geometry in WKT, GML, KML, GeoJSON, etc. but could also 
allow other ways of defining the geometry. This is more or less the 
approach of NeoGeo by the way.
Best regards.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Campus SophiaTech
Multimedia Communications Department
450 route des Chappes, 06410 Biot, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Saturday, 18 January 2014 16:10:18 UTC