RE: ISSUE-15: Past, present and future

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<mailto: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<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<mailto: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<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<mailto: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<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<tel:%2B31%20%280%2920%20-%205711%20347>
E frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://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<tel:%2B31%20%280%2920%20-%205711%20347>
E frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://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<tel:%2B31%20%280%2920%20-%205711%20347>
E frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://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<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://www.geodan.nl>
disclaimer<http://www.geodan.nl/disclaimer>

Received on Wednesday, 26 August 2015 19:20:35 UTC