Issue 288: Issue about P82 and P81 usage

Starting Date: 
2015-06-18
Working Group: 
3
Status: 
Open
Background: 

Posted by Jean-Baptiste Pressac on 18/06/2015

Hello,

I am an computer-scientist working with two researchers on a prosopographic database of people who contributed to literature in Breton, a Celtic language of Bretagne (France) and I am interested to use the CIDOC-CRM (in particular FRBRoo) to share our data in RDF format.

The database stores informations like the dates of birth, death, participation to groups of all kinds, studies... Informations where fuzzy times are legion. I read the PDF document How to implement CRM Time in RDF (response to issue 164) but I need to clarify the use of P81a, P81b, P82a and P82b.

I understood that any "date" is considered as a duration in the CRM. Even a birth occurring on 25Th of July 1815 should be considered as an event occurring between for instance 25-7-1815 at 0:00 and 25-7-1815 at 24:59. But in that case, what could be the values of P81a, P81b, P82a and P82b ? If we don't take the hours and minutes into account, should we consider the following: P82a = P81a = P81b = P82b = 25-7-1815 ? Or should we consider that we only know P82a and P82b (and don't know anything about a narrower duration, thus P81) and could only declare the following:

P82a = P82b = 25-7-1815
OR
P82a = 25-7-1815 at 0:00
P82b = 25-7-1815 at 23:59

If I take the example of the event (p.5 of the Definition of the CIDOC Conceptual Reference Model) "my birth day celebration 28-6-1995 (E7)" and guess that you invited your friends at 17:00 and the last one left your house around 23:00, should we say that the minimum known temporal extent is between 28-6-1995 17:00 and 28-6-1995 22:45 and the maximum know temporal extent is between 28-6-1995 17:00 and 28-6-1995 23:15, thus:

P82a = P81a = 28-6-1995 17:00
P81b = 28-6-1995 22:45 (23:00 arbitrarily subtracted with 15 minutes)
P82b = 28-6-1995 23:15 (23:00 arbitrarily added with 15 minutes)

Another example: An author is know to have been elected to a club during February and March 1754 and to have left the club in 1761. Should we declare a E85 Joining with a E52 Time Span characterized by:

P82a = 01-02-1754
P82b = 31-12-1754

And a E86 Leaving with a E52 Time Span characterized by:

P82a = 01-01-1761
P82b = 31-12-1761

Last example: If we are talking about a war which started between February and March 1756 and finished in 1773, should we declare an E7 Activity with a E52 Time Span characterized by:

P82a = 01-02-1756
P81a = 31-04-1756
P81b = 31-12-1773
P82b = 31-12-1773


Posted by Jean-Baptiste Pressac  on 15/09/2015

Hello,
Some months after my issue about P82 and P81 usage I still don't figure out how to solve my problem. Do you have any clue to help me ?
Thanks,

Old Proposal: 

In 34th meeting, it is decided that if two inner bounds are not known, we give the outer bounds. It is decided a good practice guide to be written by MD and CEO. MD will write about negative inner bounds.

Heraklion, October 2015

posted by Christian Emil on 6/12/2016


The issue was raised back in June 2015 and has hardly any relevance for the project anymore.

Jean-Baptiste Pressac, who wrote the email, refer to a document called " How to implement CRM Time in RDF", a post to the crm-sig-list by Vladimir A.  I have not found another document about this.

P81a_end_of_the_begin
P81b_begin_of_the_end
P82a_begin_of_the_begin
P82b_end_of_the_end

They are in the rdf-definition of CRM defined as pairwise sub properties of  P81, and P82 respectively.  I cannot find them in the text definition of CRM.

Slide 12 in the attached pdf from 2013 illustrates the definition of the 4 properties. The slide  also illustrates that P81a is not a sub property of P81. When the a time primitive is interpreted as an interval in a linear time line the P81a points to the start point of this (open) interval. If P81a is a sub property of P81 then an instance of P81a is also an instance of  P81 and there may be a  second instance of  P81a  defining the start point of the first which may give a recursion we may not want.

