RE: ISSUE-65: General purpose temporal predicates

‘No’ to problematic – sorry I missed the double question.

If a spatial thing has a beginning and/or end and duration, then it is also a temporal entity. Being able to say things about its temporal relationships with other things is the key issue.

Possibly what’s going on here is that I’m understanding the additional possibilities in the set-theoretic/multiple-inheritance viewpoint, compared with the single-inheritance restriction that applies in XML and that we often assume in UML.

From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Sent: Monday, 17 April, 2017 12:46
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
Cc: public-sdw-wg@w3.org
Subject: Re: ISSUE-65: General purpose temporal predicates

Just to clarify: is that no to “problematic” or no to “appropriate”? Can a SpatialThing be-also a TemporalEntity then?

—Josh

On Apr 16, 2017, at 9:46 PM, <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:

The issue I have been struggling with is
(i)                 Are temporal entities (instants, intervals) like geometry models (points, lines, surfaces) – which are associated with a spatial feature, but are not the parent class of spatial feature-types?
(ii)               This affects whether it is OK for the basic temporal predicates :hasBeginning :hasEnd and :hasDuration to have rdfs:domain time:TemporalEntity or not.
This is because, with these global constraints on the domain of the property, anything carrying the property is inferred to be a temporal entity.

Josh had earlier asked:
>  The question in my mind is whether the entailment of "is-also-a temporal entity" is problematic or appropriate in the sense that adding "hasDuration" or "inTimePosition" properties has the effect of adding temporality to an entity such as a spatialthing or geometry. I am trying this out in a "module" of geo -> http://geosemweb.org/stgeo. It still allows defining subproperties such as validTime or making a feature slice or sample a temporal entiity.
>  Joshua Lieberman, 14 Dec 2016, 15:43:28

I did a little more thinking and testing on this, in the form of an OWL-Time – PROV-O alignment, and have decided that the answer to Josh’s question is ‘No’.
If:

prov:Activity
  rdfs:subClassOf time:TemporalEntity ;
.

then we get all the Allen ordering relations between Activities for free. This is kinda the whole point of OWL-Time. I can’t see any down-side on thinking of a prov:Activity (or any other kind of event) as a TemporalEntity and getting to reason over ordering relations directly.

So I propose to reverse the decision made in the mail below, and re-instate the domain restrictions on :hasBeginning :hasEnd and :hasTemporalDuration (this returns us to the 2006 definitions), and assert that these predicates _are_ the general purpose ones requested in ISSUE-65. The only addition is :hasTime which is even more general purpose.

Sorry about the whiplash folks.

Simon

From: Cox, Simon (L&W, Clayton)
Sent: Wednesday, 5 April, 2017 17:35
To: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: OWL-Time - utility predicates

This relates to ISSUE-65 and ISSUE-64.

If you’ve been following this thread you would be aware that we’ve been attempting to resolve the issue of
(a)   Whether the global constraints (domain, range) on all the properties in OWL-Time should be relaxed
(b)   Provision of some general purpose predicates for use in external applications, to provide temporal properties to resources without onerous entailments.

After flipping back and forth on this a bit, I now propose to resolve these issues simultaneously using the following approach:

1.      Remove the rdfs:domain constraints on :hasBeginning :hasEnd :hasTemporalDuration (and its sub-properties :hasDuration and :hasDurationDescription)
2.      Introduce a new property :hasTime with rdfs:range :TemporalEntity
3.      Cancel the proposed new properties :activity(Beginning,End,Duration,Time) since they would no longer be necessary.

This means that the :has* predicates would no longer entail that the subject is a :TemporalEntity. The issue here is that :TemporalEntity is conceived of as a kind of ‘temporal geometry’ whose relationship with ‘temporal features’ (events) is not fully clear (spatial geometry is clearly disjoint with spatial thing, but not so clear for temporal geometry - see previous discussion with Josh Lieberman). Relaxing the global constraint provides the flexibility to allow external applications to use these predicates with a reduced ontological commitment. Or maybe it’s just kicking the can down the road, but I think harmlessly.

Anyway, I’ve implemented this change and pushed to the GitUb branch where I have been working this through - https://github.com/w3c/sdw/tree/simon-time-predicates/time which is the subject of a pull-request to integrate this into the main branch  https://github.com/w3c/sdw/pull/630


Please comment on this by 12 April (one week’s time) so I can integrate.

Simon

Simon J D Cox
Research Scientist
Environmental Informatics
CSIRO Land and Water<http://www.csiro.au/Research/LWF>

E simon.cox@csiro.au<mailto:simon.cox@csiro.au> T +61 3 9545 2365 M +61 403 302 672
   Mail: Private Bag 10, Clayton South, Vic 3169
   Visit: Central Reception, Research Way, Clayton, Vic 3168
   Deliver: Gate 3, Normanby Road, Clayton, Vic 3168
people.csiro.au/Simon-Cox<http://people.csiro.au/Simon-Cox>
orcid.org/0000-0002-3884-3420<http://orcid.org/0000-0002-3884-3420>
researchgate.net/profile/Simon_Cox3<https://www.researchgate.net/profile/Simon_Cox3>
github.com/dr-shorthair<https://github.com/dr-shorthair>

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.