[Crm-sig] partial HW for issue 556
Dear all, Please find homework regarding the Issue 556 here: https://docs.google.com/document/d/1aPdMX-vlc5xG2LxrpZTPhVwBm0CrDpno/edit BRs Athina ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc
Dear George, all, I am not sure that the class PC0_Typed_CRM_Property should be a subclass of E1. In my understanding, this class implies a situation concluded in an epistemological context. I am also not sure if the provenance we are looking for in this set of statements is a kind of E13. I am just wondering. BRs, Athina On 2023-03-29 16:36, George Bruseker via Crm-sig wrote: Dear all, When using the PC classes modelling structure we end up with a class node for a property which we can then modify with things like 'kinds' and 'modes' etc. Since such a statement has meaning and comes from somewhere [e.g.: that someone did something in some capacity (PC14 carried out by ... P02 has range E39 + P14.1 in the role of E55)] one sometimes needs to provenance this statement with an E13 attribute assignment. Ie we want to ground who made this claim. In theory this would be done with E13 pointing to the node in the typical fashion (p141, P140). However, the class PC0_Typed_CRM_Property is not declared as a subtype of E1 CRM Entity in the PC extension file. As a result we cannot do this. https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs I would argue PC0_Typed_CRM_Property should be declared a subclass of E1_CRM_Entity. Then it would be consistent with the rest of the modelling. Opinions? Best, George ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] Typo in Archaeo RDFS?
Dear George, it has been renamed and the crm-sig accepted the change of the label of S20 Physical Feature to S20 Rigid Physical Feature on the 37th joined meeting of the CIDOC CRM SIG BRs, Athina On 2023-01-20 13:44, George Bruseker via Crm-sig wrote: Dear all, Whilst doing some Archaeo implementation in Arches, Takin.solutions noticed a typo in the latest stable RDF for archaeo. 1.4.1 https://cidoc-crm.org/crmarchaeo/ModelVersion/version-1.4.1 The RDF reads: Stratigraphic Unit This class comprises S20 Physical Features that are either A2 Stratigraphic Volume Units or A3 Stratigraphic Interfaces http://www.cidoc-crm.org/cidoc-crm/CRMsci/S20_Physical_Feature"/> The reference to S20 is Physical Feature but should be Rigid Physical Feature. I think S20 was always called "Rigid Physical Feature". If so this seems to be a typo and should perhaps be corrected? Cheers, George -- George Bruseker, PhD Chief Executive Officer Takin.solutions Ltd. https://www.takin.solutions/ ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] issue 557
Dear all, Regarding my HW (refer the publicly accessible archival material from SeaLit and find the fields that Spectrum uses to document museum transactions), you can find the reference in this doc https://docs.google.com/document/d/1r5mgVbLmD3bwjgaWkyQapHedpplSvXEe/edit#heading=h.gjdgxs and a selection of related Spectrum categories in this https://docs.google.com/document/d/1zsoc6tCRum6OuTSveqqbpuX9D1UoRjyt/edit#heading=h.gjdgxs There is also helpful material regarding Spectrum (https://drive.google.com/drive/folders/1HyVxXE456MEx4MycNk3gf4UtjvANvx4H), such as an old mapping (SPECTRUM TO CIDOC CRM) and the model I proposed during 52 CIDOC CRM Meeting) BRs Athina ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] HW ffor issue 587
Dear all, Please find homework regarding the research queries prepared by me and Pavlos for Issue 587 here: https://docs.google.com/document/d/12tq1mXe4EFoZEgtyKxyN4vi0kqfUZfgj/edit BRs Athina ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] issue 623
Hello all, I reformulate the issue, adding background information regarding a few classes, that would be helpful for the discussion: Problematic" examples randomly shift from the present to the past tense (f.i. O7, O13), have been marked as "not revised" (anyhting in highlight) or simply "missing". Classes/ properties whose examples need be revised include: S9 (S9 Property Type: issue 332: It is postponed, it should be considered together with the issue related to redoing S4 - the review of the definition of this class has been postponed), S15 (issue 332:It is postponed because the whole entity is under review), S20 (issue 332: sig accepted the examples but asked Athina to improve the syntax of 4th example), S22 (issue 332: the sig reviewed the scope note and decided to ask SS and MD to elaborate it further up to the next meeting. The example is rejected. We need an example of a ‘baulk’ from an archaeological record), S23 (related to the open issue 612), O3, O4, O5, O6, O8, Ο10, Ο11, Ο13, Ο15, Ο17, Ο18, Ο19, Ο20, Ο21, Ο23, Ο25 Athina ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] NEW ISSUE regarding CRM SCI: UPDATE THE SCOPE NOTE OF S3
Dear all, Regarding the issues 537 and 531 and specifically the discussion on the implications of the decision to classify E16 Measurement as a subclass of S21 Measurement in CRMsci, I realized that this is not reflected in the current scope note of S3 Measurement by Sampling. In my opinion, the phrase "inherits...the properties of S21 (E16) Measurement. P40 observed dimension: E54 Dimension, ..." is no longer valid and should be changed. BRs, Athina ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] New Issue: Delete E35 Title
Dear all, I follow up this comment with the information that the issue is 340 (apart from 533 for E34) and the minutes is from 44th crm-sig meeting. For me, the formulation of the CRM issues list is very important and helpful to such questions arising regarding the standard. BRs Athina On 2022-11-09 15:51, Martin Doerr via Crm-sig wrote: Dear Robert, All, To my best knowledge, Title, Site and Inscription had been on the list of classes potentially to be deleted, when the current principles for minimality had been formulated. The respective decision not to delete is documented in some minutes. It was extensively discussed and voted. Following our rules, this decision can only be undone in a new issue, if new, different evidence is provided. This rule is to ensure some continuity for a standard, and economy of work. Currently, I see no new evidence. Best, Martin On 11/8/2022 10:33 PM, Robert Sanderson via Crm-sig wrote: I propose that E35 Title also does not legitimately rise to the requirements of being a named class in CRM Base. In particular: * It does not have its own properties * While it is the range of P102, P102 is indistinguishable semantically from its super-property, P1. Read the scope notes and replace "title" with "name" and it comes out the same. If that is *not* the case, then we would need a property that relates E1 and E33_E41_Linguistic_Appellation, at which point we would need to give a number of E33_E41. * It can be replaced without semantic loss by E33_E41_Linguistic_Appellation, perhaps further clarified by the addition of domain specific vocabulary (supplied title vs artist's title) using P2_has_type * It does not have any sub-classes. And so, it can safely be deleted. Rob -- Rob Sanderson Director for Cultural Heritage Metadata Yale University ___ Crm-sig mailing list Crm-sig@ics.forth.gr 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 Web-site: http://www.ics.forth.gr/isl ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33
Dear all, I fully agree that we must follow the principles of the ontology development and remove classes that do not fulfil the criteria of being classes in CRM Base. But, in my opinion, for specific classes of this kind (that they seem not to fulfill the criteria because they don't have properties ), such as Inscription, we should make an issue not to delete, but to discuss the alternatives of removing this class and maybe to remember the initial purpose of use of this class or to find if there is an open issue regarding this - For E34, there is the issue 533; So, my question is: what about the classes that we have introduced in CRM base or in other compatible models, such as S7 Simulation or S5 in sci, which have no properties at all, but, as I remember very well, the argument for introducing them (I am speaking for sci) was that that they are domain specific but we haven't yet developed them, but we intend to do so in future. - should we delete them? E34 has not been developed, in my understanding, and it is now replaced by CRM tex. So the issue , in my opinion, should be (for this class) how we sychronize and not delete. BRs, Athina On 2022-11-08 23:25, Mark Fichtner via Crm-sig wrote: Dear all, while I must agree with Rob that the three classes he proposed for deletion are not a particular best pratice in ontology building from a semantic point of view, I don't feel good with the direction the CRM is going currently. At our museum we are following the CRM because it is the only "really standardized" standard for our domain. It is expressive enough for a full top level ontology while also covering the domain of cultural heritage. We are not interested in yet another standard that maps metadata in a very common way - we have enough of these and if we would want to use dublin core we would do so. The full potential of the CRM is what binds us to using it. Concepts like "Title" are really important for our domain - it is one of the most important metadata fields for documentation in our museum. With the abolishment of properties and classes in CRM Base that were used a lot in the past the SIG and the CRM takes a turn away from the museum side of documentation towards being a very general ontology. While I know development may always hurt a little bit, this does not feel right in any way anymore. I am asking myself: Is this really what the CIDOC CRM should do? Is it possible for the CIDOC CRM to survive in comparison to standards that are more widely spread while abolishing it's own user base? Do we really want a domain ontology - extending CRM Base called "CRM Museum Documentation Ontology" because we throw out everything that is museum related out of CRM Base? At least I might have my long loved E84 Information Carrier back there... :D No offense intended - just my two cents and the perspective of the GNM Nürnberg on the current CRM development... Best, Mark Am Di., 8. Nov. 2022 um 21:51 Uhr schrieb Robert Sanderson via Crm-sig : Thank you for the clarification, Martin! I have proposed the justifications for deleting three further classes that do not, I believe, fulfil the criteria of being classes in CRM Base. And indeed, let us judge these objectively and by the given criteria, rather than subjective and personal preferences. If we come across a class that we simply cannot delete without irreparable damage to the ontology, at *that point* let us reconsider the criteria as being incomplete. Thanks again, Rob On Tue, Nov 8, 2022 at 2:24 PM Martin Doerr via Crm-sig wrote: Dear All, I just want to remind that we have a principle explicitly in the introduction of the CRM not to add classes without distinct properties of their own which is sufficiently relevant. By this, we purged a lot of very useful classes from the CRM, because it is "base". I prefer not to hear again "if we don't like a class". I kindly ask members to delete such terms from our vocabulary. Any argument in favour of a class in CRMbase which is nothing more semantics than multiple IsA, must be measured by this principle, and not by likes. If the principle is to be abandoned again, please make an issue. If the principle is unclear, please make an issue. Any issue for adding more custom classes to RDFS, to be discussed. Best, Martin On 11/8/2022 5:46 PM, Pavlos Fafalios via Crm-sig wrote: Dear George and Robert, Your comments are well taken and understood. I do not take a position against or for the addition of this class (I'm not yet sure of either decision), nor I support that "rules" must be always respected. I just tried to find a good reason for not having already introduced such a class (and thus facilitate the discussion). Best, Pavos On Tue, Nov 8, 2022 at 5:00 PM Robert Sanderson wrote: I agree with George that this should be added. There are plenty of cases of classes without additional properties that serve only to join two parent classes. For example E22_Human-Made_Object,
[Crm-sig] NEW ISSUE regarding CRM SCI
TITLE: UPDATE SYNCHRONIZATION BETWEEN CRM BASE AND CRM SCI Dear all The last decision on updating the range of P112 diminished (issue 574) requires to also update the O1 diminished property in SCI, in which the P112 is declared with the previous state. BRs Athina Kritsotaki ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] CALL FOR E-VOTE ISSUE 581
Dear Francesco, First of all, your comments are all welcome, I think there has been a long discussion on observations and observable entities in context of CIDOC CRM, so I will not focus in that - I am not sure if this discussion is about which methodology is most appropriate: bottom up or top down- we all know the advantages of bottom up methodology for real knowledge management applications – (discover ontological knowledge at a larger scale and a faster pace; detect and revise human–introduced biases and inconsistencies -support the refining and expanding of existing ontologies by incorporating new knowledge emerging from texts - result in a very high level of detail , etc). From my understanding and after discussions with historians of sealit project is that legal relationships are quite complex (since I am not an expert – a specific methodology and discussion with the domain experts, historians, real cases, using an ISO standard, etc. helps) and that we have to check what kind of information we find in registrations, in cadastre, as you said, etc. what kind of dates, are these dates the boundaries of these legal relationships or do we have actually a documentation from the sources of the full evolvement of a right holding case? I am just asking - A right holding can start or end with a legal act or also can end with the death of the holder - which is then the validity period of this phase? I am just asking. Do we have knowledge on that ? (from real data documented)? For the sealit project we had very specific information to model but we also didn’t want to include bias by modelling, for example, exhaustive concepts on which we don’t have a very good knowledge on them. But as I said to the previous mail, the model is under development and can be improved - the more information and feedback from the historians, the better - and that is an advantage, in my opinion, of the bottom up methodology. BRS Athina On 2022-03-01 11:47, Francesco Beretta wrote: Dear Athina, Thank you for taking of your time and for making explicit the reasons of your modelling choices and methodology. As University trained historians, we know that the model of the information produced by a project generally depends on the research agenda and the available sources. The model of a project is therefore not an ontology in the sense of a conceptualisation allowing for multi-project interoperability. Even the way of modelling a ship's voyage may change according to the lines of inquiry of different research projects. For this reason, a strict bottom-up modelling methodology in the field of historical research, and more broadly in the social sciences, without foundational analysis, doesn't seem to be the most appropriate way of producing an ontology for the whole portion of reality —a quite relevant portion in the cultural heritage perspective— these disciplines are concerned with. Regarding the ownership of a ship (https://en.wikipedia.org/wiki/Ship-owner), which in French is in some contexts referred to under the technical term 'armement' (https://fr.wikipedia.org/wiki/Armement_(marine) — cf. "registration activity" below), the social fact of ownership is as such and in general —in the sense of ontology— observable. One can ask sailors or informed contemporaries and they will know who the owner of the ship is. There are historical sources, for example correspondence, which attest to the role of shipowners (_armateurs_) of such and such a person or company, even if we have lost the shipping registers which state the events of taking ownership. In the Sealit project, a methodological choice or stance was adopted which is certainly legitimate in the project's context, but which one should avoid to generalize stating e.g. that ship ownership is not directly observable, as this would be in contradiction with observable reality. Besides the collective, attested and observable knowledge of ownership, there are, for other subdomains, written statements about it. One has to think of the land registry documents (https://en.wikipedia.org/wiki/Cadastre) which often attest to the social fact of land ownership, or other rights on land, without necessarily knowing where it comes from. These rights are observable and part of reality as evidenced by the recent trials and convictions of climate activists who have occupied and organised unauthorised events at the headquarters of private companies, on the basis of infringement of private property. So should one intend that social bonds, ownership, etc. are —in general and as such— not observable does not seem to be very prudent because the fact of generalising a specific method of modelling whose foundation and epistemological principles have never really been made explicit (in their foundational, philosophical aspects) risks compromising the possibility of adopting such an ontology by entire scientific communities, such as the social sciences, historical sciences,
Re: [Crm-sig] CALL FOR E-VOTE ISSUE 581
Dear Francesco, dear all, There may be a misunderstanding regarding the class Legal Object Relationship, which I explained in the presentation in the last sig meeting: We defined this class in a sense of a state of ownership of a ship, which is a kind of information that can be inferred (implicit knowledge) and not directly observed – it can be observed by the starting and terminating event of this state. It is like the soc Bond, which describes social/legal relationships that cannot be observed. We strictly follow the modelling principle which refers that we model from actual information sources that reveal actual practice- according to the historians of the sealit project, a ship ownership phase is described as a state with the only information documented to be about the ship owner, the shares that may have and the name of the ship, not the dates of this ownership (which is a quite complex phenomenon to observe since a person e.g may possess up to 1/48 of a ship, so you can understand how many ships shares a single person could have in the same time and there is no documented information on the timespan of this shareholding. Additionally, the ownership is used to assign a name to a ship and a ship changes its name under an ownership state. However, additional temporal information on these names under ownership states is not documented in the source – the Ownership phase can be traced by the ship registration activity (that includes timespan information) that initiates it and by the de-flagging, both events that are documented. This is material evidence, coming from the source. If you open a Loyd catalogue, you will find these information under ship registration without dates on the owners of the ship. Another modeling principle that is represented in our decision to leave Legal Object Relationship as a subclass of E1 CRM Entity is that we support the progressive improvement of classification knowledge by IsA hierarchy. Since we don’t have enough knowledge and we support the open world assumption, which means that new evidence may change the classification, we prefer to model the more general (here we classified under E1) and then, when we have more precise knowledge by instances on the nature of this Legal Ob.Relationship class, then we can progressively specialize and refine the E1 and find the superclass under which Legal Object Relationship fits. Sealit is a model that is based on data input, it can be refined and improved based on new knowledge, new instances. I just wanted to explain this logic under which the model was constructed and to prove that it is one of the most representative documentations from material evidence we had, in our experience. So I am a bit confused how this use case supports raising philosophical questions regarding issue 581. My BRs, Athina On 2022-02-25 12:29, Francesco Beretta via Crm-sig wrote: Dear Martin, dear Franco, I assume that the same question by Franco (Issue 581) is raised by page 25 ? " What goes on in our minds or is produced by our minds is also regarded as part of the material reality, as it becomes materially evident to other people at least by our utterances, behavior and products. " " priority of integrating information based on material evidence available for whatever human experience." " The CIDOC CRM only commits to a unique material reality independent from the observer." Cf. the new proposition below: " As “available documented and empirical material evidence” are regarded all types of material collected and displayed by museums and related institutions, as defined by ICOM[1], and other collections of things providing evidence about the past, in-situ objects, sites, monuments and intangible heritage relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history, history of sciences and technology. " It seems to me that these 'fussy' questions raise in fact, once again, the relevant Issue 504 concerning the philosophical underpinnings of CRM. The consequences of this approach are illustrated by the recently published Sealit project ontology, class: Legal Object Relationship (e.g. property of a ship by some actor): "This class comprises legal object relationships of which the timespan and the state (of these relationships) cannot be observed or documented. We can only observe these relationships through the events that initialize or terminate this state of relationship (starting event and terminating event). " I'm not sure how many domain experts would agree with this definition because ownership of things, as a fact, is attested in written texts, or even in minds of living persons and expressed in utterances, and these are empirically observable. The here adopted foundational stance excludes this fact (i.e. property) from being a subclass of E2 Temporal Entity. Legal Object Relationship is declared as subclass of E1 Entity. But on page 33 of the
Re: [Crm-sig] Modelling an Event's General Outcome Ideas? Properties?
Hi George, as far as I know, there is no other property from current CRM properties that have E55 Type as range and fits for your case, apart from P21. Another solution would be to use P134 continued for expressing a coherence of outcomes between activities, but again this property does not have E55 as range (you will not avoid a full path), so it doesn't help a lot. Best, Athina Στις 2021-12-14 21:42, George Bruseker via Crm-sig έγραψε: Hi Thanasi, Yes that's true. Good reminder. That might be a solution but then we would need the particular property for expressing that two events are causally connected. I avoided to put it in the last email so as not to stir up to many semantic teapots. But obviously to have the general property we should have the particular property. So we have for example we have the particular properties: https://cidoc-crm.org/Property/P20-had-specific-purpose/version-7.1.1 and https://cidoc-crm.org/Property/P21-had-general-purpose/version-7.1.1 so the analogy to this in my situation is probably O13 triggers (is triggered by) https://cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.4.pdf and we need the analogy of p21 to make the model complete On another note out of curiosity, in the extension where every property has a 'type of' property what happens with the extant 'type of' properties? I assume there isn't any has general purpose of type property... or is there? Cheers G On Tue, Dec 14, 2021 at 9:20 PM Athanasios Velios via Crm-sig wrote: Hi George, all, As part of Linked Conservation Data (and with the help of Carlo, Martin and Steve) we proposed the idea of Typed Properties which derive from current CRM properties and always have E55 Type as range. E.g. "bears feature" → "bears feature of type" so that one can describe the type of something without specifying the individual. It is very economical in conservation where we want to avoid describing hundreds of individuals of similar types. We are still baking the exact impact of such a reduction from individuals to Types. One issue in RDFS is the multitude of new properties. There seems to be a simple implementation in OWL with property paths. Not an immediate solution but a flag for more to come. All the best, Thanasis On 14/12/2021 15:49, George Bruseker via Crm-sig wrote: Hi all, I have situations in which I have events where the data curators describe events for which they have generic knowledge of the outcome: sold, completed, incomplete, this sort of thing. So there is knowledge but it is not knowledge of the particular next event but of a general kind of outcome. We have properties like: P21 had general purpose (was purpose of) which is very useful for when the data curator only has generic knowledge knowledge and not particular knowledge regarding purpose. This seems a parallel to this case. Anybody else have this case and have an interest in a property like 'had general outcome' or 'had outcome of type' that goes from Event to a Type? Or, better yet if possible, a solution that doesn't involve a new property but that does meet this semantic need without too many contortions? Best, George ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] Fwd: Re: sealit ontology
Dear all, Philip Actually this work was meant for Pavlov, so by mistake it was sent to the list. It is an ongoing project, not published yet, but I am really happy that some of you find it really interesting - we can discuss this and we can always exchange opinions of course Best Athina December 13, 2021 6:20 PM, "Carlisle, Philip" wrote: > Hi Athina, > This is REALLY interesting and very timely for a project we are undertaking > here in the UK. > > We (Historic England) are currently beginning development of a National > Marine Historic Environment > Record using the Getty funded Arches platform which, as you may know, uses > the CRM and its > extensions as its core ontology. > > We currently have legacy data which perfectly matches the SeaLiT extension. > Namely wreck sites of > vessels which were trading in the waters around England and the UK from > Prehistory to the Present. > The legacy data was held in a bespoke Oracle database and the ETL process > will take the legacy data > and model it as a Vessel (Ship) with an associated Wreck site (where known) > I'd be interested to > discuss our approach and to feedback on the SeaLiT ontology if you think that > would be helpful. > > Regards > > Phil > > Phil Carlisle > Data Standards Specialist > Information Analysis > Policy and Evidence Group > Historic England > Direct Dial: +44 (0)1793 414824 > Mobile: +44 (0)7768 656427 > > Many Historic England staff are working remotely at the moment and we are > doing what we can to > maintain our level of response but please bear with us as this may be slower > than usual. > > http://www.heritagedata.org/blog > > Work with us to champion heritage and improve lives. Read our Future Strategy > and get involved at > historicengland.org.uk/strategy. > > This e-mail (and any attachments) is confidential and may contain personal > views which are not the > views of Historic England unless specifically stated. If you have received it > in error, please > delete it from your system and notify the sender immediately. Do not use, > copy or disclose the > information in any way nor act in reliance on it. Any information sent to > Historic England may > become publicly available. Please read our full privacy policy > (https://www.historicengland.org.uk/terms/privacy-cookies) for more > information. > > -Original Message- > From: Crm-sig On Behalf Of athinak via Crm-sig > Sent: 07 December 2021 12:51 > To: Pavlos Fafalios via Crm-sig > Subject: [Crm-sig] sealit ontology > > THIS IS AN EXTERNAL EMAIL: do not click any links or open any attachments > unless you trust the > sender and were expecting the content to be sent to you > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] enhmerwsh
καλημερα Παύλο, ηθελα να ενημερωσω οτι ειμαι σε αδεια Τρίτη Τεταρτη και τις υπολοιπεσ μερες θα δουλευω απο το σπιτι - την οντολογια ακομη τη δουλευω γιατι δεν εχω τελέιωσει με τα παραδειγματα, μολις τελειωσω θα στη στειλω χαιρετισματα Αθηνα ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] CRMSci O19 Property Labels Minor Correction?
It is true it is linked to the Encounter Event, so, native speaker can find a better phrase for this Brs Athina October 22, 2021 3:21 PM, "melanie.roche--- via Crm-sig" mailto:crm-sig@ics.forth.gr?to=%22melanie.roche---%20via%20Crm-sig%22%20)> wrote: Dear George, I share your concerns. Being unfamiliar with CRMsci in general and O19 in particular, when I first read your mesage I immediately assumed that the inverse property pointed to a place. As a non-native English speaker, I agree that there is a very strong locative flavour to the preposition "at", and it would be totally counter-intuitive to associate it with an event. I also feel the same applies (though less strongly) to "in". If we want to exclude any kind of locative flavour, would the preposition "during" be appropriate, or would it only work for some events but not all? Best, Mélanie. De : "George Bruseker via Crm-sig" mailto:crm-sig@ics.forth.gr)> A : "crm-sig" mailto:Crm-sig@ics.forth.gr)> Date : 22/10/2021 13:43 Objet : [Crm-sig] CRMSci O19 Property Labels Minor Correction? Envoyé par : "Crm-sig" mailto:crm-sig-boun...@ics.forth.gr)> Dear all, I am manually correcting some ontology files (horror) and changing the nomenclature from the previous names for O19 which were: has found object (was object found by) up until version 1.2.6 of the document. Then it changed, rightly (mostly), to: encountered object was object encountered at which is how it has been ever since. So, what's my problem? The inverse property label sounds like we named it poorly? Particularly the preposition 'at' has a locative flavour that to me would indicate that the object pointed at would be a place. The object pointed at, however, is of course the encounter event. I do not remember if we made the choice above on purpose or if this is just a mistake, but reading it now it strikes me as not the best choice. I think typically we would use 'by' (which is also problematic since sounds like it should point to an actor) or maybe 'in' which again sounds slightly locative, although might work better with an event. Anyhow, does anyone else see this as a problem or is it just me? Best, George___ 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) Découvrez toute la programmation culturelle de la rentrée à la BnF (https://www.bnf.fr/fr/agenda) Pass BnF lecture/culture (https://www.bnf.fr/fr/pass-bnf-lecture-culture) : bibliothèques, expositions, conférences, concerts en illimité pour 15 € / an – Acheter en ligne (https://inscriptionbilletterie.bnf.fr/) Avant d'imprimer, pensez à l'environnement. ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] New Issue: Non-human Actors
Hello, I am probably missing something here, but regarding these databases, in which cases these animals are documented as actors? It seems that there are documentations about births and traps and capturing events, but the discussion is about activities carried out by them, right? From my experience with gbif and darwincore, which a standard that is widely used for biodiversity databases, haven't seen definitions of this kind of relationships, but maybe I am missing things or I misunderstood something BRs Athina Στις 2021-10-12 10:02, George Bruseker via Crm-sig έγραψε: Hi all, Here are some examples of databases that deal with individual or collectivites of animals NOT as THINGS but as AGENTS: EMU: Pest Tracking in Museums http://help.emu.axiell.com/v6.4/en/Topics/EMu/Traps%20and%20Pest%20Events%20modules.htm Here's a database that tracks the migratory paths of individual birds: https://nationalzoo.si.edu/migratory-birds/migratory-birds-tracking-map Here's a database that tracks orcas: https://theorcaproject.wordpress.com/killer-whale-orca-database/ Here's a database that tracks gorillas: https://www.gorillasland.com/la-plaine-zoo.php I would say that often something doesn't get documented because it is silenced by the information systems available (see the terrible gorilla database), arguably what CIDOC CRM is supposed to aid in getting out of (viz. Dominic's textual works issue and documenting context). The fact that people are forced to shoehorn identifiable individuals that they want to document and have discourse about into classes that do not suit them is for me the obvious argument for making classes and properties! Whether there are explicit fields for such data, the natural world is something which unsurprisingly Cultural Heritage is interested in and refers to. Orcas are, for example, highly important animals within different cultural systems in Canada, they are documented and they are documented not as things but as agents. So what is the pressing counter point to allowing this expressivity? That there are too many classes and properties. Many would make that argument about CRMinf or about any of our extensions. I suppose it depends on where you interest lies. By not opening these categories we effectively mute/suppress this voice. Because the limits of the world are my language when we choose to oppress a class we choose to oppress the ability to express that object. Or we indeed force the documentation of things that are considered agents as objects. This seems the greater harm to my mind. On the expertise question, I am not sure if we required a biologist to be able to model the notion of Birth or Death. Did we not use a middle level understanding of everyday objects and their documentation in systems in order to be support the recording of standard kinds of facts of interest to a researcher? Birth and Death are not high concepts of when conception begins or when the soul leaves the body, they are rough and ready everyday ideas of, there was a person and an event led to its end, there was a person and an event led to its death. How the case of modelling animals differs is not clear to me. Did we bring in financial experts model the payment class? On which issues we need an expert and on which issues not is not clear, nor is that expertise counts. As Rob says, having many years of experience in cultural heritage documentation and analysis of such systems does not count? I would think in basic matters like this, it goes back to the ground of coming to a common sense modelling in line with what is considered the best state of knowledge regarding the world. We KNOW that the best state of knowledge is not represented by the present modelling because agency is not just attributed to human beings. Therefore, we are presently deliberately out of synch with the best state of knowledge. I would think it behooves (pun intended) us to step up to the plate and get on to making it possible to express basic facts about the world that can be and are referenced in CH data systems (such as the existence of animals!). Best, George On Tue, Oct 12, 2021 at 1:19 AM Pat Riva wrote: Hi Rob, Looking at the dates on Lassie and Misha, I see that they were created during the phase when people were trying this under an unwise modification to RDA, and not been revised since. This would no longer be valid under the latest RDA. And no one has bothered to propose MARC coding specific to this type of heading, leading to the ones that were created being shoe-horned into the personal name coding. The proportion of the huge LC names file is too small. As for the fictitious, that was a completely different argument that has also lasted years. Stems from a difficulty in distinguishing between a name and the reality behind it. But these two issues are frequently conflated in the library world by people trying to use discussion related to why one was invalid to imply the position on the other
Re: [Crm-sig] Modelling 'Transcription' Advice?
Dear George the simplest solution I have used for very basic cases, such as, I want to assign the transcribed content (without identifying A) to B was: B (E73 Information Object or E33): P3 has note.P3.1 has type:"transcription" and the string is the content note. This is the content. However this doesn't work if you need to have A as an instance with identity (you use other paths in that case, as you mentioned) BRs Athina Στις 2021-07-20 12:38, George Bruseker via Crm-sig έγραψε: Dear all, Just a general question to the crowd. Sometimes one has transcribed data of a very simple form. A is supposed to represent B and it has been copied by someone with the intention of so doing. A is a transcription of B A [E33] is a transcription of B [E33] This could be modelled numerous ways using CIDOC CRM. If one is looking for the most direct/binary way, I suppose that the only choice is "p130 shows features of". If you wanted to capture the mode of relation then you would use p130.1 has type and indicate 'transcription'. I notice, however, that we do have 'has translation' as a sub property of P130 shows features of, as an apparently useful to the community binary property specializing P130 to that specific scenario. Has anyone else done modelling of transcriptions before with the aim of not recording the event but only the binary relation and if so, did you come up with any interesting solutions? A property would be handy in case anyone has created and published a specialization that could just be reused? Thanks for any insight! Maybe I miss an obvious trick from LRM? All the best, George ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
