- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Wed, 14 Oct 2015 14:58:14 +0200
- To: Simon Cox <Simon.Cox@csiro.au>
- Cc: Chris Little <chris.little@metoffice.gov.uk>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz40_2FG4CuZ-tJBrzq37Djys1n3neUucKju8-QcWOm-3Tg@mail.gmail.com>
Hello Simon, Your paper <http://semantic-web-journal.net/system/files/swj870.pdf> seems to go long way towards meeting requirements for OWL Time, it is good to be aware of that. But only looking at requirements (not the possible solutions), do you think we should have an explicit requirement for past, present and future? Reasons for not introducing the requirement are: 1) It is already possible with the current version of owl-time. 2) We assume that no functionality will be lost if owl-time is extended (your backward compatibility design goal) Could there be a good reason for having this explicit requirement, in one way or the other? Greetings, Frans 2015-10-07 23:42 GMT+02:00 <Simon.Cox@csiro.au>: > Hi Frans – > > > > In my paper now accepted for publication in Semantic Web Journal (and > already available in the online version) I show how OWL-Time can be > extended to enable additional reference systems. Given the fact that > OWL-Time is already widely used, I took as a design goal that existing > implementations not be affected. I added links to all the materials in > various places on our Wiki – e.g. > > https://www.w3.org/2015/spatial/wiki/Time_References > > https://www.w3.org/2015/spatial/wiki/Time_Wish_List > > I also accept that Allen’s relations were complete. > > AFAICT the issues that have come up that still remain to be dealt with are > > (i) Uncertainty – in particular whether some proposed > extensions to the ISO 8601 encoding should be used, or some other method, > for example using specific predicates (my preference) ; > > (ii) Whether we should be in the business of defining > specific predicates to associate temporal objects (position, named instant, > interval) with spatial features, and whether they should be part of > OWL-Time or part of a vocabulary for spatial objects (“features”), or > delegated out to applications. > > > > Simon > > > > *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl] > *Sent:* Thursday, 8 October 2015 6:33 AM > *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au> > *Cc:* Chris Little <chris.little@metoffice.gov.uk>; SDW WG Public List < > public-sdw-wg@w3.org> > > *Subject:* Re: ISSUE-15: Past, present and future > > > > Thank you for the help, Simon. I have now spotted a reference to the OWL > file on the web page about OWL-Time (http://www.w3.org/TR/owl-time/), it > is below in the references. > > > > Given the current state of OWL Time, do you think it is necessary to add > the proposed requirement to the UCR document? We already have the > requirement that OWL Time should support other time encodings next to > xsd:dateTime. Perhaps such support would be something like the > time:inXSDDateTime property (e.g. time:inGeologicalTime). But is it safe to > assume that when other ways of encoding time are introduced in OWL-Time the > functionality with respect to temporal relations will remain for those > other ways as well (when possible)? > > > > Greetings, > > Frans > > > > > > > > > > > > > > 2015-10-06 13:41 GMT+02:00 <Simon.Cox@csiro.au>: > > OWL-Time is here: > > > > http://www.w3.org/2006/time > > > > time:ProperInterval is a subclass of time:Interval, which is a subclass of > time:TemporalEntity, which is in the domain of time:hasBeginning and > time:hasEnd, which have the range time:Instant, which is in the domain of > time:inXSDDateTime and time:inDateTime, which provide concrete encodings. > > > > Simon > > > > *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl] > *Sent:* Monday, 5 October 2015 10:15 PM > *To:* Little, Chris <chris.little@metoffice.gov.uk> > *Cc:* SDW WG Public List <public-sdw-wg@w3.org> > > > *Subject:* Re: ISSUE-15: Past, present and future > > > > Hello, > > > > We tried to make a decision on this issue in the meeting of 2015-09-02 (see > the minutes > <https://lists.w3.org/Archives/Public/public-sdw-wg/2015Sep/0006.html>), > but the proposed new requirement for the OWL TIme deliverable ("It should > be possible to declare that a web resource is in the past, present or > future with respect to another web resource") did not make it because > some things were still unclear. I was tasked (ACTION-70 > <http://www.w3.org/2015/spatial/track/actions/70>) to do some more > research. In particular, to find out to what extent the requirement is > already met in OWL Time. > > > > OWL Time <http://www.w3.org/TR/owl-time/> supports Allen's interval > algebra <https://en.wikipedia.org/wiki/Allen%27s_interval_algebra> and it > has definitions for the relationships that this issue is about: properties > time:intervalBefore, time:intervalDuring and time:intervalAfter can be used > to state something is in the past, present or future with respect to > another thing. So in that sense the required capabilities are already > there. Interval relations in OWL time (like time:intervalBefore, > intervalDuring and intervalAfter) have domain and range set to > time:ProperInterval. This denotes a time interval of which the start and > end are different (not the same instant). As far as I can tell, > time:ProperInterval does not mandate particular time notations (like > xsd:dateTime), so I think the relations can be used with any expression of > a time interval, including vague or imprecise expressions. > > > > I failed at finding the vocabulary itself, I have only read the HTML > documentation, so I am not a 100% sure that the above is correct. But it > seems that the requirement is already met by OWL Time in its current state. > To me it seems that this means that there is no need for the proposed > requirement. > > > > Regards, > > Frans > > > > > > > > 2015-08-26 21:20 GMT+02:00 Little, Chris <chris.little@metoffice.gov.uk>: > > Hi Frans, > > > > As you may guessed, I was away. I am happy with your proposed wording. > > > > Chris > > > > *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl] > *Sent:* Monday, August 17, 2015 3:43 PM > > > *To:* Little, Chris > *Cc:* SDW WG Public List > *Subject:* Re: ISSUE-15: Past, present and future > > > > So far no-one has come up with another interpretation. So I would like to > propose a wording for the requirement: > > > > "It should be possible to declare that a web resource is in the past, > present or future with respect to another web resource" > > > > How about that? Could that be something to vote on next Wednesday? > > > > Regards, > > Frans > > > > > > 2015-08-12 11:14 GMT+02:00 Little, Chris <chris.little@metoffice.gov.uk>: > > Frans, > > > > So, I think we both agree on one interpretation of the requirement. Let’s > see if anyone come up with another. > > > > Chris > > > > *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl] > *Sent:* Friday, August 07, 2015 1:46 PM > > > *To:* Little, Chris > *Cc:* SDW WG Public List > *Subject:* Re: ISSUE-15: Past, present and future > > > > > > > > 2015-08-05 16:06 GMT+02:00 Little, Chris <chris.little@metoffice.gov.uk>: > > Frans, > > > > The problem is that the ‘static assertions’ 'isAboutPastEvent', > 'isAboutPresentEvent' and 'isAboutFutureEvent' are definitely not, unless > you live in a ‘snapshot world’, they change at the rate of 1 day per day. > > > > Well, they could be made static when related to a time. For instance, in > 2015 I could write a document about the Spanish Civil War and state that > the document is about a past event. I could also publish data about a > document that was written in 1938 about the Spanish Civil War and state > that it is about a current event. Similarly I could now publish a weather > prediction for tomorrow and include a statement saying that my data, > published today, is about a future event. This could count as 'coarse > labelling of data'. Annotation like that could be useful, it allows > distinction between predictions, hindsight and current observations. > > > > I am not proposing a solution to the problem here, but by means of this > example I am trying to find out what the possible requirement should look > like. That is what ISSUE-15 is about: it is not clear what is meant. > > > > > > I will rummage around the existing requirement to see if my scenarios are > covered or not. > > > > Thank you, that would be helpful. And if they are, do you think there > won't be a need for an extra requirement? > > > > Regards, > > Frans > > > > > > Chris > > > > *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl] > *Sent:* Wednesday, August 05, 2015 1:54 PM > *To:* Little, Chris > *Cc:* SDW WG Public List > *Subject:* Re: ISSUE-15: Past, present and future > > > > Thanks for explaining Chris. > > > > It seems to me that current practices accomodate knowing about relative > past, present and future if some amount of processing is allowed, like in a > SPARQL query. But this is more about making static assertions? So perhaps > this calls for properties like 'isAboutPastEvent', 'isAboutPresentEvent' > and 'isAboutFutureEvent'? > > > > Do you there is a reason to create an additional requirement or to change > an existing requirement? If so, could you venture a proposal? > > > > Regards, > > Frans > > > > > > > > 2015-08-05 14:23 GMT+02:00 Little, Chris <chris.little@metoffice.gov.uk>: > > Hi Frans, > > > > I think this requirement, as identified in the tracker comments, is about > coarse labelling of data. > > > > There is a subtlety that has to be captured: if an historian is annotating > a document that was written after the Spanish civil war (both ‘Past’) but > before another document (‘Past’), that would have been in the ‘Future’ at > the time. > > > > The same issue arises in a detailed way with weather forecasts – when > analysing past weather forecasts, we label things that were future in the > past. This ability to talk about such things is certainly reflected in lots > of languages like English and French. > > > > So I think it is part of logical reasoning about events and having > appropriate vocabularies and ontologies. > > > > I do not think that there is a requirement here for detailed temporal CRS > and calendar stuff. > > > > HTH, Chris > > > > *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl] > *Sent:* Tuesday, August 04, 2015 3:14 PM > *To:* SDW WG Public List > *Subject:* ISSUE-15: Past, present and future > > > > Hello, > > > > Like ISSUE-14, ISSUE-15 <http://www.w3.org/2015/spatial/track/issues/15> did > not have its dedicated e-mail thread yet. This message is intended to start > that thread and the discussion on how to resolve ISSUE-15. > > > > I am not sure what to make of this prospect requirement...Could anyone try > to explain what could be meant and whether we should consider adding a new > requirement or amending an existing requirement? > > > > Thanks, > > Frans > > > > -- > > Frans Knibbe > > Geodan > > President Kennedylaan 1 > > 1079 MB Amsterdam (NL) > > > > T +31 (0)20 - 5711 347 > > E frans.knibbe@geodan.nl > > www.geodan.nl > > disclaimer <http://www.geodan.nl/disclaimer> > > > > > > > > -- > > Frans Knibbe > > Geodan > > President Kennedylaan 1 > > 1079 MB Amsterdam (NL) > > > > T +31 (0)20 - 5711 347 > > E frans.knibbe@geodan.nl > > www.geodan.nl > > disclaimer <http://www.geodan.nl/disclaimer> > > > > > > > > -- > > Frans Knibbe > > Geodan > > President Kennedylaan 1 > > 1079 MB Amsterdam (NL) > > > > T +31 (0)20 - 5711 347 > > E frans.knibbe@geodan.nl > > www.geodan.nl > > disclaimer <http://www.geodan.nl/disclaimer> > > > > > > > > -- > > Frans Knibbe > > Geodan > > President Kennedylaan 1 > > 1079 MB Amsterdam (NL) > > > > T +31 (0)20 - 5711 347 > > E frans.knibbe@geodan.nl > > www.geodan.nl > > disclaimer <http://www.geodan.nl/disclaimer> > > > > > > >
Received on Wednesday, 14 October 2015 12:58:53 UTC