OWL-Time - issue with SPARQL endpoints lacking owl reasoner

In the new OWL-Time there is a class time:TimePosition which is expected to have one of 

 time:numericPosition - being a number on a time-line, or 
 time:nominalPosition - being a named era from an ordinal reference system

alongside a 

 time:hasTRS - which indicates the reference system that the value relates to. 

time:numericPosition is intended to support things like Unix time (usually an integer or decimal) or geologic or cosmologic time, which could be a very large number. So we want the option of either xsd:decimal (which provides arbitrary precision) and xsd:double (scientific notation). So I created an OWL2 union datatype defined as follows (Turtle notation), and used it for the rdfs:range of time:numericPosition.  

time:Number
  rdf:type rdfs:Datatype ;
  rdfs:comment "Generalized number"@en ;
  rdfs:comment "Note: integer is a specialization of decimal"@en ;
  rdfs:label "Number"@en ;
  owl:equivalentClass [
      rdf:type rdfs:Datatype ;
      owl:unionOf (
          xsd:double
          xsd:float
          xsd:decimal
        ) ;
    ] ;
.

[Note that OWL2 has types owl:real (but no lexical representation) and owl:rational (use xsd:double for the lexical representation), neither of which meets requirements. ]

A colleague has looked at a test dataset in which I had mixed value with types xsd:float and time:Number which should be OK. We ran SPARQL queries including FILTER expressions like 

               FILTER ( ?targetAge > xsd:decimal(?end) )
               FILTER ( ?targetAge < xsd:decimal(?begin) )

My test environment (TopBraid Composer) produced the expected results, but Doug found that for a variety of SPARQL engines that are not OWL2 aware, while the > and < operator succeeded when an xsd:decimal was compared with a xsd:float, they failed when xsd:decimal was compared to a time:Number. 

Are we being too clever? How to satisfy the requirement? 

Simon 

-----Original Message-----
From: Douglas Fils [mailto:dfils@oceanleadership.org] 
Sent: Wednesday, 12 April, 2017 03:56
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
Subject: OWL Time in SPARQL endpoints lacking owl reasoner

Simon,
  We got a response at https://github.com/blazegraph/database/issues/59


   Looks like lacking a reasoner Blazegraph isn’t going to connect time:Number to a concept it can do calculations with.   Adam’s Virtuoso doesn’t even seem to understand XPATH operators so I couldn’t get to the point of seeing if it does or not.   It looks from the docs and net Virtuoso does do some OWL reasoning but it’s not complete.  So whether is has the coverage of operations needed I do not know.  

   I worry that TopBraid is implementing elements that are not perhaps so common in the various SPARQL end points we are seeing in use.  I confess, I don’t have the sample size to back up that statement.   

   If true though, I worry this could limit the use of a graph implementing OWL Time in the wild.   I’ll leave it at that.  You have far more experience and understanding of this than I.  I would be very interested in your views and thoughts on this.

Thanks
Doug

Received on Wednesday, 12 April 2017 03:25:24 UTC