@prefix dc: . @prefix dcat: . @prefix dct: . @prefix owl: . @prefix rdf: . @prefix rdfs: . @prefix skos: . @prefix tempo: . @prefix vann: . @prefix xsd: . a owl:Ontology ; dc:abstract """TempO is a lightweight ontology for describing temporal validity and efficacy according to a tritemporal data model. For pragmatic reasons, keeping track of system time (also known as transaction time) is left to other ontologies or external systems such as git, or transactional extensions of the database."""@en ; dc:creator "Sebastian Freundt"^^xsd:string ; dc:description """In a typical (uni)temporal data model every resource's appearance (and disappearance) is being tracked. Numerous systems accomplish unitemporal tracking, either externally by e.g. using git to record the insertion or deletion of a resource, or internally by e.g. using prov:generatedAtTime and prov:invalidatedAtTime. This axis of time is known as *system time*, and none of TempO's concern because for one there is readily available support, and moreover because unitemporal tracking is used for principally true statements, i.e. those that have always been (considered) true or will always be (considered) true. TempO addresses bitemporal and tritemporal setups: Resources which are (known or believed to be) valid and efficacious for some time. A second time axis orthogonal to system time is introduced, that is a resource can be valid even though it is currently not in the system, or, conversely, can be already or still invalid by the time it enters the system. Efficacy, sometimes called decision time, is yet another concept orthogonal to validity, i.e. a resource that is no longer or not yet valid can be efficacious. The converse, a valid but inefficacious resource in the system, is *usually* not encountered but TempO does not impose restrictions on the shape of the time area. In general the necessity for tracking both validity and efficacy arises in areas where concepts are assigned a code or label that is subject to reuse following invalidation. Tracking efficacy and validity concurrently then allows for fine-grained control over how much future knowledge or how much past knowledge we tolerate in a datset. Example: -------- Czechoslovakia was founded in 1918 but became part of Germany, Hungary and Poland in 1938. It was reestablished in 1945 but split into two sovereign states in 1993. The ISO 3166 country code for Czechoslovakia used to be 'CS', assigned in 1974, published in February 1978, and invalidated with the country's split. In 2003 ISO 3166 reassigned the country code 'CS' to Serbia and Montenegro. The facts were assembled in 2018 and written down as follows: cc:CSHH a cc:ISO3166-CountryCode ; rdfs:label \"CS\" ; cc:refersTo \"Czechoslovakia\" ; prov:generatedAtTime \"2018-02-29T04:00:00Z\"^^xsd:dateTime . tempo:validFrom \"1978-02\"^^xsd:gYearMonth ; tempo:validTill \"1993-01-01\"^^xsd:date ; tempo:efficaciousFrom \"1918\"^^xsd:gYear , \"1945\"^^xsd:gYear ; tempo:efficaciousTill \"1938\"^^xsd:gYear , \"2003\"^^xsd:gYear . The use of the country code 'CS' in a statement from 1988 can be resolved to cc:CSHH, as of today, free from ambiguity; it was valid back then after all and we know that today. The same query in 2017 (point-in-time query) would have yielded no results because the information hadn't been in the system back then. Point-in-time queries, however, are not TempO's major concern so only as-of-today queries are assumed from now on. Following the country's split it is highly likely that news reports from, say, 1994 highlighting the then-recent past would still have used 'CS' to refer to cc:CSHH. According to the resource this is possible, a query for 'CS' in 1994 would bring up cc:CSHH as it is efficacious but marked as invalidated. On the other end of history, the use of the code 'CS' in, say, 1976 is plausible. The code was decided on but not yet formally published. A query for 'CS' as used in 1976 would bring up cc:CSHH, marked as anachronistic. Going back further, a statement from, say 1942, using the code 'CS' must clearly refer to something else. A query for 'CS' as used in 1976 would yield not yield any results. -- The ontology IRI http://purl.org/tempo/ always resolve to the latest version of TempO. Particular versionIRIs such as http://purl.org/tempo/0.1/ can be used by clients to force the import of a particular version. The goal of TempO is to allow for temporal constraints with control over how much future or past is permissible directly on the published resource, and as such, TempO does not restrict domain/ranges."""@en ; dcat:downloadURL , ; dct:creator ; dct:format "text/turtle"^^xsd:string ; dct:issued "2022-05-26T05:00:00Z"^^xsd:dateTime ; dct:language "en"^^xsd:language ; dct:license ; dct:modified "2022-08-20T05:19:00Z"^^xsd:dateTime ; dct:publisher ; dct:title "TempO - Temporal Ontology"@en ; owl:versionIRI ; owl:versionInfo "0.1"^^xsd:string ; rdfs:seeAlso ; vann:preferredNamespacePrefix "tempo"^^xsd:string ; vann:preferredNamespaceUri "http://purl.org/tempo/" . tempo:TemporalConstraint a owl:Class ; rdfs:comment """Temporal constraint box to capture a consistent set of validity and efficacy intervals. Objects of this class also serve the purpose to capture additional constraints or annotations, in particular when they are also temporally constrained. Example ------- ccy:EUR a ccy:ISO4217-CurrencyCode ; ccy:usedIn cc:DE , cc:GR ; rdfs:label \"EUR\" ; tempo:constrainedBy [ a tempo:TemporalConstraint ; tempo:validFrom \"1999-01-01\"^^xsd:date ; ccy:usedIn cc:DE ; ] , [ a tempo:TemporalConstraint ; tempo:validFrom \"2001-01-01\"^^xsd:date ; ccy:usedIn cc:GR ; ] . meaning the currency code 'EUR' became valid in Germany in 1999 whereas in Greece it became valid in 2001."""@en ; rdfs:label "Temporal Constraint"@en ; rdfs:seeAlso tempo:constrainedBy . tempo:constrainedBy a owl:ObjectProperty ; rdfs:comment """A temporal constraint associated with this resource."""@en ; rdfs:isDefinedBy ; rdfs:label "constrained by"@en ; rdfs:range tempo:TemporalConstraint ; rdfs:seeAlso tempo:TemporalConstraint . tempo:efficaciousFrom a owl:AnnotationProperty ; rdfs:comment """The date or time when this resource becomes efficacious. If omitted the resource is said to be efficacious in the past from a tempo:efficaciousTill's point of view. If neither is present the resource is said to be forever efficacious. A resource might not exist yet or have ceased to exist during its efficacy, Use tempo:validFrom/tempo:validTill to track validity. Example ------- The Federal Republic of Germany was formed on 1949-05-23. In 1974 ISO 3166 assigns the country code 'DE' to Germany. With today's knowledge it is safe to assume that no other country would have been assigned the country code 'DE' so we use information from the future to roll out the efficacy of the code into the past: cc:DE a cc:ISO3166-CountryCode ; rdfs:label \"DE\" ; cc:refersTo \"Germany\" ; tempo:validFrom \"1974\"^^xsd:gYear ; tempo:efficaciousFrom \"1949-05-23\"^^xsd:date . With this resource, a consumer of the dataset may safely liken the ccTLD '.de' to the country Germany as long as the temporal context is not older than 1949-05-23, while at the same time being aware that uses of the country code before 1974 are anachronistic. The notes about incomplete date or time types and mixing different date or time types in intervals made up from tempo:efficaciousFrom/tempo:efficaciousTill values as outlined in tempo:validFrom apply to efficacy annotations too. However, seeing as efficacy and validity are orthogonal concepts it is permissible to use incomplete date or time types on the efficacy axis different from the ones used on the validity axis. Example ------- It is up further clarification whether in this resource: ex:XY rdfs:label \"XY\" ; tempo:validFrom \"2004-08-02\"^^xsd:date ; tempo:efficaciousFrom \"2004-08\"^^xsd:gYearMonth . the use of ex:XY's label on 2004-08-01 is anachronistic (use before its validated life-span) or illegal (use before efficacy)."""@en ; rdfs:isDefinedBy ; rdfs:label "efficacious from"@en ; rdfs:seeAlso tempo:efficaciousTill , tempo:validFrom . tempo:efficaciousTill a owl:AnnotationProperty ; rdfs:comment """The date or time when this resource becomes inefficacious. If omitted the resource is said to be efficacious in the future from a tempo:efficaciousFrom's point of view. If neither is present the resource is said to be forever efficacious. A resource might not exist yet or have ceased to exist during its efficacy, Use tempo:validFrom/tempo:validTill to track validity. Example ------- The country code for Czechoslovkia had been 'CS' until 1993 when Czechoslovakia divided into Czechia and Slovakia. In 2003 then-Yugoslavia changed its name to Serbia and Montenegro, the ISO 3166 assignment is 'CS'. cc:CSHH a cc:ISO3166-CountryCode ; rdfs:label \"CS\" ; cc:refersTo \"Czechoslovakia\" ; tempo:validFrom \"1974\"^^xsd:gYear ; tempo:validTill \"1993\"^^xsd:gYear ; tempo:efficaciousTill \"2003\"^^xsd:gYear . With this resource, a consumer of the dataset may safely attribute any occurrence of the label 'CS' before 2003 to Czechoslovakia. A point in time in tempo:efficaciousTill is always exclusive. See tempo:validTill for further explanation and implications."""@en ; rdfs:isDefinedBy ; rdfs:label "efficacious till"@en ; rdfs:seeAlso tempo:efficaciousFrom , tempo:validTill . tempo:validFrom a owl:AnnotationProperty ; rdfs:comment """The date or time when this resource becomes valid. If omitted the resource is said to be valid in the past from a tempo:validTill's point of view. If neither is present the resource is said to be forever valid. A resource can be formally invalid and yet efficacious, like the future name of an unborn baby can be used to refer to the baby during pregnancy knowing that a birth certificate with this name will exist one day. Use tempo:efficaciousFrom/tempo:efficaciousTill to track efficacy. There are no restrictions on the multiplicity of tempo:validFrom. A resource can be valid during a number of non-overlapping time periods (intervals) which implies that multiple tempo:validFrom's can be ordered chronologically and paired with a chronological ordering of tempo:validTill's such that there is an alternating sequence of elements from the validFrom set and the validTill set with respect to chronologicity. Example ------- The resource [] tempo:validFrom \"1998-01-01\"^^xsd:date , \"2004-01-01\"^^xsd:date ; tempo:validTill \"2001-01-01\"^^xsd:date , \"2008-01-01\"^^xsd:date . is valid during the union of the intervals [1998-01-01, 2001-01-01) and [2004-01-01, 2008-01-01). Note: the textual order cannot be preserved so this resource [] tempo:validFrom \"1998-01-01\"^^xsd:date ; tempo:validTill \"2008-01-01\"^^xsd:date ; tempo:validFrom \"2004-01-01\"^^xsd:date ; tempo:validTill \"2001-01-01\"^^xsd:date . conveys the same validity statement as above. Example ------- Omission of the time value for the most distant point in the past and/or the most distant point in the future mandates this resource [] tempo:validFrom \"2004-01-01\"^^xsd:date ; tempo:validTill \"2001-01-01\"^^xsd:date . to be interpreted as valid in [-infinity, 2001-01-01) u [2004-01-01, infinity), i.e. invalid during [2001-01-01, 2004-01-01). Illegal example --------------- The following resource [] tempo:validFrom \"1998-01-01\"^^xsd:date , \"2000-01-01\"^^xsd:date , \"2004-01-01\"^^xsd:date ; tempo:validTill \"2001-01-01\"^^xsd:date , \"2008-01-01\"^^xsd:date . does not convey proper validity information because 1998-01-01 would have to be paired with 2001-01-01 chronologically whilst alternatingly choosing from the 'from' and 'till' sets but [2000-01-01, 2008-01-01), interval next in line, overlaps with the first interval, i.e. there is a point in time that is invalid according to the first interval, to wit 2001-01-01, but at the same time valid according to the second interval. The use of incomplete date or time types is generally up to further clarification. As far as temporal logic and constraints in TempO are concerned, a value of, say, \"1999-02\"^^xsd:gYearMonth is interpreted as \"at some point in February 1999\". All of these points are considered equivalent as long as all values in tempo:validFrom (and paired up corresponding values in tempo:validTill) use the same scale. Using different date or time types is generally discouraged in situations where the coarser scale's value contains points before and after the finer scale's value. That is the following is permissible [] tempo:validFrom \"2019\"^^xsd:gYear ; tempo:validTill \"2022-02\"^^xsd:gYearMonth . whereas [] tempo:validFrom \"2019\"^^xsd:gYear ; tempo:validTill \"2019-02\"^^xsd:gYearMonth . is discouraged. """@en ; rdfs:isDefinedBy ; rdfs:label "valid from"@en ; rdfs:seeAlso tempo:validTill . tempo:validTill a owl:AnnotationProperty ; rdfs:comment """The date or time when this resource becomes invalid. If omitted the resource is said to be valid in the future from a tempo:validFrom's point of view. If neither is present the resource is said to be forever valid. A resource can be formally invalid and yet efficacious, like an expired passport can be used still to identify a person. Use tempo:efficaciousFrom/tempo:efficaciousTill to track efficacy. There are no restrictions on the multiplicity of tempo:validTill. A resource can be valid during a number of non-overlapping time periods (intervals) which implies that multiple tempo:validTill's can be ordered chronologically and paired with a chronological ordering of tempo:validFrom's such that there is an alternating sequence of elements from the validTill set and the validFrom set with respect to chronologicity. See tempo:validFrom for an example. A point in time in tempo:validTill is always exclusive. Combined with the policy about omissible far-in-the-future and far-in-the-past time points this implies that the resource [] tempo:validFrom \"2009-09-09\"^^xsd:date ; tempo:validTill \"2009-09-09\"^^xsd:date . is to be interpreted as valid in [-infinity, 2009-09-09) and valid again in [2009-09-09, infinity), or in other words forever-valid. There is no way to encode that a resource is valid only at exactly one point in time or during an infinitesimally small period of time. The use of incomplete date or time types is generally up to further clarification. As far as temporal logic and constraints in TempO are concerned, a value of, say, \"1999-02\"^^xsd:gYearMonth is interpreted as \"at some point in February 1999\". All of these points are considered equivalent as long as all values in tempo:validTill (and paired up corresponding values in tempo:validFrom) use the same scale. Using different date or time types is generally discouraged in situations where the coarser scale's value contains points before and after the finer scale's value. That is the following is permissible [] tempo:validFrom \"2019\"^^xsd:gYear ; tempo:validTill \"2022-02\"^^xsd:gYearMonth . whereas [] tempo:validFrom \"2019\"^^xsd:gYear ; tempo:validTill \"2019-02\"^^xsd:gYearMonth . is discouraged. """@en ; rdfs:isDefinedBy ; rdfs:label "valid till"@en ; rdfs:seeAlso tempo:validFrom .