Issue 672: Quantifiers of P140, P141, P177

ID: 
672
Starting Date: 
2024-01-26
Working Group: 
3
Status: 
Proposed
Current Proposal: 

Post by Martin (24 January 2024) 

Dear All,

I remember a discussion about the quantifiers of P140, P141, assigns attribute...

As it stands now, they are both
"many to many (0,n:0,n)".

P177 assigned property of type, has 

"many to many, necessary (1,n:0,n)"

Firstly, all must be necessary. you cannot assign a property type without a domain and range.

Secondly, the scope notes of all these properties do use singular, "the":

"This property associates an instance of E13 Attribute Assignment with the type of property or relation that this assignment maintains to hold between the item to which it assigns an attribute and the attribute itself"

Thirdly, multiple values confuse which is which.

I remember a discussion that, theoretically, if you have:

a) one domain, one type, many ranges

b) many domains, one type, one range

c) one domain, many types, one range,

The propositions are well defined. I assume that this discussion was never ended, nor such constraints be formulated in Logic. I doubt it can be in FOL, and is, for any user, utterly confusing.

The quantifiers must be: "many to one, necessary (1,1:0,n)"

Generalizing single property assigments for ISSUE 602, this must be resolved.

best,

Martin

Comment by Christian-Emil Ore (19 March 2024)

Dear Martin,

I have read this issue a little late. I have no problem with your argumentation. There may be a side effect.

P35:

Quantification: many to many, necessary (1,n:0,n)

For all x,y we have P37(x,y) ⇒ P141(x,y)

Since the quantification of P35 is (1,n:0,n), then it may exist  P37(a,b) and P37(a,c) and b is not c. (if not the quantification should be (1,1:0,n). From the subproperty definition 
P37(a,b) ⇒ P141(a,b) and  P37(a,c) ⇒ P141(a,c)

so we can conclude that P141(a,b) and P141(a,c) which  contradicts the proposed quantification (1,1:0,n) of P141. In general a subproperty cannot have a less restrictive quantification than its superproperty. If I am correct we have check the scopenotes of 

P34, P35, P37, P38, P40, P42

P140 assigned attribute to (was attributed by)

Domain: E13 Attribute Assignment Range:E1 CRM Entity

Superproperty of:

E14 Condition Assessment. P34 concerned (was assessed by): E18 Physical Thing [ (1,n:0,n), not OK]

E16 Measurement. P39 measured (was measured by): E18 Physical Thing [OK]

E17 Type Assignment. P41 classified (was classified by): E1 CRM Entity   [OK]

P141 assigned (was assigned by)

Domain: E13 Attribute Assignment

Range:E1 CRM Entity

Superproperty of:

E14 Condition Assessment. P35 has identified (identified by): Ε3 Condition State  [ (1,n:0,n), not OK]

E15 Identifier Assignment. P37 assigned (was assigned by): E42 Identifier  [ (0,n:0,n), not OK]

E15 Identifier Assignment. P38 deassigned (was deassigned by): E42 Identifier   [ (0,n:0,n), not OK]

E16 Measurement. P40 observed dimension (was observed in): E54 Dimension [ (1,n:0,n), not OK]

E17 Type Assignment. P42 assigned (was assigned by): E55 Type [ (1,n:0,n), not OK]

In all the scopepnotes (P34, P35, P37, P38, P40, P42 ) the instance of the range is in singular number. So the quantifications can be adjusted without problem.

Comment by Martin Doerr (19 March 2024)

On a second thought: "deassigned" should not be subproperty of P14 co1. It violates (1,1: 0,n), isn't it?

Comment by Christian-Emil (20 March 2024)

That is true. Thanasis pointed out that a single condition assessment may comprise more than one thing. So P34 concerned (was assessed by) should not be (1.1:0:n).  In the other hand the same can be said about type assignment and P41 classified (was classified by) which currently  is (1,1:0,n). So maybe we should reconsider all the properties listed in my email. Again E13 is a somewhat problematic class and should perhaps be confined to reifications.

 

In the 58th CIDOC CRM SIG & 51st FRBR/LRMoo SIG Meeting, the SIG reviewed the proposal by MD to change the quantification of P140, P141 from “many to many (0,n:0,n)” and P177 from “many to many, necessary (1,n:0,n)”, to “many to one, necessary (1,1:0,n)”.

CEO checked the quantifiers of their subproperties and marked the ones that need to be altered to match the “many to one, necessary (1,1:0,n)” requirement (namely P34, P35, P37, P38, P40, P42), because the semantics of a property cannot be more restrictive than the semantics of its subproperties.

  • Since the quantification of P35 is (1,n:0,n), then it may exist P37(a,b) and P37(a,c) and b is not c. (if not the quantification should be (1,1:0,n). From the subproperty definition P37(a,b) ⇒ P141(a,b) and P37(a,c) ⇒ P141(a,c) so we can conclude that P141(a,b) and P141(a,c) which contradicts the proposed quantification (1,1:0,n) of P141.
  • The scope notes would not have to be altered, as the range instances of the property are explicitly mentioned in the singular form.

Discussion points: 

Especially for P35 and P40, “many to one, necessary (1,1:0,n)” means that: 

  • one cannot have one instance of E14 Condition Assessment that concerned multiple instances of E18 Physical Things (so one cannot group items assessed by one group assessment); rather they would have to create a super-activity consisting of multiple E14s, each for one item only.
  • one cannot have one instance of E16 Measurement that assigned multiple dimensions to the measured thing; again, they would have to create a super-activity consisting of multiple E16s to do that. 
    • This will have implications for the S25 Relative Dimension construct in sci.

Decision: 
Bring this to MDs attention. Either disengage the subproperties from P140 and P141 to allow them less restrictive semantics, or go for the “many to one, necessary (1,1:0,n)” and configure the implications necessary for the semantics of the subproperties.

 

Paris, March 2024
 

Comment by Martin Doerr (9 August 2024) 

 

The comment in the last SIG:

"This will have implications for the S25 Relative Dimension construct in sci." is obsolete. S25 will no more be under the umbrella of E13. This will be in the solution of issue 602, interface between CRMsci and CRMinf, consistently with the decision in CRMinf to regard E13 as subclass of I1 Argumentation, and not vice versa.