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.
In the 59th joint meeting of the CIDOC CRM and ISO/TC46/SC4/WG9 & 52nd FRBR/LRMoo SIG, Christian-Emil proposed to either restrict the quantification of the subproperties of P140/141 and of P177 to "many to one, necessary (1,1:0,n) or to disengage the subproperties of P140/P141 from them and allow their property quantifiers to be set to "many to many (0,n:0,n)".
However, the SIG refrained from reaching a decision wrt to the original proposal, because of concerns that were raised by Wolfgang, namely:
If E13 Attribute Assignment is only meant to be used for reification constructs, then its properties should only be used for this purpose –it doesn’t make sense that they have subproperties of themselves.
E14 Condition Assessment and E16 Measurement in particular are inherently different to E13 Attribute Assignment, insofar as they involve objectively true situations that are observed and documented, whereas E13 is purely declarational (i.e., E14 and E16 are uncovering facts about the world, whereas E13 is just stating them –thereby creating them).
The properties of E15 Identifier Assignment are not so different from one another (contrary to what is mentioned in the scope note).
For the details of the proposal and the ensuing discussion see here.
How to proceed: The SIG appointed Christian-Emil, Martin, and Wolfgang to come up with a different proposal by the next meeting.
Plovdiv, September 2024
Post by Martin Doerr (17 February 2025) -- personal communication
Continuing the discussion about issue 672, during which I have been absent,
I'd like to propose several answers to the question as appeared in the minutes:
"If E13 Attribute Assignment is only meant to be used for reification constructs" and the proposal to cut off subclasses of E13.
Issue 672 was about the quantification of the properties of E13, in order to remove ambiguity of reference between the three properties, as well as for its subclasses, and not about addressing the meaning of E13. Since the above question about the meaning of E13 has nothing to do with the ambiguity of reference between the three properties, I understand this as a new issue, which should be discussed after resolving 672.
I propose to define the above question as a more general issue:
A) What is the meaning of E13 ?
B) How to document a statement in an attitude neutral to its truth or to being believed by anyone.
C) How to refer to a property instance independent of its place in the model.
--------------------------------------------------------------------------------------------------------
My understanding (as our homework) is the following:
Firstly, I'd like to point you to my elaborate justification of the relation of reification with proposition sets and E13, as attached.
To my understanding,
a) Reification is an encoding feature, and not an ontological entity. It provides a URI to a property instance.
This is exactly what I17 One-Proposition Set does. It allows for declaring a URI for a property instance,
either by three properties or an encoding string.
It is therefore functionally adequate, and can be used as range by any new property. It answers point C above, if CRMinf is used.
b) E13 is an activity. As such, it embeds a reification pattern, but that does not mean
that it covers all possible senses to refer to a property instance. That would be a co-implication.
In particular,
Following the scope note,
"This class allows for the documentation of how the respective assignment came about, and whose opinion it was. Note that all
instances of properties described in a knowledge base are the opinion of someone. Per default, they are the opinion of the team
maintaining the knowledge base."
As such, it was not meant to be neutral to the question of justification by the Actor carrying it out. Also, implementation guide lines discussed in
the past recommended to materialize the property referred to by E13 in the Knowledge Base, if its type is part of the model used.
c) The subclasses of E13 must be regarded as part of the intended meaning. The CRM is developed bottom up. E13, beyond the precision of
its scope note to capture its meaning, was historically designed as generalization of its known subclasses in CRMbase.
d) The proposal to cut off the subclasses is:
- non-monotonic, as it invalidates queries about E13, i.e., constitutes a major revision.
- in contradiction to the original definition
- leaves the current subclasses without generalization, i.e., would require to reinvent their generalization
e) We have recently decided that E13 IsA I1 Argumentation, which would become invalid as well.
Therefore, I have the following questions: Why should E13 only be meant to be used for reification constructs? And who is the Actor, the documentalist or in the documented fact?
As real underlying reason, I regard B) above:
How to document a statement made by someone in an attitude neutral to its truth or to being believed by anyone, in CRMbase or using CRMinf as well?
Obviously, there are several solutions to that:
1) The idea to redefine E13, cut it off from its subclasses and I1, and create a new superclass tin CRMbase to its previous subclasses, and put that under I1 or not.
2) It would be much simpler and monotonic, to declare a new superclass of E13 to cover the meaning thought about in the discussion.
3) Any statement, including a reified property instance, is an instance of E89 Propositional Object, created by an instance of E65 Creation. Used with E65, there is no other commitment to a related reality by the documentalist, nor questioning any possible related reality.
4) I16 Meaning Comprehension in CRMinf provides precisely the mechanism to analyzing a text in terms of formal propositions, without taking a position about its truth or whose opinion it was.
Summarizing, I regard solution 1) not as necessary or effective, and 3),4) and I17 as sufficient.
That leaves the last question A) open:
What is the meaning of E13, and how is it justified to be a kind of I1 Argumentation?
I regard the following:
a) I1 Argumentation is more general than E13 in the sense that it refers (1) to whole sets of propositions and (2) to varied belief values. This is what the new version of CRMinf describes.
b) I1 Argumentation, regardless scope note, is designed to be superclass of Observation (Doerr et al. 2011), i.e., "I have seen it"is taken as Argument.
c) Similarly, E13 is superclass of: E14 Condition Assessment, E16 Measurement, E17 Type Assignment. Clearly, these classes are observation based and therefore clearly fall under the intention of I1.
d) E15 Identifier Assignment has different semantics, because it brings about a new state. I argue, that even identifier assignment follows a justifying procedure with premises, such as uniqueness etc.
e) The more general case of "name use" activity is referred to in CRMbase in the introduction and as example under E7, but was not considered under E13.
In case we regard the scope note of I1 Argumentation to be too restrictive to cover E15, we can relax the scope note of I1, which is monotonic.
Best,
Martin