Re: Structured literals - was RE: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

On Thu, Jul 16, 2020 at 11:57:06PM +0000, Cox, Simon (L&W, Clayton) wrote:
> Yes. A GeoSPARQL engine has extra capabilities, to deal with
> geometry operations, which a generic SPARQL engine does not.
> [...]
> A limited set of DateTime handling appears to be built-in to generic
> SPARQL - https://www.w3.org/TR/sparql11-query/#OperatorMapping and
> https://www.w3.org/TR/sparql11-query/#func-date-time It gets a pass
> because xsd:dateTime is inherited from XML. A full TimeSPARQL would
> add the ability to reason against Allen's interval calculus as
> described in OWL-Time [1] and the extension for other relations [2].
> 
> [1] https://www.w3.org/TR/owl-time/ 
> [2] https://www.w3.org/TR/vocab-owl-time-rel/ 

I can see a parallel with Postgresql, which has SQL functions to
manipulate the data stored in a table column with "complex" types
(with complex meaning that it goes further than numbers and strings):
bits, datetime, geometry, network addresses, xml, json, sequences,
arrays, ranges, etc.
https://www.postgresql.org/docs/current/functions.html

Using the Postgis extension to Postgresql you get functions to use
geo-operations in your SQL queries
http://postgis.net/docs/manual-3.0/using_postgis_dbmanagement.html#idm2390

IIUC, any RDF value is a literal, any "relational" value is in a column,
SPARQL and SQL have functions/extensions to manipulate the complex
types packed in literals/columns.

Earlier, you said that the boundary between RDF and Data separates
different domains (logic / other). But GeoSparql is an example that
you may need a single query to do things on both sides at the same
time. Is that boundary as clear as it looks at first sight ? Does it
boil down to "the people that do the design can chose what they want
to put on each side of that boundary" ?

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances

Received on Friday, 17 July 2020 07:34:55 UTC