Pxx represents entity of type

In the 46th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 39th FRBR - CIDOC CRM Harmonization meeting; The sig discussed the necessity of introducing such a property and agreed to it. Sig members did not oppose to the introduction of a property used when the specific entity being represented is either unknown, or not of documentary interest. The scope note proposed by RS is to be put up for discussion over the next sig meeting.

Athens, February 2020

Posted by Robert Sanderson on 6/3/2020

Hi Nicola,

I disagree with the relationship to P137.  That would mean that the visual item exemplified the type, which it doesn’t, it merely depicts an entity of the type.

For example, if it were a sub-property of P137 and I was looking for exemplars of abstract impressionism, I might find images that are photographic that merely depict an instance of something which is abstract impressionism.

I could also see it being a sibling to P138 rather than a child, and thus a sub-property of P67.

I took the “not of interest” phrase from the parallel P125:

> This property defines the kind of objects used in an E7 Activity, when the specific instance is either unknown or not of interest, such as use of "a hammer".

But I’m also happy with your reformulation.

Posted by Robert on 25/6/2020

Yesterday we agreed that the scope note for Pxx represents entity of type should be clarified to separate it from just P138 directly to an E55 type.

My attempt to do so for discussion in session 3 tomorrow:

Scope Note:

This property establishes the relationship between an E36 Visual Item and an E55 Type that represents the class of entity which it visually represents.  This property is used when the identity of the specific entity being represented is unknown or unidentified beyond the content of the E36 Visual Item. Pxx represents entity of type is, thus, a shortcut of the more fully developed path from the domain E36 Visual Item through P138 represents, E1 Entity, P2 has type, to the range E55 Type. 

This property is most useful when there is an entity of any type being depicted that is not identifiable as any single individual, but is clearly of a particular type. The image carried by a photograph of an unknown garden would depict many flowers, but none of which are known as entities beyond the photograph. Conversely, if there isn't an individual that could fill the role of the E1 Entity in the fully developed path, then this property is not appropriate, and a direct relationship of P138 represents from the E36 Visual Item to the E55 Type is recommended. 

 The manner or mode of the representation can be captured using Pxx.1 mode of representation.

Examples:

    The photograph’s visual content (E36) represents an entity of type beach (E55) 

    The sculpture’s visual content (E36) represents an entity of type woman (E55)

    The landscape painting’s image content (E36) represents an entity of type field (E55) in the manner of background (E55)

In the 47th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 40th FRBR - CIDOC CRM Harmonization meeting; the sig discussed the proposal to  Introduce a new property (Pxxx represents entity of type) to facilitate documenting the type of an entity represented by a visual item and  decided to postpone reaching a decision until RS has brought back an updated proposal incorporating the changes suggested by the SIG (define it as a shortcut and redraft the examples); which should be before session 2.3. Then, if the SIG agrees it could be given an identifier and be used by the community –it is not to go to the version submitted to ISO. HW for RS. The details of the discussion can be found here.

June 2020

Posted by Robert  Sanderson on 03/03/2021

Dear all,
The proposed, revised scope note, copied mostly from the issue which I believe fulfils the requests from last SIG meeting's discussion, but please let me know if any additional edits are needed:

This property establishes the relationship between an E36 Visual Item and an E55 Type that represents the class of an entity which it visually represents.  This property is used when the identity of the specific entity being represented is unknown or unidentified beyond the content of the E36 Visual Item. Pxx represents entity of type is a shortcut of the more fully developed path from the domain E36 Visual Item through P138 represents, E1 Entity, P2 has type, to the range E55 Type. 

This property is most useful when there is an entity of some type being depicted that is not identifiable as any particular individual, but is clearly of a particular type. The image carried by a photograph of an unknown garden would depict many flowers, but none of which are known as entities beyond the photograph. Conversely, if there isn't an individual that could fill the role of the E1 Entity in the fully developed path, then this property is not appropriate, and a direct relationship of P138 represents from the E36 Visual Item to the E55 Type is recommended. 

The manner or mode of the representation can be captured using Pxx.1 mode of representation.

Examples:

    The photograph’s visual content (E36) represents an entity of type beach (E55) 

    The sculpture’s visual content (E36) represents an entity of type woman (E55)

    The landscape painting’s image content (E36) represents an entity of type field (E55) in the manner of background (E55)

In the 49th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 42nd FRBR – CIDOC CRM Harmonization meeting, the SIG reviewed RS's HW (scope note and example for Pxxx represents entity of type).

