`timespans`: inconsistent use of OWL Time ontology terms

[gklyne]

I've been looking at the the example data in README:

    "timespans": [
      {
        "start": {"in":"0676"},"end": {"in":"1066"}
      }
    ]

and the JSON-LD context definitions:

  "when": {"@id": "lpo:when"},
  "timespans": { 
    "@id": "lpo:timespan",
    "@type": "lpo:Timespan", 
    "@container": "@set"
  },
   :
  "start": "time:intervalStartedBy",
  "end": "time:intervalFinishedBy",
  "in": "time:inXSDgYear",
  "earliest": {
    "@type": "time:DateTimeDescription",
    "@id": "lpo:earliest"
  },
  "latest": {
    "@type": "time:DateTimeDescription",
    "@id": "lpo:latest"
  },

and the referenced OWL time ontology at https://www.w3.org/TR/owl-time/

From https://www.w3.org/TR/owl-time/#time:inXSDgYear, the domain of in is time:Instant. Thus, the usage example requires that the range of start includes time:Instant.

But start is time:intervalStartedBy, which per https://www.w3.org/TR/owl-time/#time:intervalStartedBy has domain and range of time:ProperInterval. Further, per https://www.w3.org/TR/owl-time/#time:ProperInterval, time:ProperInterval is disjoint with time:Instant, so the range of start cannot include time:Instant.

Similarly for end.

Thus I believe there is an inconsistency here with the OWL time ontology.

I think the specific example given would work simply by defining in differently in the JSON-LD context, thus:

      "in": "time:year"

Then, the sub-expression {"in":"0676"} would represent a time:ProperInterval corresponding to the given year.

Personally, I think the use of the term in here is an unfortunate name choice, as it makes possible use of other units more awkward. Would it be unreasonable to change the example to use, say:

    "timespans": [
      {
        "start": {"year":"0676"},"end": {"year":"1066"}
      }
    ],

and define year as time:year in the JSON-LD context?

