# Issue 288: Issue about P82 and P81 usage

ID:
288
Starting Date:
2015-06-18
Working Group:
4
Status:
Done
Closing Date:
2020-10-23
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.

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

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

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.

In the 41st joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 34th FRBR - CIDOC CRM Harmonization meeting, the sig  accepted the text  initially and decided that improvements should be made: GB will make minor grammatical changes before it goes up.  CEO and OE would contribute examples and graphics for the next version of the text.

Lyon, May 2018

In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting,  the text “Guidelines for using P82a, P82b, P81a, P82b” was accepted as an appendix to the document “Implementing the CIDOC Conceptual Reference Model in RDF”.

The sig also complemented the text of 288 by adding a citation to Christian’s Emil relative work and decided to update the uploaded  text to the site and the crm-sig be listed as the author of “Guidelines for using P82a, P82b, P81a and P81b”.

Berlin, November 2018

Posted by Olivier Marlet on 22/10/2019

Dear all,
I see that you will work about P81 and P82 usage in the 288 issue.
I can share with you the reason we use P81a and P81b or P82a and P82b in the case of the AERBA project (http://aerba.huma-num.fr/) > Mapping 1468 in 3M.

The aim is to model the time when the discovery of the site took place. In our case, the information we have is only the year. Of course the discovery didn't last a year but we don't have any more information. However, we do know that it is necessarily during the course of this year, so we decided to use the extended margins since the event could not occur before January 1st or after December 31, so we choose to use P81, which corresponds to the wide fork.
On the other hand, the dating of the occupation of the site corresponds to a restricted range: we propose a short dating compared to the knowledge we have of the site, but this does not exclude that the site may exist a little before and remain a little after, so we choose to use P82 which corresponds to the restricted range.

Posted by Martin on 20/10/2020

I came to the conclusion that the guidelines in the Annex of "Implementing..." are more modern than that 288 from the 42nd Meeting. Only a few minor  updates in the latter had not been promoted into the Implementing CRM in RDF. See the differences. I propose the attached consolidation, and to delete the independent guideline P81/P82 from the site.

I propose to vote to accept Implementing CRM in RDF as official and delete the Google doc

Posted by Steve on 21/10/2020

Hi all

The “New Guidelines P81 P82.docx” document still has the “Guidelines for using P82a, P82b, P81a, P82b” title error. It should be “Guidelines for using P81a, P81b, P82a, P82b”

Posted by Martin on 21/10/2020

On 10/21/2020 6:46 PM, Stephen Stead wrote:
>
> Hi all
>
> The “New Guidelines P81 P82.docx” document still has the “Guidelines for using P82a, P82b, P81a, P82b” title error. It should be “Guidelines for using P81a, P81b, P82a, P82b”
Corrected

By the way, I remember (if not from my dreams) that we have reviewed the guidelines after integrating it into the Implementation guidelines.

Outcome:

In the 48th CIDOC CRM and 41st FRBR CRM sig meeting (virtual), the sig discused the parallel editing of two texts entitled "New Guidelines P81 P82" that got everyone confused regarding what the last updated version was. CB presented a pairwise comparison of the “Guidelines on how to use P81 and P82” found under “Best Practices”, and the new version produced by MD. The differences were minor and involved
1)    Adding the citations where necessary
2)    Moving the paragraph about negative time intervals under P81a/b
3)    Different phrasing when to avoid documenting the instance of E61 Time Primitive corresponding to the *end-of-the-end* of the relevant time-span: instead of expressing a possibility, it was changed to express necessity.
4)    Deleting the note re. the other possible ways that one could come up with to deal with imprecision and temporal reasoning.
In total, the new version that MD produced is more up to date than the one implementing the relevant decision of the 42nd sig meeting.
The sig accepted  the changes proposed by MD, changed the date of the document [set it to current: 23 October 2020], incorporate it as an appendix to the document “Implementing the CIDOC Conceptual Reference Model in RDF”, published on the CIDOC CRM site under Best Practices. The updated text (citations, changes) can be found here

Subsequently CB presented a pairwise comparison of the document labelled “Implementing the CIDOC Conceptual Reference Model in RDF” in its google doc version, to the version published under Best Practices in the CIDOC CRM site (issue 443).
There is one difference that needs be addressed in the sig, namely the addition of following chunk of text in the section concerning linking to authority files (chapter: CIDOC CRM and other frameworks).
“It is also incompatible to use skos:exactMatch to link from CRM instances to authorities such as VIAF, ULAN and TGN. Authorities often define places and people as skos:Concept for classification in their discourses and assign a URI for each instance of skos:Concept. These URIs are instances of E41 Appellation. Therefore, it is recommended that instances of places and people should link to authorities with the property P1_is_identified_by.”

It was agreed that since any URI that stands for a thing in a knowledge base constitutes simultaneously an appellation for the thing, the text should be included despite implementers not liking it. And it should be explained more, if necessary.
The sig (a) accepted  the addition of this text to the document, (b)    to substitute the annex on how to use P81a/b and P82a/b with the one discussed earlier,
(c)    change the date of the text to the current (October, 23 2020) and set its version to 1.1