RE: OWL-Time - issue with SPARQL endpoints lacking owl reasoner

Simon, Antoine, Josh,

So +1 to 'when in doubt, cut it out' i.e. anything other than xsd:decimal.

Based on no experience but just Occam's razor.

Chris

> -----Original Message-----
> From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
> Sent: Wednesday, April 12, 2017 2:21 PM
> To: simon.cox@csiro.au
> Cc: antoine.zimmermann@emse.fr; public-sdw-wg@w3.org;
> dfils@oceanleadership.org
> Subject: Re: OWL-Time - issue with SPARQL endpoints lacking owl
> reasoner
> 
> Simon,
> 
> It really remains true that RDF and OWL do a lousy job with numeric
> values, from different value spaces to precision to units. There should
> be bigger answers to to these questions. However, there isn’t any
> present resolution within OWL 2. The only way a literal comparison can
> be made is if two datatypes derive from the same primitive datatype so
> a logical re-casting can be made. The types xsd:decimal, xsd:float, and
> xsd:double are deliberately set as pairwise disjoint to prevent such a
> comparison. We’re down and being kicked too. So the union may combine
> the value spaces of the types, but it doesn’t provide any means of
> overcoming the disjointness. It would only work if, as with coordinate
> string literals, the type you defined were intercepted and re-cast by a
> particular software engine. Maybe we need “NumSPARQL”.
> 
> —Josh
> 
> > On Apr 12, 2017, at 4:28 AM, simon.cox@csiro.au wrote:
> >
> > [Now logged as ISSUE-178 -
> https://www.w3.org/2015/spatial/track/issues/178 ]
> >
> > Very helpful Antoine.
> >
> > 1) clarifies what can be expected from a SPARQL engine (no OWL
> entailments, unless you specifically enable them!)
> >
> > 2) I knew about the XSD story, but not that OWL union datatypes were
> as pointless as you appear to be saying. So looks like TBC is cheating
> somehow. Its doing a good job though - I've tweaked my dataset to mix
> xsd:double, xsd:decimal, xsd:float and time:Number and am getting a
> sensible result. Definitely *not* just a lexical op.
> >
> > 3) but regarding your recommendation, I had more or less reached that
> conclusion already myself. xsd:decimal really is the only type to use -
> it gives arbitrary precision and magnitude, just sometimes a little
> inconvenient when working with the text representation. But since
> literal types are essentially about the serialized/lexical form, there
> are really no shortcuts. (You can probably express this more
> correctly.) (And I won't include the commas in the long numbers. BTW
> ISO standards officially recognize the French notation - comma for
> decimal, period for groups of three in big numbers, but I don't know if
> any computer languages do? )
> >
> > This afternoon I already changed all except time:numericPosition and
> time:numericDuration to xsd:decimal (even before your mail landed). I
> guess I should finish the job.
> >
> > Simon
> >
> > -----Original Message-----
> > From: Antoine Zimmermann [mailto:antoine.zimmermann@emse.fr]
> > Sent: Wednesday, 12 April, 2017 17:33
> > To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdw-
> wg@w3.org
> > Cc: dfils@oceanleadership.org
> > Subject: Re: OWL-Time - issue with SPARQL endpoints lacking owl
> reasoner
> >
> > Simon,
> >
> >
> > I have several remarks wrt to your message concerning:
> >  1) SPARQL engines supporting OWL
> >  2) numeric values in XSD, RDF and OWL
> >  3) precision & scientific notations (also related to your following
> email)
> >
> > ... etc ...
>

Received on Wednesday, 12 April 2017 16:08:00 UTC