Temporal-relations test suite

[dr-shorthair]

A set of RDF resources that can be used to test implementations of OWL-Time

[dr-shorthair]

@nicholascar some resources for an OWL-Time test-suite

[nicholascar]

Cool! We will have to implement similar tests for GeoSPARQL 1.1. now that the bar has been set...

[dr-shorthair]

@tguild @lvdbrink @jabhay please note that some of the resources in these tests are in the namespace http://www.w3.org/2021/time/test/ which may need to be reserved?

[tguild]

Create a placeholder html doc for now and I can publish as a placeholder. We can do content negotiation if we later wish to serve rdf, ttl etc

[dr-shorthair]

@tguild see https://github.com/w3c/sdw/blob/time-test-suite/time/test/index.html

[dr-shorthair]

@nicholascar @HolgerKnublauch could rules to test the temporal relations be written in SHACL?

[nicholascar]

@tguild see https://github.com/w3c/sdw/blob/time-test-suite/time/test/index.html

Better, see https://raw.githack.com/w3c/sdw/time-test-suite/time/test/index.html

[nicholascar]

@nicholascar @HolgerKnublauch could rules to test the temporal relations be written in SHACL?

I suppose they could be but I would personally find it easier to write a demonstration implementation in just SPARQL where I would calculate the time:intervalStarts etc. from the base data (probably all TIME object properties) and then compare the calculated results to each xxx-true.ttl / xxx-false.ttl file by graph comparison. Likely I just don't know how easy it is to embed SPARQL in SHACL or to create custom SHACL functions...

I could implement not a query language implementation though but a tool: an RDFlib extension. There I would simple make a new RDFlib class that calculates TIME relations for given data. It would obviously use the equivalent logic to a demonstration implementation in SPARQL but would use Python code against its own graph objects (faster than translating SPARQL). It would export created properties as graphs so results could be tested with this suite. I could then use this pattern (of a dedicated class) to calculate GeoSPARQL results too in efficient Python spatial toolkit code.

I'd then like to register the implementation here somewhere.

[dr-shorthair]

In the test files I have used only the time:inXSDDateTimeStamp to fix the positions of the time:Instant individuals that define the beginning and end of each time:Interval. So for these tests it is only necessary to find ordering relationships between literals of type xsd:dateTimeStamp (once you've chased down the paths to find them). I think that is built in to SHACL? An advantage of SHACL is explicit error messages.

[nicholascar]

An advantage of SHACL is explicit error messages.

Sure, and TIME validates in SHACL would be useful but you don’t need this test suite in order to create them, just implement the ontology rules!

When I think this test suite will be most useful will be in tool implementation, as per RDFlib. How else other than having test data to work on will we know that the tools are performing correctly?

[chris-little]

@dr-shorthair I am a bit out of my depth here, but why is there ti:ent0-0_1 and ti:ent0-1_1 as well as ti:ent0-0 and ti:ent0-1?

[tguild]

Published the doc

[dr-shorthair]

@chris-little I thought I eliminated those - where did you find them?

[chris-little]

@chris-little I thought I eliminated those - where did you find them?

@dr-shorthair They have now gone. I must have been looking at an earlier commit.