[Crm-sig] NEW ISSUE: Approximate Dimensions
Dear all, In recent history, we have added P189 approximates for the practically ubiquitous scenario where we have recorded the approximate “declarative” place of an event, but not the exact “phenomenal” place. P189 allows us to say that the event took place at the phenomenal place, which is then approximated by the declarative place. Thus: Birth_of_Rob a E67_Birth ; p7_took_place_at [ a E53_Place ; rdfs:label “The exact place Rob was born” ; p189i_approximated_by [ a E53_Place ; rdfs:label “New Zealand” ; // … ] ] This gives us two significant advantages: 1. We can have multiple declarative places associated with the single phenomenal place. This allows us to be clear that the event took place in one location, but we have multiple ways to describe that location in our information system. 2. If we can be precise (enough) about the phenomenal place (e.g. we have the GPS coordinates from the digital camera that took the photograph), then we do not have a different model … we can simply ascribe those coordinate values to the phenomenal place. While the E53 Place scope notes do not talk about approximation, there is another class that does … the very next one, E54 Dimension. An instance of E54 Dimension represents the true quantity, independent from its numerical approximation, e.g. in inches or in cm. However, there isn’t a property that allows us to use this same approximation pattern for Dimensions. The same advantages would apply: 1. We can have multiple declarative dimensions (10 inches, 25 centimeters) that approximate the true dimension, rather than implying there are two different dimensions. 2. If we do not have this case, because the dimension is measured very accurately and has only a single numerical representation, then we can simply use a single Dimension. This is also useful for conservation when the same dimension is measured to different degrees of accuracy with different instruments or techniques … there is only a single height (for example) but it is measured with a laser, or by estimation. Thus I would like to propose the addition of a new property, Pxxx_approximates_dimension, that mirrors P189_approximates, that would be used to associate true dimensions with their approximations. It would be used in exactly the same way as P189: painting a Human-Made_Object ; has_dimension [ a Dimension ; p2_has_type ; pxxxi_dimension_approximated_by [ a Dimension ; p90_has_value 10 ; p91_has_unit ] ] Thank you for your consideration of this issue! I’m happy to write up a draft scope note for discussion if the general issue is considered to be worthy of inclusion. Rob
Re: [Crm-sig] ISSUE proposal to replace E18 isa E92 and E4 isa E92 with properties
As the spacetime volume that is Rob, and the spacetime volume that is the next SIG meeting will unfortunately not intersect, I’d like to register my full support for this change, including case 3 as the preferred solution, in advance! Rob From: Crm-sig on behalf of Christian-Emil Smith Ore Date: Tuesday, October 15, 2019 at 1:19 AM To: "crm-sig@ics.forth.gr" Subject: [Crm-sig] ISSUE proposal to replace E18 isa E92 and E4 isa E92 with properties Dear all, This email describes the issue of replacing the E18 isa E92 Spacetime volume and E4 isa E92 Spacetime volume with properties. The main reason to do so is based on the observation that for most of the (potential) users of CRM it is too abstract to identify a thing with its spacetime volume. Below I start with a soft introduction and then present the issue(s). I have given links to documents which can be downloaded. These are ppt with 4 possible cases (case 3 is what is suggested) and concordance of the phrase “spacetime volume” in the CRM document. ppt: http://www.edd.uio.no/nedlasting/cidoc-crm/STV_suggested_changes.ppt concordance: http://www.edd.uio.no/nedlasting/cidoc-crm/kwic_spacetime_volume.txt Best, Christian-Emil The concept of spacetime volume is taken from physics. The idea is intuitive. Every physical thing has a volume, that is, occupies space (check your cupboard). When a cup is moved in the kitchen its volume will move relative to the kitchen floor and walls. Its place in the kitchen will depend on the time of the day. If the cup’s movement is registered in a 3D model, say every second , its whereabouts will look like some strange geometric figure. If the cups movement from it production to it is broken beyond recognition by a steamroller, this can also be a figure depending on time. So for any identifiable thing there will be a unique volume from it gets it identity until the identity is lost. This can be seen as a volume in a 4 dimensional space (X,Y,Z,T), that is, a 3D figure evolving over time. It should also be evident that such a 4D volume is unique for a physical thing. Two things describing the exact same volume during their lifetime can be considered the same thing. Instances of the class E92 Spacetime volume (STV among friends) are such 4 dimensional volumes. It is a handy abstraction which makes it possible to talk about a ship’s travel etc. The one to one relation between an identifiable physical thing and a spacetime volume is the reason to make E18 Physical thing a subclass of E92 Spacetime Volume, that is, every instance of E18 Physical thing _is_ an instance of E92 Spacetime volume. However, practical experience has shown that this is considered to be very abstract for most users of CRM. We have observed confusions and misinterpretations. It is reported to be very difficult to teach CRM with this construct. It is more intuitive to say that a physical thing has a spacetime volume than to say that a physical thing is a spacetime volume. Proposal 1: Replace E18 isa E92 Spacetime volume with a property PXXX: Pxxx has defining STV (is defining STV of) Domain: E18 Physical Thing Range: E92 Spacetime Volume Quantification: one to one, necessary (1,1:0,1) In the current model we also have E4 Period isa E92 Spacetime volume. This is more intuitive since something happening has a time and a place but no physical substance. On the other hand, it is arguable that two events may happen at the same time and same place. A simple example technical example are instances of E8 Acquisition and E10 Transfer of Custody, which may happen at the same time and place. More generally and perhaps more philosophically, when documenting the past, it is not uncommon to interpret something happing at a place and time as more than one event. If one accept this, then an instance of E92 Spacetime Volume is not in one to one relation with an instance of E4 Period, two instances of E4 Period can share an instance of E92 Spacetime Volume Proposal 2: Replace E4 isa E92 Spacetime volume with a property Pyyy Pyyy has defining STV (is defining STV of) Domain: E4 Period Range: E92 Spacetime Volume Quantification: one to one, necessary (1,1:0,n) This construct will solve the problem of P4 vs P160. Consequences for the current CRM (document): There only two properties that are a sub property of a property with STV as domain or range: 1) P46 is composed of (forms part of) 2) P156 occupies (is occupied by) P46 needs an adjustment of the FOL-definition (which also has an error as it is today). P156 is ok as it is (although its not so easy to understand) The scope not of the two classes E4 Period and P18 Physical thing has to be adjusted. There is a almost identical paragraph which can be deleted and reused in the scope note for the new properties. E18 Physical Thing: We mod
Re: [Crm-sig] P72 has Language
Dear all, I think that the turn to the data is the right move here. So some examples at hand: Viaf - widely used ref http://viaf.org/viaf/27251336 Emu - widely adopted collections management system Chin makers in Canada model - national standard body Canada It is in the requirements by researchers for building their persons model Finally, I would come back to the initial example. The project in question as far as I follow it, looks to extract analytic data typically encoded by researchers in archival formats that HAVE NOT ALLOWED the precise recording of information that they would have liked to record Analytically and formally. Ie they are precisely trying to find good structures where there were none. The solution is certainly not to document it as an information object. I am glad to keep finding examples. I hope we can use this practice generally and could even think of formalizing a list of schemas of reference. Best, George On Tue, 15 Oct 2019 at 3:50 AM Franco Niccolucci < franco.niccolu...@gmail.com> wrote: > Dear all, > > > having somehow started this discussion in a hot August evening, let me > remind you that the initial question was: > > "When describing biographical information [in an archive] it’s common to > state that some person was fluent in some language, or languages, apart > from his/her native one. Using current archival descriptions standards > [ISAD(G) 3.2.2; EAD ] this is represented within a text, usually > a very long text string with information of distinct natures. So far we > have been able to decompose the different elements and represent them > adequately as instances of CIDOC-CRM classes and link them trough the > suitable properties. > We cannot link a Person (E21) to a language (E56) and neither use multiple > instantiation, as it has been suggested in other cases ( > http://www.cidoc-crm.org/Issue/ID-258-p72-quantification), because Person > (E21) and Linguistic Object (E33) are disjoint.” > > I understand these bios consist in a text, and metadata are added to it as > instances of various CIDOC-CRM classes. The question was how to indicate in > such metadata the knowledge of a language as reported in the bio: so not a > real quality of the person, but a fact documented. My suggestion was to use > E74 Group. I always prefer to use what is already available and avoid the > unnecessary proliferation of classes and properties, in my opinion there > are already (more than) enough. But in doing so I try to maximize > expressiveness, as otherwise one class (E1 CRM Entity) and one property (P2 > has type) would be sufficient for the whole world: P2 is not a > jack-of-all-trades. > > Reportedly, the Group solution seemed to please the person who made the > question. > > I don’t know if the "language spoken" is an information usually taken into > account in CH; but in this case it was by the archivist, otherwise no > question would have been aaked. > > Best regards > > Prof. Franco Niccolucci > Director, VAST-LAB > PIN - U. of Florence > Scientific Coordinator > ARIADNEplus - PARTHENOS > > Editor-in-Chief > ACM Journal of Computing and Cultural Heritage (JOCCH) > > Piazza Ciardi 25 > 59100 Prato, Italy > > > > Il giorno 14 ott 2019, alle ore 22:39, Detlev Balzer > ha scritto: > > > > Dear George, Martin, > > > > this discussion made me curious whether or not I can confirm George's > assertion that such statements are common in the cultural heritage field. > > > > EAC-CPF does have a language element, which is, however, only used to > indicate in which language the name of a person or corporation is > expressed. > > > > GND, the authority file for libraries in German-speaking countries, has > a Language entity which is used for making statements about the "field of > study" of a person. Other predicates for the person-language pair of > entities do occur, but these are obvious data entry errors. > > > > Having extracted person-related data from a dozen or more cultural > heritage projects, I don't remember any example where languages spoken or > known by somebody have been considered in any other sense than relating to > the documented activity, rather than to the (possibly un-instantiated) > capacity of the person. > > > > Of course, this is just an observation that doesn't prove anything. > Personally, I would tend towards Martin's view that there is little, if > anything, to be gained by defining such kind of statement in a reference > model such as the CIDOC CRM. > > > > Best wishes, > > Detlev > > > >> George Bruseker hat am 14. Oktober 2019 um > 19:45 geschrieben: > >> > >> > >> Dear Martin, > >> > >> The conversation began with a use case from an archive. I just inform > that > >> this is also found in all the projects I work on for memory > institutions. > >> They find it in scope, so looking further afield for what > anthropologists > >> do doesn't seem like a necessary step? Though highly fascinating! > >> > >> Best > >> > >> George > >> > >> > >> > >> On
[Crm-sig] ISSUE proposal to replace E18 isa E92 and E4 isa E92 with properties
Dear all, This email describes the issue of replacing the E18 isa E92 Spacetime volume and E4 isa E92 Spacetime volume with properties. The main reason to do so is based on the observation that for most of the (potential) users of CRM it is too abstract to identify a thing with its spacetime volume. Below I start with a soft introduction and then present the issue(s). I have given links to documents which can be downloaded. These are ppt with 4 possible cases (case 3 is what is suggested) and concordance of the phrase “spacetime volume” in the CRM document. ppt: http://www.edd.uio.no/nedlasting/cidoc-crm/STV_suggested_changes.ppt concordance: http://www.edd.uio.no/nedlasting/cidoc-crm/kwic_spacetime_volume.txt Best, Christian-Emil The concept of spacetime volume is taken from physics. The idea is intuitive. Every physical thing has a volume, that is, occupies space (check your cupboard). When a cup is moved in the kitchen its volume will move relative to the kitchen floor and walls. Its place in the kitchen will depend on the time of the day. If the cup’s movement is registered in a 3D model, say every second , its whereabouts will look like some strange geometric figure. If the cups movement from it production to it is broken beyond recognition by a steamroller, this can also be a figure depending on time. So for any identifiable thing there will be a unique volume from it gets it identity until the identity is lost. This can be seen as a volume in a 4 dimensional space (X,Y,Z,T), that is, a 3D figure evolving over time. It should also be evident that such a 4D volume is unique for a physical thing. Two things describing the exact same volume during their lifetime can be considered the same thing. Instances of the class E92 Spacetime volume (STV among friends) are such 4 dimensional volumes. It is a handy abstraction which makes it possible to talk about a ship’s travel etc. The one to one relation between an identifiable physical thing and a spacetime volume is the reason to make E18 Physical thing a subclass of E92 Spacetime Volume, that is, every instance of E18 Physical thing _is_ an instance of E92 Spacetime volume. However, practical experience has shown that this is considered to be very abstract for most users of CRM. We have observed confusions and misinterpretations. It is reported to be very difficult to teach CRM with this construct. It is more intuitive to say that a physical thing has a spacetime volume than to say that a physical thing is a spacetime volume. Proposal 1: Replace E18 isa E92 Spacetime volume with a property PXXX: Pxxx has defining STV (is defining STV of) Domain: E18 Physical Thing Range: E92 Spacetime Volume Quantification: one to one, necessary (1,1:0,1) In the current model we also have E4 Period isa E92 Spacetime volume. This is more intuitive since something happening has a time and a place but no physical substance. On the other hand, it is arguable that two events may happen at the same time and same place. A simple example technical example are instances of E8 Acquisition and E10 Transfer of Custody, which may happen at the same time and place. More generally and perhaps more philosophically, when documenting the past, it is not uncommon to interpret something happing at a place and time as more than one event. If one accept this, then an instance of E92 Spacetime Volume is not in one to one relation with an instance of E4 Period, two instances of E4 Period can share an instance of E92 Spacetime Volume Proposal 2: Replace E4 isa E92 Spacetime volume with a property Pyyy Pyyy has defining STV (is defining STV of) Domain: E4 Period Range: E92 Spacetime Volume Quantification: one to one, necessary (1,1:0,n) This construct will solve the problem of P4 vs P160. Consequences for the current CRM (document): There only two properties that are a sub property of a property with STV as domain or range: 1) P46 is composed of (forms part of) 2) P156 occupies (is occupied by) P46 needs an adjustment of the FOL-definition (which also has an error as it is today). P156 is ok as it is (although its not so easy to understand) The scope not of the two classes E4 Period and P18 Physical thing has to be adjusted. There is a almost identical paragraph which can be deleted and reused in the scope note for the new properties. E18 Physical Thing: We model E18 Physical Thing to be a subclass of E72 Legal Object and of E92 Spacetime Volume. The latter is intended as a phenomenal spacetime volume as defined in CRMgeo (Doerr and Hiebel 2013). By virtue of this multiple inheritance we can discuss the physical extent of an instance of E18 Physical Thing without representing each instance of it together with an instance of its associated spacetime volume. This model combines two quite different kinds of substance:
Re: [Crm-sig] P72 has Language
Dear all, having somehow started this discussion in a hot August evening, let me remind you that the initial question was: "When describing biographical information [in an archive] it’s common to state that some person was fluent in some language, or languages, apart from his/her native one. Using current archival descriptions standards [ISAD(G) 3.2.2; EAD ] this is represented within a text, usually a very long text string with information of distinct natures. So far we have been able to decompose the different elements and represent them adequately as instances of CIDOC-CRM classes and link them trough the suitable properties. We cannot link a Person (E21) to a language (E56) and neither use multiple instantiation, as it has been suggested in other cases (http://www.cidoc-crm.org/Issue/ID-258-p72-quantification), because Person (E21) and Linguistic Object (E33) are disjoint.” I understand these bios consist in a text, and metadata are added to it as instances of various CIDOC-CRM classes. The question was how to indicate in such metadata the knowledge of a language as reported in the bio: so not a real quality of the person, but a fact documented. My suggestion was to use E74 Group. I always prefer to use what is already available and avoid the unnecessary proliferation of classes and properties, in my opinion there are already (more than) enough. But in doing so I try to maximize expressiveness, as otherwise one class (E1 CRM Entity) and one property (P2 has type) would be sufficient for the whole world: P2 is not a jack-of-all-trades. Reportedly, the Group solution seemed to please the person who made the question. I don’t know if the "language spoken" is an information usually taken into account in CH; but in this case it was by the archivist, otherwise no question would have been aaked. Best regards Prof. Franco Niccolucci Director, VAST-LAB PIN - U. of Florence Scientific Coordinator ARIADNEplus - PARTHENOS Editor-in-Chief ACM Journal of Computing and Cultural Heritage (JOCCH) Piazza Ciardi 25 59100 Prato, Italy > Il giorno 14 ott 2019, alle ore 22:39, Detlev Balzer ha > scritto: > > Dear George, Martin, > > this discussion made me curious whether or not I can confirm George's > assertion that such statements are common in the cultural heritage field. > > EAC-CPF does have a language element, which is, however, only used to > indicate in which language the name of a person or corporation is expressed. > > GND, the authority file for libraries in German-speaking countries, has a > Language entity which is used for making statements about the "field of > study" of a person. Other predicates for the person-language pair of entities > do occur, but these are obvious data entry errors. > > Having extracted person-related data from a dozen or more cultural heritage > projects, I don't remember any example where languages spoken or known by > somebody have been considered in any other sense than relating to the > documented activity, rather than to the (possibly un-instantiated) capacity > of the person. > > Of course, this is just an observation that doesn't prove anything. > Personally, I would tend towards Martin's view that there is little, if > anything, to be gained by defining such kind of statement in a reference > model such as the CIDOC CRM. > > Best wishes, > Detlev > >> George Bruseker hat am 14. Oktober 2019 um 19:45 >> geschrieben: >> >> >> Dear Martin, >> >> The conversation began with a use case from an archive. I just inform that >> this is also found in all the projects I work on for memory institutions. >> They find it in scope, so looking further afield for what anthropologists >> do doesn't seem like a necessary step? Though highly fascinating! >> >> Best >> >> George >> >> >> >> On Mon, Oct 14, 2019, 6:58 PM Martin Doerr wrote: >> >>> Dear George, All, >>> >>> As a second thought: >>> >>> I think documentation formats such as LIDO are an adequate place to add >>> such useful properties to characterize items in a more detailed way, we >>> would not put in the CRM analytically. Shapes, colors etc. being typical >>> examples. >>> >>> Question: Are there formats from the archival world that use to describe >>> the languages people speak? EAD CFP? >>> Libraries are interested in the languages someone publishes in, not >>> speaking. >>> >>> What are the anthropologists registering? Would they be interested in >>> languages learned at school, or rather in the language used for >>> communication in a typical group? Would they document people being >>> incapable of communicating in that group? >>> Or just infer language via group? >>> >>> How to distinguish native speakers from non-native? >>> >>> Would historians make cases of people that could not communicate in a >>> given language, with societal effects? >>> >>> What about illiterate people? Speaking, not writing...? Maintaining oral >>> history with great precisi
