Re: CRS specification

Ηι,
I apologize for my late response(s), but I was out of the office for some
time.


>      True, if you only have the literal, e.g. "POLYGON((97372
>>     487152,97372 580407,149636 580407,149636 487152,97372 487152))", you
>>     can not get the CRS. But is that a problem? If you have the triple
>>     you can get the CRS (provided one is specified).
>>
>> You cannot rely on two triples to interpret a single RDF term. See my
>> comment on the formal definition of a datatype. On the other hand, since
>> we adopt the open world assumption we certainly cannot assume that only
>> a single pair of coordinates and CRS will exist in a knowledge base.
>>
>
> This really comes back to the class vs datatype representation issue that
> has already been pointed out by Frans.
>

I do not think that there is a class vs datatype problem. There are many
standards that define different geometry types. For example, the OGC-SFA
standard (WKT), defines a CURVE as an non-instantiable class that is
specialized to the instantiable class LINEARSTRING. In GML however, the
class CURVE is instantiable. For these reason many ontologies about
geometry types can be defined. This is why GeoSPARQL defined two separate
RDFS hierarchies for modeling geometries according to the WKT and GML
standards.

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.


> 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.


> This has some limitations as we already shown in other threads, e.g. 1/
> use of regular expression for some SPARQL queries, 2/ hard-coded
> interpretation of the value if no CRS is provided, i.e. your software
> relies on a default CRS, but this default is not made explicit in the
> vocabulary definition, etc.
>

I am not sure about the first point. Applications need to be prepared for
such cases, similarly to the way that applications catter for the case that
an xsd:float/double has a lexical space that uses a decimal format with
optional scientific notation. My point here is that applications need to be
knowledgeable on how to treat well-defined defined datatypes. Regarding
your second point, I agree in the sense that a geometry must always be
accompanied by a CRS. This is why both GeoSPARQL and stSPARQL have a
default CRS. This is the same for example with the xsd:float/double
datatype that say explicitly scientific notation uses powers of 10 (it
could be 2 or whatever, but it is hard-coded to 10).


> In Frans view (and also mine), a geometry can be a class, that has
> explicit attributes such as a list of coordinates and a CRS. The CRS and
> the set of coordinates are still tied together in the definition of this
> class. Do you see the difference?
>

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.

Cheers,
Kostis

===================================================
Kostis E. Kyzirakos, Ph.D.
Centrum voor Wiskunde en Informatica
DB Architectures (DA)
Office L320
Science Park 123
1098 XG Amsterdam  (NL)
tel: +31 (20) 592-4039
mobile: +31 (0) 6422-95345
e-mail:  kostis@cwi.nl
===================================================