The primitive time relations between E2 temporal entities should also be taken into consideration:

A E2 temporal entity has one and only one E52 Time-Span.  An instance of E52 Time-Span has one and only one  E61 Time Primitive connected via E81 Ongoing throughout and E82 occurs within respectively. Thus indirectly every instance of E2 Temporal Entity has one and only one instance of E61 Time Primitive via P2 ○ P81 and correspondingly one and one E61 Time Primitive via P2 ○ P82.

If two instances of E2 temporal enitiy are related via an instance of Pxx, then there should be some relation between their  corresponding pairs of E61 Time Primitive such that the PXX are "implemented" by the  relations between the (pairs of) E61 Time Primitive.

Next: If P81 and P82 are seen as approximations to the "real" temporal extent, then the cardinality of the two should be weakened to many to many, necessary (1,n:0,n).

Summing up:

The P81a, P81b, P82a, P82b are not a part of CRM and but may be parts of an implementation of E61 as intervals on a linear timeline.

An implementation of E61 Time Primitive should include relationships which make the implementation consistent with the relationships between the instances of E2 Temporal Entities.

The cardinality of P81 and P82 should be weakened to many to many, necessary (1,n:0,n).

*********************
P81 ongoing throughout
Domain: E52 Time-Span
Range: E61 Time Primitive
Quantification:many to one, necessary (1,1:0,n)

Scope note:This property describes the minimum period of time covered by an E52 Time-Span.

Since Time-Spans may not have precisely known temporal extents, the CRM supports statements about the minimum and maximum temporal extents of Time-Spans. This property allows a Time-Span’s minimum temporal extent (i.e. its inner boundary) to be assigned an E61 Time Primitive value. Time Primitives are treated by the CRM as application or system specific date intervals, and are not further analysed.

 

 

Current Proposal: 

In the 37th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 30th   FRBR - CIDOC CRM Harmonization meeting, the crm-sig discussed the proposal of Christian - Emil and decided that  this issue cannot be solved without addressing the overall issues discussed in issue 309. To contribute to / consider within that overall discussion it should be decided how time primitives relate to E2  instances. A Potential solution is to  identify these constructs with declarative time spans. It seems that it is required  a generalization of phenomenal vs declarative properties.

This issue remains pending.

Berlin, December 2016

In the 39th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 32nd FRBR - CIDOC CRM Harmonization meeting, the sig assigned homework to Martin to write a statement about the use of a & b of properties P81 and P82 along with the results of issue 309.
 
Heraklion, October 2017
 

Posted by Martin on 7/1/2018

<PROPOSAL> <HW>

Guidelines for using P82a, P82b, P81a, P82b

 

The range of properties "P81_ongoing_throughout" and "P82_at_some_time_within" is  defined in the CRM as E61 Time Primitive, i.e., (closed, contiguous) intervals on the natural time dimension in which we live.

Since the E61 Time Primitive of the CRM cannot directly be implemented in RDF databases, we define in the official RDF implementation of the CIDOC CRM four properties replacing P81 and P82 adequately using xsd:dateTime.

Property P81 describes the maximum known temporal extent of an E52 Time-Span, i.e. the extent it is ongoing throughout.  It is replaced in this RDF version by the property "P81a_end_of_the_begin"  and "P81b_begin_of_the_end", to be used together.

"P81a_end_of_the_begin" should be instantiated as the earliest point in time the user is sure that the respective temporal phenomenon is indeed ongoing. We call it “end_of_the_begin”, because it also constitutes an upper limit to the end of the indeterminacy or fuzziness of the begin of the described temporal phenomenon.

"P81b_begin_of_the_end" should be instantiated as the latest point in time the user is sure that the respective temporal phenomenon is indeed ongoing. We call it “begin_of_the_end”, because it also constitutes a lower limit to the begin of the indeterminacy or fuzziness of the end of the described temporal phenomenon.

