Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporal coverage [RTC] #85

Open
jpullmann opened this Issue Jan 18, 2018 · 13 comments

Comments

7 participants
@jpullmann
Copy link
Contributor

jpullmann commented Jan 18, 2018

Temporal coverage [RTC]

Allow for specification of the start and/or end date of temporal coverage.


Related use cases: Modeling temporal coverage [ID27] 
@stijngoedertier

This comment has been minimized.

Copy link

stijngoedertier commented Apr 19, 2018

As suggested in the use case Modeling temporal coverage [ID27], owl:time can be used. Would the below example be a correct representation of a coverage for the year 2016 and 2018?

@prefix time: <http://www.w3.org/2006/time#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix dcat: <http://www.w3.org/ns/dcat#>.
[] 	a dcat:Dataset;
	dcterms:temporal [
		a dcterms:PeriodOfTime ;
		time:hasTime [
			a time:TemporalEntity ; 
			time:hasBeginning [ time:inXSDDate "2018-01-01"];
			time:hasEnd [ time:inXSDDate "2018-12-31"]
		] ; 
		time:hasTime [
			a time:TemporalEntity ; 
			time:hasBeginning [ time:inXSDDate "2016-01-01"];
			time:hasEnd [ time:inXSDDate "2016-12-31"]
		] 
	].
@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Apr 19, 2018

@stijngoedertier said:

As suggested in the use case Modeling temporal coverage [ID27], owl:time can be used. Would the below example be a correct representation of a coverage for the year 2016 and 2018?

As mentioned in the relevant use case (UC27):

the only relevant example provided in [VOCAB-DCAT] makes use of a URI operated by reference.data.gov.uk, denoting a time interval modeled by using [OWL-TIME]. Such sophisticated representation could be relevant for some use cases, but it is quite cumbersome when the requirement is to specify simply a start / end date, and it makes it difficult to use temporal coverage as a filtering mechanism during the discovery phase.

So, the use case was about defining a more "flat" alternative (which could be nonetheless mapped to the OWL-Time representation), noting that DCAT does not provide guidance, and the current practice (defined in ADMS, and followed by DCAT-AP and related extensions) is to use schema:startDate and schema:endDate.

An additional note about your example, @stijngoedertier : you have specified a dct:PeriodOfTime including multiple, non-contiguous intervals. Although this may be possible in OWL-Time, using this approach to specify multiple intervals may be not fit for the most common DCAT use cases, where the presence of multiple temporal coverages is typically specified with multiple instances of dct:temporal.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Apr 19, 2018

Checking the relevant use case (UC27), I'm not sure about the relevance of some of the mentioned approaches (in particular, DATS and DataCite):

To address this issue, [VOCAB-ADMS] makes use of properties schema:startDate and schema:endDate [SCHEMA-ORG]. [DCAT-AP] follows the same approach. Other existing approaches are: DATS, DataCite and Google datasets

As far as I know, DataCite has no specific element for temporal coverage, and the same seems to apply to DATS (@agbeltran , please correct me if I'm wrong).

On the other hand, the Google's approach outlines another solution not explicitly mentioned so far, namely, specifying the period with a literal (following ISO 8601) and with a datatype property. It is worth noting that this approach cannot be applied with the property used in DCAT, i.e., dct:temporal, which is an object property (so it can be at most a complementary solution).

Coming back to the use case, I think it may be worth providing a brief description of the approach used by Google (and, if relevant, DataCite and DATS).

@stijngoedertier

This comment has been minimized.

Copy link

stijngoedertier commented Apr 23, 2018

Thanks, Andrea. I agree with your feedback that multiple, non-contiguous intervals would require several dcterms:temporal instances. This is probably based on the definition of dcterms:PeriodOfTime, which reads: An interval of time that is named or defined by its start and end dates.

I did not get from the use case that we want a more "flat" alternative, but in this case the Google (schema:temporalCoverage) approach using the ISO 8601 time interval notation indeed makes sense. OWL Time does not seem to have have a property for representing time intervals as a literal like that.

@dr-shorthair dr-shorthair added this to To do in DCAT revision Apr 26, 2018

@aisaac aisaac removed coverage labels May 29, 2018

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Jan 27, 2019

(coming back to this after quite a while...)

@stijngoedertier said:

I did not get from the use case that we want a more "flat" alternative, but in this case the Google (schema:temporalCoverage) approach using the ISO 8601 time interval notation indeed makes sense. OWL Time does not seem to have have a property for representing time intervals as a literal like that.

The problem here (as it is for DCAT-AP) is that schema.org terms and how they are used may change over time (and actually this has happened in this specific case), of course, without being bound to how they are used outside the schema.org community.

So, the main point of this question is whether we should or not define specific properties in the DCAT namespace, so that we can ensure that their possible revision will take into account their actual implementation in the community using DCAT.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

dr-shorthair commented Feb 18, 2019

For time-series datasets, temporal coverage should also be complemented by temporal resolution - see discussion at #84 (comment)

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

dr-shorthair commented Feb 21, 2019

Proposal here: #84 (comment)

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 6, 2019

This issue was discussed by the DCAT subgroup on 6 Mar 2019, and I got an action to make a proposal.

My proposal is that we use the ADMS / DCAT-AP approach (which has already been tested in existing implementations), but define in the DCAT namespace two properties corresponding to schema:startDate and schema:endDate:

  • dcat:startDate, with range xsd:dateTime, xsd:date, xsd:gYear
  • dcat:endDate, with range xsd:dateTime, xsd:date, xsd:gYear

Looking forward to your votes & feedback.

@makxdekkers

This comment has been minimized.

Copy link
Contributor

makxdekkers commented Mar 7, 2019

Why could we not simply re-use the schema.org properties? It seems such a waste to duplicate properties that already exist elsewhere.

andrea-perego added a commit that referenced this issue Mar 7, 2019

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 7, 2019

@makxdekkers , for the issues I personally see in re-using schema.org, see #85 (comment)

Re-summarising the point here:

Schema.org is an evolving vocabulary, and some properties get deprecated or replaced with other ones, based on the requirements of the schema.org community. This is actually what happened with schema:startDate and schema:endDate, which are now replaced by schema:temporalCoverage plus a literal.

So, I think it should be preferable to have something whose stability and revision policy is aligned with the DCAT one.

I would also like to add that these new properties shouldn't pose any backward compatibility issue (otherwise I wouldn't have made the proposal), as they are equivalent of the use of schema:startDate and schema:endDate in ADMS and DCAT-AP.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 7, 2019

I implemented the proposal for you to review via the following PR #807

Preview here:

https://raw.githack.com/w3c/dxwg/andrea-perego-dcat-rev-temporal-spatial-coverage/dcat/index.html#Class:PeriodOfTime

@makxdekkers

This comment has been minimized.

Copy link
Contributor

makxdekkers commented Mar 7, 2019

@andrea-perego I can't find information that schema:startDate and schema:endDate have been replaced by schema:temporalCoverage.
I understand your concern about stability of schema.org semantics, but I would be extremely surprised if the meaning of schema:startDate would change substantially and no longer be a point in time that marks the beginning of some event. I am also not aware that schema.org ever deletes a property -- even when schema.org would deprecate it, it would still remain valid.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 7, 2019

Sorry if I was unclear, but with "replaced" I didn't mean that they have been deleted. What I meant is that now, for expressing temporal coverage, schema.org uses schema:temporalCoverage instead of schema:startDate and schema:endDate.

About the possible semantic changes to start/end date, I tend to agree with you. But, again, there's nothing preventing this from happening if the schema.org community decides so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.