On 21/06/15 17:53, Adrian Gschwend wrote:
On 15.06.15 17:38, Andy Seaborne wrote:
Hi Andy,
Some thoughts:
If you can translate to xsd date/time values, < and > will work.
thanks for the various hints, James Anderson proposed another type to
use (outside of the list), I listed the response here:
https://github.com/OpenTransport/gtfs-csv2rdf/issues/13
"if one takes your description as it stands, you seek to represent a
duration either from midnight or from beginning of service, or some
other point in time which fits your model.
if you use a duration to model exactly that, xsd:dayTimeDuration should
have sufficient capacity and the time of day for a given event would be
the combination of that duration and the start of the respective service
day."
That pretty much matches the semantics of the GTFS specs so that would
be the best solution. I tried to figure out what xsd types are supported
in Jena/Fuseki, is there a reference somewhere?
regards
Adrian
(I have not forgotten your question about Fuseki2 configuration)
ARQ supports all the XSD atomic datatypes, including all the
date/time/duration, but not all the XML related ones (so not sequences,
xsd:NOTATION, XML-specific subtypes of xsd:string).
Durations are helpful if you include the start point of the duration.
Just giving a duration doesn't fix it on the timeline, so it might mean
any day or time. Durations are not the most friendly of lexical forms
however.
But it is adding an extra property so a translated
gtfs:arrivalTimeXSD
which is a proper xsd:datetime for calculation (then considering the
gtfs:arrivalTime as some presentation form akin to an rdfs:label) keeps
you inside unrestricted SPARQL. Well, for the limited xsd:dateTime
support required for comparison, not:
xsd:dateTime - xsd:dateTime => xsd:duration
and it strikes me that how long the journey takes is useful information.
That could be added as well (so not need to calculate in SPARQL) but
waiting time between arriving on one bus and leaving on another is a
calculation or N^2 triples.
Andy