Decision: There was some editing involved and it was agreed that the property will appear in CIDOC CRM v7.2, with a different label (Pxxx represents instance of type). The reworked scope note can be found here.

For the moment there is only one example illustrating the proper use of the property. New examples are to be discussed in a separate issue. The property still needs to be assigned a number (before the issue closes). 

Some of the points raised in the discussion: 

• We don’t talk about entities in the CRM. It’s instance, item or particular. Here probably *instance*.

• If Pxx represents entity of type isA P138 represents, then it inherits the .1 property, we don’t need to declare a separate subproperty for that. 

• typed properties for the CRM. When the extension for typed properties is ready, there will be some replication. We might want to consider moving it to the extension. 

• Distinguish btw representing an unknown particular and representing a concept. The property should only be used when one wants to document that an instance of E36 Visual Item represents an unknown particular of a given type. More examples are needed to make that crystal clear. The examples should mainly involve photographs. That a photo represents an instance of owl, means that the identity of the particular bird is unknown. But there must have been a photographed object of type owl. 

HW: MD to provide more examples, RS to collaborate. 

HW by Martin Doerr (proposed quantification, FOL and minor scope note addition) --24 January 2022

Comment by Thanasis (24 January 2022)

Dear all,

The FOL I think is missing the shortcut (which I feel brave enough to try!):

P199(x,y)⇐(∃z)[E1(z)˄P138(x,z)˄P2(z,y)]

Just to flag that this seems to me a typical case of a typed property
(TP198). I am happy with adding this, but I am a bit concerned on where
will we stop with typed properties. I.e. I have lots of examples for
typed P46 statements and typed P45 statement etc. but we do not want all
of these in CRMbase. And I am sure there are tons of similar examples
for the rest of the CRM properties (another one from the St. Catherine's
is TP1 is identified by identifier of type).

Another issue is that, if I am reading the RDFS file correctly, querying
RDF for P198 will not return results of P199 when clearly the chain
passes through it. A reification construct is needed to do that, again
not desirable in CRMbase.

In other words I am worried that this property is an *incomplete
implementation* for RDFS and opens a can of worms. I would suggest that
this is kept in a separate RDFS file which brings me to the TP and NTP
extension: This is developing in parallel to Carlo and I working on TPs
and NTPs which I think are a more complete solution which does not
affect base and I apologise for being slow with it. Carlo is doing a lot
of hand-holding and I am learning as I go.

As always, I am sorry if I have misunderstood critical points.

All the best,

Thanasis
 

In the 53rd CIDOC CRM & 46th FRBRoo SIG meeting, the SIG decided to postpone this issue, on the grounds that it may result in infinitely multiplying the typed properties in the CRM. TV and CM are working to achieve that through a systematic solution (also negative properties). The property may end up being deprecated in the end. 
Nb. There are other typed properties in the CRM that we might need to reconsider after a more general solution has been provided.

May 2022
 

In the 54th CIDOC CRM & 47th FRBR/LRMoo SIG Meeting, Thanasis Velios proposed to deprecate P199 represents instance of type (admitted into the CIDOC CRM v7.2.x branch), on the grounds that the information it conveys can be expressed through the (N)TPs model. 

The SIG decided to discuss the proposal in the December 2022 meeting, in order to give Thanasis and Rob ample time to discuss how P199 fits into the (N)TPs model. 

Rome, September 2022

Post by Martin (21 Nov 2022)

Dear All,

At a second thought, P199 represents entity of type may actually not fit well into the "typed property theory" presented by Thanasis.

The visual item described by this property is expected to be specific to the represented instance, nearly providing a sort of identity to it ("but is clearly a particular thing of that type. "). 

This is different from, e.g., "P125 used object of type ", in which the related unknown entity is not essential to the domain instance.

I therefore propose not to delete it in favour of a general typed property mechanism.

I propose the following quantification and FOL, which is missing:

many to many (0,n:0,n).

The visual item may show multiple items of different type, one item described by multiple types or no item at all, or no item of any particular type.

Even if we require that it shows only one item, the quantification remains the same, because any item can have multiple types.

THE FOL:

P199(x,y) ⇒ E36(x)

P199(x,y) ⇒ E55(y)

P125(x,y) ⇔ (∃z) [E18(z) ∧ P138(x,z) ∧ P2(z,y)]