It is correct to assign the same value to P81a_end_of_the_begin and P81b_begin_of_the_end, if no other positive knowledge exists. It is also correct not to instantiate P81 for a time span, if no respective evidence is known.

If a respective reasoning is installed, and no evidence exists that the phenomenon was definitely ongoing at any point in time, one may use a value for P81a_end_of_the_begin greater than for P81b_begin_of_the_end, indicating that the indeterminacy of knowledge (not of being) of the begin overlaps with the indeterminacy of knowledge (not of being) for the end [see Christian-Emil Ore XXX].

If a value for P81a_end_of_the_begin is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it up” to the last instant (second) of this time expression, e.g. 1971 = Dec 31 1971 23:59:59. Respectively, if a value for P81b_begin_of_the_end is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it down” to the last instant (second) of this time expression, e.g. 1971 = Jan 1 1971 0:00:00. If values are needed that are not within the range or precision of xsd:dateTime, e.g., for paleontology, this property should be extended with another, suitable data type.

Property P82 describes the narrowest known outer bounds of the temporal extent of an E52 Time-Span, i.e. the extent it is ongoing “at some time within” this interval.  It is replaced in the official RDF version by the properties "P82a_begin_of_the_begin" and "P82b_end_of_the_end", to be used together.

" 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 ongoing. We call it “begin_of_the_begin”, because it also constitutes a lower limit to the begin of the indeterminacy or fuzziness of the begin of the described temporal phenomenon.

" 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 more ongoing. We call it “end_of_the_end”, because it also constitutes an upper limit to the end of the indeterminacy or fuzziness of the end of the described temporal phenomenon.

It is not correct to assign the same value to P82a_begin_of_the_begin and P82b_end_of_the_end. If a value for P82a_begin_of_the_begin is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it down” to the last instant (second) of this time expression, e.g. 1971 = Jan 1 1971 0:00:00. Respectively, if a value for P82b_end_of_the_end is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it up” to the last instant (second) of this time expression, e.g. 1971 = Dec 31 1971 23:59:59.

It must always hold that the value for P82a_begin_of_the_begin is less than P82b_end_of_the_end, P81a_end_of_the_begin and P81b_begin_of_the_end.

It must always hold that the value for P82b_end_of_the_end is greater than P82b_end_of_the_end, P81a_end_of_the_begin and P81b_begin_of_the_end.

P82a_begin_of_the_begin and P82b_end_of_the_end should always be assigned a value to for any past phenomenon, albeit unrealistically far away from reality. It is an error to associate any quality of positive knowledge with these values. The scholarly practice not to give any outer bounds for an event, because it is, for instance, not known down to a precision of three years, is not helpful for automated reasoning. In that case, the machine may regard that the event has possibly happened at the time of the dinosaurs.

Please improve.

Posted by Thanasis on 10/1/2018

<PROPOSAL

Please find attached a version with some minor changes and a couple of comments. 

 

 

Posted by Richard on 10/1/2018

<COMMENTS>

On 07/01/2018 21:34, Martin Doerr wrote:

