RE: OWL-Time - utility predicates

Hi, Simon.

+1 from me to your proposal.

Actually, I wonder whether also the range can be dropped from :hasBeginning and :hasEnd, to allow literal values. The use case is the one I outlined here, about expressing temporal coverage of a dataset:

https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0158.html

I think there'll be also other use cases where the specification of an interval can be preferably done with literal values, whereas modelling start and end date with an instance of class time:Instant would not be necessary and/or too cumbersome.

These two options would also be aligned with what discussed in the BP document about geometries - depending on your use case, you can model it with a literal or with more structured representations (in RDF, GML, etc.).

Thanks in advance

Andrea

----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

________________________________
From: Simon.Cox@csiro.au [Simon.Cox@csiro.au]
Sent: 05 April 2017 09:37
To: 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.