Adrian,
Some thoughts:
If you can translate to xsd date/time values, < and > will work.
One approach is to add some custom functions that "casts" the different
way of writing times into something that can be tested.
gtfsFn:timestamp("2015-06-15T25:33:00"^^:customDatatype)
which returns "2015-06-16T01:33:00"^^xsd:dateTime
which is an RDF term that does mao into ARQ's date/time code.
Another approach is like rules: to add properties: this is a post
data-generation expansion (perl or etc will do it).
:bus :departs "25:33:00"^^:customDatatype .
and add
:bus :departsXSD "01:33:00"^^xsd:time .
So "before 09:00am" where 02:00:00 is the end of logical day.
FILTER (?t > "02:00:00"^^xsd:time && ?t < "09:00:00"^^xsd:time)
If "logical day" has overlaps, then it's all going to get a bit weird!
And an off-the-wall solution: fake the timezone. Move the bus times
into +02:00.
Andy
On 15/06/15 13:22, Adrian Gschwend wrote:
Hi,
I'm using Pieter Colpaerts script for transforming GTFS public transport
schedule data to RDF, see
https://github.com/OpenTransport/gtfs-csv2rdf/
According to the GTFS specification arrivalTime and departureTime can
have more than 24 hours to represent connections which are technically
on a new day but before the end of the "daily" public transport
schedule. As an example a bus departing at 01:33 would be listed as
25:33:00.
While this makes sense for what GTFS aims to do it's highly inconvenient
for querying the data with SPARQL. When using SPARQL one wants to be
able to use the FILTER keyword to restrict to time ranges for the
particular query. This is in that form not possible as we cannot assign
standard values like xsd:time to it.
As an example I would like to get all departures after 22:00 on that
particular stop/connection.
I wonder what would be needed to implement a new data type for GTFS
datasets with that particular behaviour. In terms of what would be
needed from a Fuseki/SPARQL point of view and is this a good idea or
not? It clearly will break any other SPARQL endpoint which would not
know how to handle this data type but it would not require hacks on
GTFS2RDF side.
I will collect ideas in this issue:
https://github.com/OpenTransport/gtfs-csv2rdf/issues/13
regards
Adrian