The FOL above reveals a logical gap. The scope note excludes representations of E55 Type directly, but the range of P138 includes types. I would argue, that the real application of this property is only about physical things.

 Otherwise, we would need to define NOT E55 Type instances, but there are many other immaterial things that do not clearly separate between depictable particulars and general concepts:

P125(x,y) ⇔ (∃z) [E1(z) ∧ ¬ E55(z) ∧ P138(x,z) ∧ P2(z,y)]

I propose the following adaptation to the scope note:

Scope note:

This property establishes the relationship between an instance of E36 Visual Item and an instance of E55 Type that characterises an instance of E18 Physical Thing depicted on the domain instance. This property is used when the identity of the thing depicted is unknown or unrecorded, but is clearly a particular physical thing of that type. If the instance of E36 Visual Item directly depicts the concept of the E55 Type rather than an instance of a thing of that type, then this should be represented using E36 Visual Item P138 represents E55 Type.

This property is a shortcut of the more fully developed path from E36 Visual Item through P138 represents, E18 Physical Thing, P2 has type to E55 Type.

Best,

Martin

In the 55th joint meeting of the CIDOC CRM and SO/TC46/SC4/WG9; 48th FRBR/LRMoo SIG meeting, the SIG reviewed the proposal by TV to not deprecate P199 represents instance of type, on the grounds of it having been implemented already in many systems. TV also made a case against introducing typed properties in the model from now on. 
Furthermore, it was proposed that the Guidelines to writing scope notes document (see issue 494) should contain a statement about the existence of typed properties. The idea is to let people know that they shouldn’t be proposing typed properties from now on.

Decisions: 

• Keep P199 in the v7.2.x branch, quantification set to (many-to-many) 
  HW: 
  • MD to provide a quantification statement for P199;
  • RS to revise the reformulation of the scope note and the axiom proposed by MD in the email thread for the issue (7 December 2022). If this happens long before the next meeting, then it can be put to an evote. If there are things to be discussed still, it can be brought to the SIG in the meeting in May 2023. 
• Add the statement about the typed properties in the guidelines to writing scope notes.
  HW: TV.

Issue is kept open, until all the subtopics have been resolved.
 

Belval, December 2022

Post by Martin Doerr (25 April 2023)

Dear All,

At a second thought, P199 represents entity of type may actually not fit well into the "typed property theory" presented by Thanasis. The visual item described by this property is expected to be specific to the represented instance, nearly providing a sort of identity to it ("but is clearly a particular thing of that type. "). This is different from, e.g., "P125 used object of type ", in which the related unknown entity is not essential to the domain instance. 

I therefore propose not to delete it in favour of a general typed property mechanism. 

I propose the following quantification and FOL, which is missing: many to many (0,n:0,n).

The visual item may show multiple items of different type, one item described by multiple types or no item at all, or no item of any particular type.

Even if we require that it shows only one item, the quantification remains the same, because any item can have multiple types.

THE FOL:

• P199(x,y) ⇒ E36(x)
• P199(x,y) ⇒ E55(y)
• P125(x,y) ⇔ (∃z) [E18(z) ∧ P138(x,z) ∧ P2(z,y)]

The FOL above reveals a logical gap. The scope note excludes representations of E55 Type directly, but the range of P138 includes types. I would argue, that the real application of this property is only about physical things. 

Otherwise, we would need to define NOT E55 Type instances, but there are many other immaterial things that do not clearly separate between depictable particulars and general concepts:

P125(x,y) ⇔ (∃z) [E1(z) ∧ ¬ E55(z) ∧ P138(x,z) ∧ P2(z,y)]

I propose the following adaptation to the scope note:

Scope note:

This property establishes the relationship between an instance of E36 Visual Item and an instance of E55 Type that characterises an instance of E18 Physical Thing depicted on the domain instance. This property is used when the identity of the thing depicted is unknown or unrecorded, but is clearly a particular physical thing of that type. If the instance of E36 Visual Item directly depicts the concept of the E55 Type rather than an instance of a thing of that type, then this should be represented using E36 Visual Item P138 represents E55 Type.

This property is a shortcut of the more fully developed path from E36 Visual Item through P138 represents, E18 Physical Thing, P2 has type to E55 Type.

Best,

Martin

In the 57th CIDOC CRM & 50th FRBR/LRMoo SIG Meeting, the SIG refrained from reviewing the issue, becasue RS could not be present in the discussion. 

Decisions: 
the issue will either be discussed in RS's presence in the 58th SIG meeting, or will be resolved according to the proposal by MD & TV. 

Marseille, October 2023