>
> Dear All,
>
> Here my guidelines:
>
> Guidelines for using P82a, P82b, P81a, P82b
... should be '81a, 81b, 82a, 82b'
>
> Jan 7, 2018
>
> The range of properties "P81_ongoing_throughout" and "P82_at_some_time_within" is  defined in the CRM as E61 Time Primitive, i.e., (closed, contiguous) intervals on the natural time dimension in which we live.
>
> Since the E61 Time Primitive of the CRM cannot directly be implemented in RDF databases, we define in
replace 'implemented in RDF databases' by 'expressed in RDF'
>
> the official RDF implementation of the CIDOC CRM four properties replacing P81 and P82 adequately using xsd:dateTime.
>
> Property P81 describes the maximum known temporal extent of an E52 Time-Span, i.e. the extent it is ongoing throughout.  It is replaced in this RDF version by the property "P81a_end_of_the_begin"  and "P81b_begin_of_the_end", to be used together.
>
>  "P81a_end_of_the_begin" should be instantiated as the earliest point in time the user is sure that the respective temporal phenomenon is indeed ongoing. We call it “end_of_the_begin”, because it also constitutes an upper limit to the end of the indeterminacy or fuzziness of the begin of the described temporal phenomenon.
replace 'begin' by 'beginning' [of the described ...]
>
> "P81b_begin_of_the_end" should be instantiated as the latest point in time the user is sure that the respective temporal phenomenon is indeed ongoing. We call it “begin_of_the_end”, because it also constitutes a lower limit to the begin of the indeterminacy or fuzziness of the end of the described temporal phenomenon.
>
> It is correct to assign the same value to P81a_end_of_the_begin and P81b_begin_of_the_end, if no other positive knowledge exists. It is also correct not to instantiate P81 for a time span, if no respective evidence is known.
replace 'if ... known' by 'if there is no evidence that the event was definitely occurring at a particular time'?
>
> If a respective reasoning is installed, and no evidence exists that the phenomenon was definitely ongoing at any point in time, one may use a value for P81a_end_of_the_begin greater than for P81b_begin_of_the_end, indicating that the indeterminacy of knowledge (not of being) of the begin overlaps with the indeterminacy of knowledge (not of being) for the end [see Christian-Emil Ore XXX].
Is it helpful to say this? Why not just leave P81 out in this situation?
>
> If a value for P81a_end_of_the_begin is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it up” to the last instant (second) of this time expression, e.g. 1971 = Dec 31 1971 23:59:59. Respectively, if a value for P81b_begin_of_the_end is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it down” to the last instant (second) of this time expression, e.g. 1971 = Jan 1 1971 0:00:00. If
replace 'last' by 'first'?
>
> values are needed that are not within the range or precision of xsd:dateTime, e.g., for paleontology, this property should be extended with another, suitable data type.
>
> Property P82 describes the narrowest known outer bounds of the temporal extent of an E52 Time-Span, i.e. the extent it is ongoing “at some time within” this interval.  It is replaced in the official RDF version by
delete 'the extent'
>
> the properties "P82a_begin_of_the_begin" and "P82b_end_of_the_end", to be used together.
>
> " 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 ongoing. We call it “begin_of_the_begin”, because it also constitutes a lower limit to the begin of the indeterminacy or fuzziness of the begin of the described temporal phenomenon.
replace 'ongoing' by 'happening'?; replace 'begin' by 'beginning' [of the described ...]
>
> " 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 more ongoing. We call it “end_of_the_end”, because it
replace 'no more' by 'no longer'
>
> also constitutes an upper limit to the end of the indeterminacy or fuzziness of the end of the described temporal phenomenon.
>
> It is not correct to assign the same value to P82a_begin_of_the_begin and P82b_end_of_the_end. If a value for P82a_begin_of_the_begin is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it down” to the last instant (second) of this time
replace 'last' by 'first'?
>
> expression, e.g. 1971 = Jan 1 1971 0:00:00. Respectively, if a value for P82b_end_of_the_end is given with a precision less than that of xsd:dateTime, such as in days or years, the implementation should “round it up” to the last instant (second) of this time expression, e.g. 1971 = Dec 31 1971 23:59:59.
>
> It must always hold that the value for P82a_begin_of_the_begin is less than P82b_end_of_the_end, P81a_end_of_the_begin and P81b_begin_of_the_end.
>
> It must always hold that the value for P82b_end_of_the_end is greater than P82b_end_of_the_end,
should be 'greater than P81a_begin_of_the_begin,'
>
> P81a_end_of_the_begin and P81b_begin_of_the_end.
>
> P82a_begin_of_the_begin and P82b_end_of_the_end should always be assigned a value to for any past
delete 'to'
>
> phenomenon, albeit unrealistically far away from reality. It is an error to associate any quality of positive
replace 'albeit ... reality' by 'however approximate'
>
> knowledge with these values. The scholarly practice not to give any outer bounds for an event, because it is, for instance, not known down to a precision of three years, is not helpful for automated reasoning. In that case, the machine may regard that the event has possibly happened at the time of the dinosaurs.
replace 'regard ... possibly' by 'conclude that the event could have'

