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 <azarot...@gmail.com> 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, > E25_Human-Made_Feature, and E34_Inscription. There are also remaining leaf > nodes with no properties with only one parent class, such as E27_Site. > Further, there are classes that have a property, but which is semantically > indistinguishable from its super property. If the requirement is a > property, then I propose > > Pxx_is_named_by (names) > Domain: E1 > Range: Exx_Name (previously E33_E41) > Sub Property Of: P1_is_identified_by > Super Property Of: P102 has title > > This property describes the naming of any entity by a name in a human > language. > > And the > Exx_Name > Super Class: E33, E41 > Super Class Of: E35 Title > > > The discussion last time devolved to "Well we use those so we don't want > to get rid of them so we're not going to even though they don't have > properties". But here's the thing ... *everything* has a Name (by which I > mean an E33_E41_Linguistic_Appellation). And it's easy to demonstrate that > E33_E41 is very well used. > > So ... I don't find the argument that we can't do this "because rules" > very convincing when those rules are applied so inconsistently. > > Rob > > > > On Tue, Nov 8, 2022 at 9:18 AM Pavlos Fafalios via Crm-sig < > crm-sig@ics.forth.gr> wrote: > >> Dear George, >> >> To my understanding (without having been involved in the >> relevant discussions about having the E33_E41 class in the RDFS but not in >> CRM), >> and according to the discussion in issue 363 >> <https://cidoc-crm.org/Issue/ID-363-form-and-persistence-of-rdf-identifiers> >> , >> classes that use to co-occur on things simultaneously without being >> associated with properties only applicable to the combination of such >> classes, are not modelled individually as subclasses of multiple parent >> classes (a principle used for keeping the ontology compact). >> >> The 'E35 Title' class exists because there is a property 'P102 has title' >> (of E71 Human-Made Thing) that needs to point to something that is both a >> linguistic object and an appellation. >> So, for having a CRM class "E? Linguistic Appellation", there should be a >> property that needs to point to something that is both a linguistic object >> and an appellation (and with the intended meaning), e.g. a 'has linguistic >> appellation' property for E39 Actor or E77 Persistent Item. To my >> understanding, since there is no such property, there is (currently) no >> need to introduce such a class in CRM. >> >> Best, >> Pavlos >> >> >> >> On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig < >> crm-sig@ics.forth.gr> wrote: >> >>> It's not really though. In the majority of cases when you talk about a >>> name you need to talk about a language too. Especially if CRM wants to be >>> inclusive etc. We have a subclass 'title' of appellation that does allow >>> but it only works for inanimate objects. So it is useless as a general >>> case. The use of E33_E41 should be a default in most modelling cases with >>> E41 being the exception (mostly names are in a language). The general idea >>> of a name in a language is not an arcane concept, but the majority concept. >>> Needing to use an arcane construct either E33_E41 or multi instantiation >>> for the majority case when the standard could just provide the appropriate >>> class and document it and allow people to build around it, would be a >>> superior way to go imho. >>> >>> On Tue, Nov 8, 2022 at 12:04 PM stead...@outlook.com < >>> stead...@outlook.com> wrote: >>> >>>> Surely the RDFS E33_E41 is just a workaround for a common multiple >>>> instantiation that is problematic in RDFS land not a need for a new class. >>>> >>>> >>>> >>>> *From:* Crm-sig <crm-sig-boun...@ics.forth.gr> *On Behalf Of *George >>>> Bruseker via Crm-sig >>>> *Sent:* 07 November 2022 15:58 >>>> *To:* Elias Tzortzakakis <tzort...@ics.forth.gr> >>>> *Cc:* Crm-sig@ics.forth.gr >>>> *Subject:* Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is >>>> a subclass of E41 and E33 >>>> >>>> >>>> >>>> Thank Elias, >>>> >>>> >>>> >>>> You are definitely right that it is ok in the actual doc but mis >>>> referenced in the xml commentary. My point is not that the RDFS is wrong >>>> and it is great that it is produced and solid. I am more interested in how >>>> NOT having legitimate classes in the standard but compromising and just >>>> putting them in RDFS means that a) we create all sorts of arcana around >>>> what should be an open standard and b) because the class is not documented >>>> in the specification document we don't actually have a rule to know what is >>>> should be called. >>>> >>>> >>>> >>>> So it's more a process and principles level issue. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> George >>>> >>>> >>>> >>>> On Mon, Nov 7, 2022 at 5:29 PM Elias Tzortzakakis < >>>> tzort...@ics.forth.gr> wrote: >>>> >>>> Dear George, >>>> >>>> >>>> >>>> The rdfs defines 1 such class using just 1 name the >>>> ‘E33_E41_Linguistic_Appellation’. >>>> >>>> The second name reference you are referring to >>>> ‘E41_E33_Linguistic_Appellation’ exists only in the XML comments of the >>>> rdfs file. >>>> >>>> >>>> >>>> There has been a discussion and decision about the correct order. >>>> >>>> Please see issue >>>> https://cidoc-crm.org/Issue/ID-555-rdfs-implementation-and-related-issues >>>> and search for post starting with In the 51st CIDOC CRM & 44th FRBRoo SIG >>>> meeting >>>> >>>> *Decision*: keeping numbers of the numeric identifier in order. >>>> >>>> >>>> >>>> Thus the rdfs is valid and consistent but the comment lines should also >>>> definitely be adapted to this decision. >>>> >>>> Thanks for spotting, >>>> >>>> >>>> >>>> I will correct this ASAP, >>>> >>>> >>>> >>>> Kind regards, >>>> >>>> Elias Tzortzakakis >>>> >>>> >>>> >>>> >>>> >>>> *From:* Crm-sig <crm-sig-boun...@ics.forth.gr> *On Behalf Of *George >>>> Bruseker via Crm-sig >>>> *Sent:* Monday, November 7, 2022 5:02 PM >>>> *To:* crm-sig <Crm-sig@ics.forth.gr> >>>> *Subject:* [Crm-sig] error in RDFS for 7.1.1 for the class that is a >>>> subclass of E41 and E33 >>>> >>>> >>>> >>>> Dear all, >>>> >>>> >>>> >>>> There are two references to the class that is a subclass of E41 and E33 >>>> that allows you to talk about the language of a name (which is a super >>>> common requirement... actually almost always necessary). I can't give you >>>> it's official name because I dont know because it isn't in the spec doc and >>>> it doesn't have ONE name in the RDFS. >>>> >>>> >>>> >>>> In one reference it is called: E41_E33_Linguistic_Appellation and then >>>> later it is called E33_E41_Linguistic_Appellation. Try find f in the rdfs >>>> doc and you will what I mean. >>>> >>>> >>>> >>>> https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1.rdfs >>>> >>>> >>>> >>>> >>>> >>>> Actually I don't care what it is called, but it would be nice if it was >>>> really, really clear. >>>> >>>> >>>> >>>> I think this speaks against the practice of hiding classes we don't >>>> like and call implementation classes in the RDFS and should make them full >>>> classes in the standard so that they are fully vetted and controlled. It is >>>> a fundamental class. It should be in the standard in the first place. >>>> >>>> >>>> >>>> And definitely it should not have two different name in the RDFS. Can >>>> we confirm that it is supposed to be E33_E41 and not E41_E33? >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> George >>>> >>>> >>>> >>>> -- >>>> >>>> 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/ >>>> >>> >>> >>> -- >>> 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 >>> >> >> >> -- >> Pavlos Fafalios >> >> Postdoctoral researcher (Marie Curie IF - Project ReKnow >> <https://reknow.ics.forth.gr/>) >> Centre for Cultural Informatics & Information Systems Laboratory >> Institute of Computer Science - FORTH >> >> Visiting Lecturer >> Department of Management Science & Technology >> Hellenic Mediterranean University >> >> Web: http://users.ics.forth.gr/~fafalios/ >> Email: fafal...@ics.forth.gr >> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece >> Tel: +30-2810-391619 >> >> _______________________________________________ >> 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 > -- Pavlos Fafalios Postdoctoral researcher (Marie Curie IF - Project ReKnow <https://reknow.ics.forth.gr/>) Centre for Cultural Informatics & Information Systems Laboratory Institute of Computer Science - FORTH Visiting Lecturer Department of Management Science & Technology Hellenic Mediterranean University Web: http://users.ics.forth.gr/~fafalios/ Email: fafal...@ics.forth.gr Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece Tel: +30-2810-391619
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