(I was originally mislead by the use of name "in" to think this could be resolved by using time:IntervalContains (https://www.w3.org/TR/owl-time/#time:intervalContains) instead of time:inXSDgYear, and using time:year to define the time period covering the designated year.)

[gklyne]

This is wrong: see next comment

Aargh! I messed up above. Getting confused between dates and intervals in the OWL ontology. I still think the inconsistency exists, but my suggested solution is inconsistent in a different way. Needs more thought, but I think some invocation of the following may be required:

https://www.w3.org/TR/owl-time/#time:DateTimeInterval https://www.w3.org/TR/owl-time/#time:hasDateTimeDescription

[gklyne]

So now I think my proposed solution may be OK, as start == time:intervalStartedBy, which per https://www.w3.org/TR/owl-time/#time:hasDateTimeDescription is a relationship between intervals.

BUT, the JSON-LD context also defines earliest as referring to a time:DateTimeDescription, which doesn't make sense (which is what got me started expecting DateTimeDescriptionvalues above).

Per JSON-LD (http://www.w3.org/TR/json-ld/#typed-values), @type is used to indicate a literal datatype value - this is quite different from an OWL/RDF class (such as time:DateTimeDescription). (See the discussion of value types and node types in the JSON-LD reference above.)

I now realize I had misunderstood the intended use of earliest and latest. I'm not sure if there is an RDF literal datatype defined that includes the newer ISO date options ('%', etc.) - but that is what you want here. A quick fix for now would be to use:

"xsd": "http://www.w3.org/2001/XMLSchema#"
  :
"earliest": {
  "@type": "xsd:string",
  "@id": "lpo:earliest"
},
"latest": {
  "@type": "xsd:string",
  "@id": "lpo:latest"
},

in the context definition, and leave it to an application to figure out what the string literal means based on the property.

Or maybe replicate the structure at https://www.w3.org/TR/owl-time/#time:generalYear with allowance for the additional ISO date syntax options.

[kgeographer]

What about time:inXSDDateTime? (https://www.w3.org/TR/owl-time/#time:inXSDDateTime)

I'm struggling to align this with OWL:Time, and it seems possible, if tricky. A timespan in a when object is a time:ProperInterval, which has lpo:start (time:intervalStartedBy) and lpo:end (time:intervalFinishedBy) time:ProperInterval(s). Each of those time:hasBeginning and time:hasEnd, which must be instants.

In LP format this looks like this:

"start": {"in"|"earliest"|"latest"}, "end": {"in"|"earliest"|"latest"}

So "in", "earliest", and "latest" MUST be a time:Instant. As it happens, a time:Instant can be expressed as an xsd:dateTime (a "Position of an instant, expressed using xsd:dateTime")

The key point here is that a time:Instant is a bad label (imho), because it in fact can translate to temporal expressions that have far greater duration than an "instant" - whatever that is in reality.

So if that makes sense, then "in", "earliest", and "latest" should all correspond to time:inXSDDateTime -- no? (I'm leaving years out, because in case, people will contribute calendar dates -- founding of a polity, e.g.)

[gklyne]

I'm not following your logic in saying:

So "in", "earliest", and "latest" MUST be a time:Instant.

Based on your use of time:intervalStartedBy [1] and time:intervalFinishedBy [2], I would say that in, earliest and latest must be used to define a time:ProperInterval; i.e. the properties used must have that as their domain.

[1] http://www.w3.org/TR/owl-time/#time:intervalStartedBy

[2] http://www.w3.org/TR/owl-time/#time:intervalFinishedBy

I'm also not understanding why you say:

ime:Instant [...] can translate to temporal expressions that have far greater duration than an "instant"

It seems to me that the OWL Time spec is quite explicit that this is not the case [3], and I haven't spotted anything there that contradicts this.

[3] http://www.w3.org/TR/owl-time/#time:Instant

There exists properties time:hasBeginning [4] and time:hasEnd [5] that can relate a time instant to an interval, but using them would require an extra level in your JSON description (unless you define your own property that is a shortcut for a path expression).

[4] http://www.w3.org/TR/owl-time/#time:hasBeginning

[5] http://www.w3.org/TR/owl-time/#time:hasEnd

But I note that time:DateTimeInterval is a subclass of time:ProperInterval,

And the property time:xsdDateTime allows one to specify an interval in terms of a date, which seems to me to be compatible with your intended use of in. I'm not seeing anything like this that corresponds to your use of earliest or latest.

I looked at the defined interval relationships to see if they might be used to similar effect, for example

"intervalStartedBy": { "year": "yyyy" }, "intervalFinishedBy": { "year": "yyyy" }

for

"start": {"earliest": "yyyy"}, "end": { "latest": "yyyy"}

but I'm not seeing anything there that provides the equivalent of

"start" { "latest": "yyyy", ...} 

or

"end": { "earliest": "yyyy", ... }

If I'm not missing something here, then your intended model does seem to lie outside what OWL Time can express. This doesn't mean you have to abandon OWL Time completely, but you will need to define additional properties, which appears to be the intent of your lpo:earliest and lpo:latest.

---

At this point, I feel a need to stand back and think about the intent of:

"start": {"in"|"earliest"|"latest"}, "end": {"in"|"earliest"|"latest"}

and see what additional vocabulary terms could be combined with OWL Time terms to achieve it.

(I think the intent can be captured in OWL time, but not within the simple JSON-LD structure you are proposing; my tentative approach would be to define to terms that are effectively shortcuts for more complex expressions in OWL Time - in that way, your JSON can always be translated to equivalent OWL Time expressions that express the same semantics.)

[kgeographer]

At this point, I feel a need to stand back and think about the intent of:

"start": {"in"|"earliest"|"latest"}, "end": {"in"|"earliest"|"latest"}

and see what additional vocabulary terms could be combined with OWL Time terms to achieve it.

So do I. I don't feel beholden to owl:time personally - it does not account for the circumstance I find in historical data routinely, namely 'not before', 'not after,' etc. Therefore, why shoehorn? PeriodO, which deals specifically with historical time periods, does not. From my very pragmatic viewpoint, it boils down to what software might interact with a data model. In Linked Data world, we are strongly urged to reuse ontologies where possible (a very problematic tack IMO); in Semantic Web world, not so much.

All this suggests to me that a Linked Pasts ontology is an eventuality, with mappings to existing ontologies where possible w/equivalentClass, etc. Unfortunately, I can't take the time from what I'm doing to develop it right now

[gklyne]

I've thought some more about this. My notes are at https://github.com/culturesofknowledge/emplaces/blob/develop/models/20180827-Linked-Pasts-OWL-Time-notes.md

My summary:

While it's possible to capture the intended lpo semantics in the OWL Time ontology, the result isn't pretty, especially if represented in JSON-LD.

Hence, I'd suggest using easier-to-use lpo terms in the JSON-LD context, and maintain the OWL Time mapping, maybe in the form of a set of inference rules, so that information exchange compatiblity with OWL Time can be achieved.

[gklyne]

I just noticed that PeriodO uses OWL Time ontology: The JSON-LD looks like this:

"p05krdxwgcc": {
  "stop": {
    "in": {
      "year": "1950"
    },
    "label": "1950 A.D."
  },
  "start": {
    "in": {
      "year": "1800"
    },
    "label": "1800 A.D."
  },
   :
  "label": "Early Modern Era",
   :
  },
  :
},

Which, in Turtle (using full OWL time terms) looks like this:

<http://n2t.net/ark:/99152/p05krdxwgcc>
    a skos:Concept;
     :
    skos:prefLabel "Early Modern Era";
    time:intervalFinishedBy [
      skos:prefLabel "1950 A.D.";
      time:hasDateTimeDescription [
        time:year <"1950"^^xsd:gYear>
      ]
    ];
    time:intervalStartedBy [
      skos:prefLabel "1800 A.D.";
      time:hasDateTimeDescription [
        time:year <"1800"^^xsd:gYear>
      ]
    ].

But I note that, per the OWL Time ontology, this structure requires the described period to start specifically at the start of 1800, and to end specifically at the end of 1950, which seems to me to be overly prescriptive. Hence the more complex structure in my notes linked from the previous comment.

[rybesh]

But I note that, per the OWL Time ontology, this structure requires the described period to start specifically at the start of 1800, and to end specifically at the end of 1950, which seems to me to be overly prescriptive.

This is an unfortunate effect of the OWL Time ontology revising / clarifying the definition of time:hasDateTimeDescription after PeriodO established its data model. The current version of OWL Time states:

The beginning and end of the interval coincide with the limits of the shortest element in the description.

Which, as you point out, implies that the endpoints of starting and finishing intervals coincide with the endpoints of the year(s) in their descriptions.

However, the current version of OWL Time when we designed the PeriodO data model did not include that clarification. PeriodO tried to take advantage of that looser (2006) definition of time:hasDateTimeDescription precisely in order avoid the implication above:

time:intervalStartedBy links the period to an (anonymous) time interval that has the same (unknown) beginning point as the period, and an (unknown) end point that comes before the end point of the period. We call this the start interval for the period. time:intervalFinishedBy links the period to an (anonymous) time interval that has the same (unknown) end point as the period, and an (unknown) beginning point that comes after the beginning point of the period. We call this the stop interval for the period.

In other words, we did not intend for the description pointed to by time:hasDateTimeDescription to imply anything about the precise start or end of the interval described—and it didn’t, until OWL Time was revised.

One of the reasons we now need to revise the PeriodO data model! (Hopefully in a backward-compatible, non-disruptive way.)