I seem to have lost Martin’s in between email, but I agree with the general point that there are multiple questions arising and that this issue thread is pointing to one particular problem. This issue in particular is about the formal representation and whether it is correctly formulated (I think yes). The extension of the discussion is related to this issue but does not pertain directly to the particular decision here.
The other questions arose because this thread is parallel in interest to questions of modelling phases or states in CRMSoc and elsewhere and the potential implications and or conflicts in intended models. Therefore, I would say that we could mark this discussion as relevant to both existing, open phase issues and the issue on specifying the top level classes and properties required to return a complete CRM and family graph. I don’t think we need to open a new issue for either because these discussions are on-going and already marked for further investigation. If we want to create a separate email thread to distinguish from the FOL representation under question and the related questions is another matter. We could if desired in order to keep things clear. Best, George ------------------------------------------------------ Dr. George Bruseker Coordinator Centre for Cultural Informatics Institute of Computer Science Foundation for Research and Technology - Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece Tel.: +30 2810 391619 Fax: +30 2810 391638 E-mail: bruse...@ics.forth.gr URL: http://www.ics.forth.gr/isl > On Mar 14, 2019, at 7:23 PM, Robert Sanderson <rsander...@getty.edu> wrote: > > > Good point! I agree that the necessary condition of P98 means that the > Person-STV is impossible, as that temporal projection was not, itself, born. > Thus all STVs that are also Persons, must at least include the temporal > projection of the birth of the Person. > > So … it doesn’t work for Person p10i Person, but it could be reduced to a > higher level class that doesn’t have such an identity condition. For example, > for some time I had a phase in which I was 183 centimeters tall: > > Person p10i [ > a E18_Physical_Object ; > P43_has_dimension [ > a E54_Dimension > P90_has_value 183 ; > P91_has_unit <centimeters> ] > P160_has_temporal_projection [ > a E52_Time-Span ; > … > ] > > Rob > > From: Crm-sig <crm-sig-boun...@ics.forth.gr > <mailto:crm-sig-boun...@ics.forth.gr>> on behalf of Martin Doerr > <mar...@ics.forth.gr <mailto:mar...@ics.forth.gr>> > Date: Wednesday, March 13, 2019 at 4:45 AM > To: "crm-sig@ics.forth.gr <mailto:crm-sig@ics.forth.gr>" > <crm-sig@ics.forth.gr <mailto:crm-sig@ics.forth.gr>> > Subject: Re: [Crm-sig] Issue 326 Resolving inconsistencies between E2, E4, > E52 and E92 > > Dear Robert, > > On 3/13/2019 2:51 AM, Robert Sanderson wrote: > > Let me put it a different way… > > Currently the model allows us to partition physical things according to a > time-span. I can easily document how to have a new identity for the > Nightwatch in its 17 ft phase, and a separate identity for it in its 14.3 ft > phase. I then don’t need to document how to express the width, as it’s > exactly the same pattern as the “real” object. I can do the same with any > descendent of physical thing, or any descendant of E4. > > This seems, I have to say, like a very easy way to model Phase and State with > no additional ontological features needed. I can, today, say that there is a > Person which I “contain”, and has a particular temporal projection (begin of > the being April 25 2016, no end date), and p2_has_type SemanticArchitect. We > could provide a label mapping of P10i_contains to something like “has_phase” > and it would follow the ontology and be easily usable and understandable. > I think this is simply an inconsistent model, because the "person I contain" > must have an identity condition. It has necessarily a birth. Just check E21. > We have to add conditions that the STV is temporally bounded by these events, > which is obvious. > > This has to be spelled out. The cardinality of P100 was death of seems to be > wrong. It allows multiple deaths for people. Here is an interesting question > how to deal with STVs that extend into future! > > Best, > > Martin > > > I don’t regard it as a bad application, because the ontology explicitly > allows it by having E18 as a subclass of E92. Compared to introducing two new > classes and a bunch of new properties, instead I can simply use functionality > present in CRM base today … and I can probably live with feeling dirty > because of it, knowing it’s exploiting a feature that probably shouldn’t be > there. > > And thus, I think the feature probably shouldn’t be there :) > > Rob > > From: Crm-sig <crm-sig-boun...@ics.forth.gr> > <mailto:crm-sig-boun...@ics.forth.gr> on behalf of Martin Doerr > <mar...@ics.forth.gr> <mailto:mar...@ics.forth.gr> > Date: Tuesday, March 12, 2019 at 4:55 PM > To: "crm-sig@ics.forth.gr" <mailto:crm-sig@ics.forth.gr> > <crm-sig@ics.forth.gr> <mailto:crm-sig@ics.forth.gr> > Subject: Re: [Crm-sig] Issue 326 Resolving inconsistencies between E2, E4, > E52 and E92 > > Dear Robert, > > I agree that this is a "non-intended" model, as Guarino describes it. He also > points out, that no ontology can exclude all unintended models. > > However, I do not see actually why this kind of model would be disallowed > with a link. If I am not mistaken, anything that can be said with the IsA can > be said with the 1-1 link. Just add the links, isn't it? > > Indeed, parts can have a smaller time of existence than the whole. This is > intended. To declare a whole which has no portion surviving from beginning to > end of the whole is also realistic. To declare a whole as E22 which has no > properties poses a question about its identity. > > So, I regard the example as a bad application, not a shortcoming of the > schema, and a question of elaborating the identity conditions for physical > objects. > > Opinions? > > Martin > > > > On 3/12/2019 4:27 PM, Robert Sanderson wrote: > > Dear Martin, all, > > I agree with your assessment into the four categories, and that the first > three are met, and the last is more complicated. > I also agree with the formalism for E4. It moves some of the complexity > around, and doesn’t introduce inconsistency for the temporal side of things > for subclasses of E2. > > However, I agree with George that this does not hold true for the other sub > class of E92, being E18 Physical Thing. With this subclass assertion, we can > partition physical things based on time and then make assertions about those > partitions using all of the sub-classes of E18. For example, to say that the > Nightwatch had a width of 17 feet between its production in 1642 and 1715 > when it was trimmed to fit on a wall in the Amsterdam town hall, we could > have an E22 for the painting throughout time, and use P10 to reference > further E22s, each of which were clarified with P160 as to their temporal > projection. These projections could then have different dimensions. > > <Nightwatch> a E22_Man-Made_Object ; > P10i_contains <Large_Nightwatch> , <Small_Nightwatch> . > > <Large_Nightwatch> a E22_Man-Made_Object ; > P160_has_temporal_projection [ > a E52_Time-Span ; > P81a_begin_of_the_begin “1642-01-01” > P82a_end_of_the_end “1715-12-31” ] ; > P43_has_dimension [ > P2_as_type <width-type> ; > P90_has_value 17 ; > P91_has_unit <feet-unit> ] > > (and the same for Small_Nightwatch, starting 1715 with 14.3 feet as width) > > This seems antithetical to the intent of the model (as I understand it) where > activities (such as Modification in this case) are kept separate from the > entities that they affect. > > This particular pattern could be prevented by having E92 not be a sub class > of E18, without affecting the P160 / P4 discussion. However, I note some > issues with making only this split: > > · It would still be valuable to have the STV of a physical thing, in > order to calculate the intersection between the STV that a physical object > projects with Periods (that are themselves STVs). So it would be valuable to > introduce a relationship between E18 and E92, introducing pattern > inconsistency. > · While Period and Event seem to share the identity conditions with > STV, Activity and below start to seem less identical. I worry that I become > the space-time volume of the sum of my activities… and then I am a STV again, > even though we removed it from E18 for just this reason. > · The same issue for P160 / P4 would apply for P161 / P53 – the > spatial projection of the object is its former or current location, as they > have the same identity currently. > > So overall, I think my position is that for consistency of the model, E92 > should not be a subclass of either E4 or E18, but instead related via a > property. > > Hope that helps! > > Rob > > > > > > -- > ------------------------------------ > 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 > > Vox:+30(2810)391625 > Email: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> > Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> > > > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > <http://lists.ics.forth.gr/mailman/listinfo/crm-sig> > > > -- > ------------------------------------ > 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 > > Vox:+30(2810)391625 > Email: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> > Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > <http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
