or to put it another way, if one only lived in a world of CRMese and knew nothing else about the world in itself, understanding what E33_E41 is is just a question of understanding what E35_Title is and then taking the conceptual leap that it can be applied to E1. That's it! Names, in a language, can be applied to anything, in human societies. And they often are, and in documentation, and so the standard should represent it and perspicuously document that representation. Not everything is totally inscrutable.
On Wed, Nov 9, 2022 at 5:13 PM George Bruseker <george.bruse...@gmail.com> wrote: > Dear both, > > I have to agree with Robert, I basically can't even conceive how this is > an argument. Obviously names come in languages MOST of the time. This is a > basic feature of living in a human society, is it not? Is this not a base > experience of being embodied as a human being that we all commonly have > access to and is an undeniable reality? We live in language. We name things > in language. > > But if we need to show that it was documented in a database, here are some: > > Getty AAT wrenches > > https://www.getty.edu/vow/AATFullDisplay?find=spanner&logic=AND¬e=&english=N&prev_page=1&subjectid=300024714 > > Wrench has a name in many languages. > > Here is geonames: > > https://www.geonames.org/6094817/ottawa.html > > Ottawa, has many names in different languages. > > Here is VIAF > > https://viaf.org/viaf/15873/#Picasso,_Pablo,_1881-1973 > > Picasso has names in different languages. > > This could be done ad infinitum. How many databases should be listed > before this is accepted as an empirical part of reality documented in CH > and needing a class? > > Cheers, > > George > > > > > > On Wed, Nov 9, 2022 at 4:49 PM Robert Sanderson via Crm-sig < > crm-sig@ics.forth.gr> wrote: > >> >> To re-merge the threads, apologies for the duplication... >> >> The language of an E33_E41 is the language in which the linguistic >> content of the entity is expressed, per P72_has_language. >> >> For example, >> >> The language of the name of Douglas Adams (the Person) that has the >> symbolic content of "Douglas Adams" is English. >> The language of the name of Douglas Adams (the Person) that has the >> symbolic content of "دوغلاس آدمز" is Arabic. >> >> These are clearly expressed in a language, and appellations, and symbolic. >> >> Or: >> >> eg:Q42 a crm:E21_Person ; >> crm:P1_is_identified_by [ >> a crm:E33_E41_Linguistic_Appellation ; >> P190_has_symbolic_content "Douglas Adams" ; >> P72_has_language <uri-for-English> ] >> crm:P1_is_identified_by [ >> a crm:E33_E41_Linguistic_Appellation ; >> P190_has_symbolic_content "دوغلاس آدمز" ; >> P72_has_language <uri-for-Arabic> ] >> >> E33_E41 is a super-class of E35, which is semantically narrower through >> its scope note as applying only to "works", and "can be clearly identified >> as titles due to their form". I don't think anyone would say that "Douglas >> Adams" is the "title" of the person. >> >> Rob >> >> On Wed, Nov 9, 2022 at 9:05 AM Martin Doerr via Crm-sig < >> crm-sig@ics.forth.gr> wrote: >> >>> Dear All, >>> >>> I would like to focus on the semantic questions wrt E33_E41. Would it be >>> well defined? Please remember, that there were implementation arguments >>> against multiple instantiation, not semantic ones. Therefore, we decided >>> to solve the problem in the implementation side. Why the unlucky choice >>> of two different labels now would warrent a deeper semantics is not >>> clear to me. We can solve the issue by deciding a label. >>> >>> If there are possibly deeper semantics, as I indicated in my last >>> message, could we specify this? >>> >>> Is the language of an E33_E41 a created within, made for, used by? Is it >>> language or language speakers? What substance makes an Appellation >>> "languageable"? >>> >>> Can someone take a position? If this stays unclear, I vote for the >>> current solution. >>> >>> Cheers, >>> >>> Martin >>> >>> On 11/9/2022 10:46 AM, athinak via Crm-sig wrote: >>> > 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 >>> >> >>> >>> -- >>> ------------------------------------ >>> 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 >>> >> >> >> -- >> 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 >> > > > -- > George Bruseker, PhD > Chief Executive Officer > Takin.solutions Ltd. > https://www.takin.solutions/ > -- 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
