Dear All, Just quickly jotting down the questions I had (I hope I don't misquote anyone):
1) If E13 Attribute Assignment is problematic and should be used only for reifications, would that mean that P140, P141 can no longer have any subproperties? Christian-Emil: E13 shouldn't be restricted to reifications George: sort out CRMbase first, then the extensions And would we then need a new Class / superproperties, not with (1,1:—,—) ? The properties still seem to want to be grouped. 2) If P38 "deassigned" doesn't have (1,1:—,—), does this also apply to P37 "assigned"? Think of having a list of URI identifiers and changing the base URL. George: argues that P38 should have (1,1:—,—) Christian-Emil: sees the point, and the same with measurement. Decouple it from E13. 3) Condition States: One Assessment may create more than one Condition State. But are there "objective" Condition States that do not come from a Condition Assessment? I.e. is the quantification of P35 "has identified" really (—,—:0,n), or is it (—,—:1,n) ? @Thanasis: sorry, I forgot which of the two versions would break some modelling principles. Best, Wolfgang > Am 09.09.2024 um 15:14 schrieb Martin Doerr via Crm-sig > <[email protected]>: > > Dear Eleni, > > Please use the thread below for Issue 672. I propose to decide it in this > SIG, with all down-stream implications Christian-Emil is pointing to. > > 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. > > > > > -------- Forwarded Message -------- Subject: Re: [Crm-sig] New ISSUE: > Quantifiers of P140,P141,P177 Date: Wed, 20 Mar 2024 15:10:22 +0200 From: > Martin Doerr <[email protected]> To: Christian-Emil Smith Ore > <[email protected]> > > On 3/20/2024 8:24 AM, Christian-Emil Smith Ore wrote: >> 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. > yes🙂🙂 >> >> Best, >> Christian-Emil >> >> >> From: Martin Doerr <[email protected]> >> Sent: 19 March 2024 21:03 >> To: Christian-Emil Smith Ore >> Subject: Re: [Crm-sig] New ISSUE: Quantifiers of P140,P141,P177 >> On a second thought: "deassigned" should not be subproperty of P14 co1. It >> violates (1,1: 0,n), isn't it? >> >> >> On 3/19/2024 8:52 AM, Christian-Emil Smith Ore wrote: >>> >>> 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. >>> >>> >>> >>> Best, >>> Christian-Emil >>> From: Crm-sig <[email protected]> on behalf of Martin Doerr via >>> Crm-sig <[email protected]> >>> Sent: 24 January 2024 19:09 >>> To: crm-sig >>> Subject: [Crm-sig] New ISSUE: Quantifiers of P140,P141,P177 >>> 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 >>> -- >>> ------------------------------------ >>> Dr. Martin Doerr >>> >>> Honorary Head of the >>> Center for Cultural Informatics >>> >>> Information Systems Laboratory >>> Institute of Computer Science >>> Foundation for Research and Technology - Hellas (FORTH) >>> >>> N.Plastira 100, Vassilika Vouton, >>> GR70013 Heraklion,Crete,Greece >>> >>> Email: [email protected] >>> Web-site: http://www.ics.forth.gr/isl >> >> >> -- >> ------------------------------------ >> Dr. Martin Doerr >> >> Honorary Head of the >> Center for Cultural Informatics >> >> Information Systems Laboratory >> Institute of Computer Science >> Foundation for Research and Technology - Hellas (FORTH) >> >> N.Plastira 100, Vassilika Vouton, >> GR70013 Heraklion,Crete,Greece >> >> Email: [email protected] >> Web-site: http://www.ics.forth.gr/isl > > > -- > ------------------------------------ > Dr. Martin Doerr > > Honorary Head of the > Center for Cultural Informatics > > Information Systems Laboratory > Institute of Computer Science > Foundation for Research and Technology - Hellas (FORTH) > > N.Plastira 100, Vassilika Vouton, > GR70013 Heraklion,Crete,Greece > > Email: [email protected] > Web-site: http://www.ics.forth.gr/isl > > -- > ------------------------------------ > Dr. Martin Doerr > > Honorary Head of the > Center for Cultural Informatics > > Information Systems Laboratory > Institute of Computer Science > Foundation for Research and Technology - Hellas (FORTH) > > N.Plastira 100, Vassilika Vouton, > GR70013 Heraklion,Crete,Greece > > Email: [email protected] > Web-site: http://www.ics.forth.gr/isl > _______________________________________________ > Crm-sig mailing list > [email protected] > http://cidoc-crm.org/crm-sig-mailing-list _______________________________________________ Crm-sig mailing list [email protected] http://cidoc-crm.org/crm-sig-mailing-list