Hope this helps!

Richard

Posted by Martin  on 10/1/2018

 <HW>

Thank you very much. Here my improvement of the last statement.

Posted by Martin on 10/1/2018

 <HW>

Here my latest edits, thanks to Richard's comments

Posted by Richard on 11/1/2018

Hi,

Not all of my corrections were picked up. Updated version (with some other minor changes) attached. I tried desperately to switch on 'track changes' (saving it as .docx in an attempt to do so), but I have no idea whether Word has actually done this.  I did try!

I wonder if it is helpful to include the paragraph about overlapping 'end of begin' and 'begin of end': the concept is already hard enough to understand without throwing this into the mix.

As regards the substance of the proposal, I would observe that there are other W3C date types, for example gDate and gYear [1].  I agree with the goal of expressing dates in a way which is amenable to machine processing, but the suggested approach appears to require users to record to a spurious precision, which will never be present in the source data.  (If we're following W3C guidelines in full, a DateTime value should have an associated time zone, declared explicitly or implicitly assumed to be UTC.  We don't actually give an example showing this.)

I suggest, instead, that we say that when a W3C date, of whatever sort, is given as the value of P81a or P82a, then it should be interpreted as representing the beginning of the time period expressed by that date.  When such a date is given as the value of P81b or P82b, it should be interpreted as representing the end of the time period expressed by that date.  (Re-reading the text, I do wonder if this is what was actually meant.  It depends what you mean by "the implementation". If so, I certainly misunderstood it the first time around.)

I think the guidance should contain examples using both gYear and gDate, showing how to record e.g. "date of birth recorded as 4.12.1854" and "building not started before 1736; definitely happening 1745-1750; finished by 1754 when it was opened" as RDF.

Best wishes,

Richard

[1] https://www.w3.org/TR/xmlschema11-2/#gYear

posted by Martin on 11/1/2018

Dear Richard,

Your comments well-taken, but I regard it as pointless to use less precise data types. This is, to my opinion, exclusively an issue of automatic conversion
in the data entry forms. We at FORTH have conversion libraries. Data entry utility ("ca 730 BC") must not be confused with internal data representation for interoperability (xsd:....), and not with ontological-logical modelling (time as isomorphic with real numbers).

I do not know how RDF-compatible databases do arithmetic with mix of time data types. Any insight? We must avoid meaningless equality between imprecise dates. I assume there is no default interval arithmetic in place that could handle 28-6-1951 to be  possibly before something that happened in "1951" .

I copy to Christian-Emil, because he should give us his theory of negative P81 intervals.

posted by Richard on 11/1/2018

On 11/01/2018 14:39, Martin Doerr wrote:
> Dear Richard,
>
> Your comments well-taken, but I regard it as pointless to use less precise data types. This is, to my opinion, exclusively an issue of automatic conversion
> in the data entry forms. We at FORTH have conversion libraries. Data entry utility ("ca 730 BC") must not be confused with internal data representation for interoperability (xsd:....), and not with ontological-logical modelling (time as isomorphic with real numbers).
>
> I do not know how RDF-compatible databases do arithmetic with mix of time data types. Any insight? We must avoid meaningless equality between imprecise dates. I assume there is no default interval arithmetic in place that could handle 28-6-1951 to be  possibly before something that happened in "1951" .

Martin,

So we agree that the ultimate storage format should be precise, in the manner described by the draft document.  I take your point about the distinction between a data entry interface and the ultimate storage format in the RDF.  However, I think a description of our RDF solution for P81/P82 which is expressed solely in these terms will convince most practitioners that our RDF implementation is too complex to be used with 'real' museum data.

I think it would be a good idea to include some examples of dates, in a form which might be found in collections catalogues, and show (a) how they should be expressed in abstract terms (P81/P82) and then (b) how they should be rendered as RDF (P81a/P81b/P82a/P82b).  We can also point out that these conversions can be carried out programmatically.

Reference to Issues: