I actually think that the text makes the right assumption. If something
is said to have happened in 1586 we can be reasonablycertain that it happened
before 1 January 1587. We can’t be certain that it did not happen a millisecond
after 31 December 1586 at 23:59:59.
I think we should provide two examples. One that matches the text and the
current one, mentioning that this can be done for ease of implementation.
Which version one implements is after all not the decision of the CRM, but
depends on the available knowledge and interpretation of the source data.
Best,
Florian
On Thu, May 9, 2019 at 7:42 PM +0200, "Robert Sanderson" <[email protected]>
wrote:
Thanks Florian, Nicola!
Should the example be updated (and thus we must all update our implementations)
or the specification to match the example which everyone seems to do in
practice?
My proposal would be to do the latter, in the face of the current ambiguity.
What has everyone else done in this situation? 3 data points is interesting,
but still anecdotal.
(And I’m not going to mention leap seconds that would make the end of some
years 23:59:60 instead of 23:59:59, which would be solved by an exclusive end
date)
Rob
From:
Nicola Carboni <[email protected]>
List-Post: [email protected]
Date: Thursday, May 9, 2019 at 10:27 AM
To: Florian Kräutli <[email protected]>
Cc: Robert Sanderson <[email protected]>, crm-sig <[email protected]>,
Adam Brin <[email protected]>, Greg Williams <[email protected]>
Subject: Re: [Crm-sig] begin_of_the_begin /end_of_the_end is excluded from time
range?
Dear all,
I also follow the range as appear in the data linked by Florian, so:
crm:P82a_begin_of_the_begin “1586-01-01T00:00:00”^^xsd:date
;
crm:P82b_end_of_the_end “1586-12-31T23:59:59”^^xsd:date
;
I agree that the example should be harmonised with the text ( which I assume is
more authoritative). Thank you for pointing out about the problem
Best,
Nicola
Sent from my iPad
On 9 May 2019, at 10:04, Florian Kräutli <[email protected]> wrote:
Dear Rob,
Not having read the guidelines as attentively as you I usually implement P82a/b
suggesting that the begin and end date are both included in the range.
For example, here's the date related to a book published in 1586:
http://sphaera.mpiwg-berlin.mpg.de/id/item/7e241bb5-41e3-4e08-9ab1-547a93fe6b3d/publication/date
I think this is readable as a confidence interval of the book having been
published somewhen in 1586, lacking better ways to express the level of
accuracy in date datatypes.
Best,
Florian
On 8. May 2019, at 19:50, Robert Sanderson <[email protected]> wrote:
Dear all,
I admit I made the rookie mistake of assuming that the P81a/b and P82a/b
properties followed the typical temporal pattern of an inclusive beginning and
an exclusive
end.
Or using interval notation: [begin_of_the_begin, end_of_the_end)
Thus if you know that an event happened sometime in 1586, the begin of the
begin would be 1586-01-01T00:00:00 and the end of the end would be
1587-01-01:00:00:00.
However, http://www.cidoc-crm.org/guidelines-for-using-p82a-p82b-p81a-p81b seems
to clarify that both are exclusive.
> "P82a_begin_of_the_begin" should be instantiated as the latest point in time
> the user is sure that the respective temporal phenomenon is indeed *not yet*
happening.
> "P82b_end_of_the_end" should be instantiated as the earliest point in time
> the user is sure that the respective temporal phenomenon is indeed *no longer*
ongoing.
And thus (begin_of_the_begin, end_of_the_end)
Meaning that the begin of the begin would need to be 1585-12-31T23:59:59 such
that midnight on January first is included in the range, and the end of the end
would
be midnight of January first, 1587.
However, in the following paragraph it says:
> … e.g. 1971 = Jan 1 1971 0:00:00. Respectively, for “P82b_end_of_the_end”
>the implementation should “round it up”, e.g. 1971 = Dec 31 1971 23:59:59.
Which would mean that both ends were *included* in the range.
And thus [begin_of_the_begin, end_of_the_end]
So …
Enquiring minds that need to implement this consistently would like to know
which is correct ☺
Many thanks!
Rob
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
