Representing time intervals in RDF

[ioggstream]

Question

ISO defines a way to represent time intervals as START_DATE/END_DATE while in cities.ttl we define ~6k TimeIntervals that we then reuse providing further mentions.

Is it possible to identify a way to rely on ISO for date intervals, eg: https://w3id.org/italia/data/time-intervals/1945-10-05/1947-01-09

Note

$ grep  -c time-interval.*TimeI cities.ttl 
6103

[giorgialodi]

In cities we define a class TimeInterval that has startDate and endDate. The one you suggest. So I think it is the same modelling.

The time interval in OntoPiA is defined in TI which is the time ontology that mainly follows the W3C time ontology. I do not see the issue then.

[ioggstream]

Ok, maybe now I understand better: time intervals are just URIs and are not tied to a specific syntax: is that correct?

According to W3C it is perfectly valid to use both https://w3id.org/italia/data/time-intervals/(1945-10-05)-(1947-01-09) and https://w3id.org/italia/data/time-intervals/1945-10-05/1947-01-09 (or some other syntax. I am only just not sure if it's possible to use paths under time-intervals/).

Now the point:

• cities.ttl references time intervals as https://w3id.org/italia/data/time-intervals/(1945-10-05)-(1947-01-09)

This means that even with a proper json-ld context, e.g. see playground

you cannot use ISO8601 parsers to process those dates, and you need to write a custom parser.

[giorgialodi]

Ok, maybe now I understand better: time intervals are just URIs and are not tied to a specific syntax: is that correct?

What do you mean? I don't understand here. The modelling in OntoPiA is that startDate and endDate are properties of a Time Interval (object or class). So in cities we define the class of type TimeInterval that has startDate and endDate and we decided to create the URIs of the TimeInterval objects following the rules for persistent URIs whose final part is the code of reference that we decided to be the combination of the startDate and endDate. Between the the dates we decided to include "-" because it seems better for some software. This https://w3id.org/italia/data/time-intervals/1945-10-05/1947-01-09 does not really follow the rules for persistent URIs that we adopted in OntoPiA. In essence (1945-10-05)-(1947-01-09) would be the code of reference that should be the last part of the URI.

According to W3C it is perfectly valid to use both https://w3id.org/italia/data/time-intervals/(1945-10-05)-(1947-01-09) and https://w3id.org/italia/data/time-intervals/1945-10-05/1947-01-09 (or some other syntax. I am only just not sure if it's possible to use paths under time-intervals/).

Now the point:

* cities.ttl references time intervals as https://w3id.org/italia/data/time-intervals/(1945-10-05)-(1947-01-09)

This means that even with a proper json-ld context, e.g. see playground

you cannot use ISO8601 parsers to process those dates, and you need to write a custom parser.

[giorgialodi]

@ioggstream can we close this issue?

[ioggstream]

If we need to recreate the dataset, I think we can consider iso - based time intervals

[giorgialodi]

It is already iso based. The modelling of the time in OntoPiA is done according to the most important standards regarding the time available at W3C and based on ontology design patterns available in the scientific literature, with iso dates formats. Time interval is a class that then defines the start date and end date (based on iso standard). The start date and end date are boundaries of a time interval, in the time domain. This modelling can be also done in jsonld. So really, I do not see the issue in this specific case. I would close it.

[giorgialodi]

BTW: we cannot change the modelling approach to facilitate later the management with some tools. The modelling of an object like a time interval is usually done as it is in OntoPIA and cities simply materialises with real data that model. Here the reference to the used ontology design pattern - http://www.ontologydesignpatterns.org/cp/owl/timeinterval.owl

[giorgialodi]

@ioggstream I think we can close the issue. The materialisation of the time implements the TI ontology, which is in turn based on existing standards (W3C and ISO for specific properties) for time representation.

[ioggstream]

Ok